[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.interop

ExecutionEngineException in dotnet 2.0 application doing interop with VB6 legacy code

Willy Van den Driessche

11/8/2007 11:37:00 PM

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.
4 Answers

Johannes Passing

11/14/2007 11:32:00 AM

0

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.
>
>

Willy Van den Driessche

11/16/2007 8:15:00 AM

0

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/1...
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.
>>

Johannes Passing

11/16/2007 9:45:00 AM

0

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/1...
> 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.
>>>

Willy Van den Driessche

11/18/2007 3:04:00 PM

0

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.

"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/1...
>> 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.
>>>>