Johannes Passing
11/14/2007 11:32:00 AM
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.
>
>