| Groups | Blog | Home |
dotnet interop : ExecutionEngineException in dotnet 2.0 application doing interop with VB6 legacy code
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 [quoted text, click to view] Willy Van den Driessche wrote:
> 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. >
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. [quoted text, click to view] "Johannes Passing" <jpassing_at_hotmail_com@nospam.com> wrote in message
news:uY0WKIrJIHA.4584@TK2MSFTNGP03.phx.gbl... > 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 > > Willy Van den Driessche wrote: >> 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.
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 [quoted text, click to view] Willy Van den Driessche wrote:
> 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. > > "Johannes Passing" <jpassing_at_hotmail_com@nospam.com> wrote in message > news:uY0WKIrJIHA.4584@TK2MSFTNGP03.phx.gbl... >> 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 >> >> Willy Van den Driessche wrote: >>> 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.
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. [quoted text, click to view] "Johannes Passing" <jpassing_at_hotmail_com@nospam.com> wrote in message
news:%239LhWVDKIHA.4948@TK2MSFTNGP02.phx.gbl... > 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 > > Willy Van den Driessche wrote: >> 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. >> >> "Johannes Passing" <jpassing_at_hotmail_com@nospam.com> wrote in message >> news:uY0WKIrJIHA.4584@TK2MSFTNGP03.phx.gbl... >>> 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 >>> >>> Willy Van den Driessche wrote: >>>> 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. >>>>
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |