 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Interop / November 2007ExecutionEngineException in dotnet 2.0 application doing interop with VB6 legacy code
We are porting a huge VB6 application to dotnet 2.0. The full application has 800KLOC of VB6 code. The old application was basically as small shell application that loaded optional plugins (nearly 100 of them for a complete installation). Because it is impossible to rewrite all existing code at once, we have rewritten the shell (as well as new functionality) in dotnet (also reaching for 200 KLOC of code). The old modules are loaded like they where loaded in VB6. The main shell show them via an (interop) active control. Sometimes, the application halts with a ExecutionEngineException exception. But there is really no pattern in this. Does anybody know how to pinpoint such problems ? Some background : The old app has a core of 8 VB6 DLLs, which in turn use 4 purchased components (FlexGrid, Janus Grid and buttonbar, ActiveReports 1.6, DAO 3.5 (yes !)). I have created interop assemblies for these using TLBIMP.EXE and AXIMP.EXE, making sure they reference one another correctly. Afterwards I have merged all of these use ILMERGE.EXE to reduce the number of assemblies. The error *never* occurs on our development machines but on some testing machines we have the problem (the application is deployed via ClickOnce but all prerequisites are installed with the same installers that have been working for 8 years now). The VB6 code use classes written in ..NET (they implement interfaces defined in the VB6 interop assembly) My little voice tells me it could have something to with stdole.dll. *any* advice is *very* welcome. It turns out it is a "COMPlusException" with the code 0xe0434f4d. All I found is that this is a generic code that means "COM" (the ascii codes - http://dotnetjunkies.com/WebLog/wicwil/archive/2006/04/28/137513.aspx). That's nice. I guessed it had everything to do with COM. But how do I even begin to solve it ? If the crash occurs repeatedly on certain machines, you should be able to attach a debugger or grab a crash dump. Have you tried so? If yes, is the ExecutionEngineException always thrown at the same code location? If so, can you post a stacktrace, please? Finally, why do you suspect stdole.dll? --Johannes > We are porting a huge VB6 application to dotnet 2.0. The full application > has 800KLOC of VB6 code. The old application was basically as small shell [quoted text clipped - 21 lines] > My little voice tells me it could have something to with stdole.dll. *any* > advice is *very* welcome. I have attached a debugger to the crashing apps, setting up symbol server and pdb stuff. The crash is never twice on the same code location. From what we know now, it appears to have something to do with us not closing our database connections to sql express explicitly. I have walked the code and made sure all connections where closed when done and the problem disappeared. We must have had 500+ "open" (in quotes because we don't know when gc will hit) connections. Then the crash appeared. What bothers me is of course the bug in our code but even more so the fact that there was no exception being thrown when we opened too many connections. I suspected stdole because sometimes, the attached debugger reported this error : http://dotnetjunkies.com/WebLog/wicwil/archive/2006/04/28/137513.aspx which is clearly related to COM. I'm still not convinced our bug is completely solved but practice tells me for the moment it is. Thanks for your reply Johannes, Willy. > If the crash occurs repeatedly on certain machines, you should be able to > attach a debugger or grab a crash dump. Have you tried so? If yes, is the [quoted text clipped - 39 lines] >> *any* >> advice is *very* welcome. Hi Willy, all CLR exceptions use the SEH exception code e0434f4d ('COM') - this is more of an historical holdover than an indication that the exception is related to COM. It is still a little weird that the ExecutionEngineException seems to have been the result of "just" a resource leak. Normally, ExecutionEngineExceptions indicate more severe faults like corruped memory... --Johannes > I have attached a debugger to the crashing apps, setting up symbol > server and pdb stuff. [quoted text clipped - 68 lines] >>> *any* >>> advice is *very* welcome. All I know is that the problem has now gone away for now. Inside our application there's still plenty of room for corrupted memory and stacks (since we're for to use (our own) legacy COM components, several third party COM components as well as some unmanaged "simple" DLLs.) so I'm not sure this is the last of it. For the moment the app looks stable. > Hi Willy, > [quoted text clipped - 83 lines] >>>> *any* >>>> advice is *very* welcome.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.