System.ExecutionEngineException when making COM call 
Author Message
 System.ExecutionEngineException when making COM call

Hi,

I am getting a System.ExecutionEngineException when making a COM call to a
C++ COM DLL compiled in VC7.

The problem appears to be on the C# side as I have debugged the C++ DLL and
have a test suite that makes more than 10,000 calls successfully (from C#)
to the same COM method that is causing the problem this time around. In this
particular application, many calls are made to the same method, but it
causes the problem on the 5th call...

private void FindJunction(string name)
{
    m_JunctionCursor.Find((int)m_JunctionMap[name]);

Quote:
}

The .Find method is the guy that fails (or more to the point, never gets
executed), and m_JunctionMap is a Hashtable. There is nothing wrong with the
Hashtable, it returns the correct value. (I have tested this by breaking the
FindJunction function into several lines). I have also tried this on another
PC, tried re-writing the code etc etc. When debugging the COM DLL, the .Find
method call that fails never makes it into the COM DLL so it seems it really
does die in C# before the call (or during the call).

The call to FindJunction is made from within a switch statement.

The MS docco states that "Execution engine errors are fatal errors that
should never occur." Sounds as serious as the swag of Internal Compiler
Errors (C1001) I've been bumping into over the last couple of weeks with
VC7.

Kind Regards,
Wayne Hartell



Wed, 06 Oct 2004 08:17:49 GMT  
 System.ExecutionEngineException when making COM call
Sorry. False alarm.

I managed to resolve this particular bug. There was a redundant call to
Release() in the COM component in a method that is call from the C# code
right before the .Find method is called. I guess the error in C# was a
little unintuitive, but understandable given what was happening ;0)

Wayne.


Quote:
> Hi,

> I am getting a System.ExecutionEngineException when making a COM call to a
> C++ COM DLL compiled in VC7.

> The problem appears to be on the C# side as I have debugged the C++ DLL
and
> have a test suite that makes more than 10,000 calls successfully (from C#)
> to the same COM method that is causing the problem this time around. In
this
> particular application, many calls are made to the same method, but it
> causes the problem on the 5th call...

> private void FindJunction(string name)
> {
>     m_JunctionCursor.Find((int)m_JunctionMap[name]);
> }

> The .Find method is the guy that fails (or more to the point, never gets
> executed), and m_JunctionMap is a Hashtable. There is nothing wrong with
the
> Hashtable, it returns the correct value. (I have tested this by breaking
the
> FindJunction function into several lines). I have also tried this on
another
> PC, tried re-writing the code etc etc. When debugging the COM DLL, the
.Find
> method call that fails never makes it into the COM DLL so it seems it
really
> does die in C# before the call (or during the call).

> The call to FindJunction is made from within a switch statement.

> The MS docco states that "Execution engine errors are fatal errors that
> should never occur." Sounds as serious as the swag of Internal Compiler
> Errors (C1001) I've been bumping into over the last couple of weeks with
> VC7.

> Kind Regards,
> Wayne Hartell



Wed, 06 Oct 2004 09:33:36 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. System.ExecutionEngineException - framework bug?

2. System.ExecutionEngineException

3. System.ExecutionEngineException exception

4. System.ExecutionEngineException - mixing managed/unmanaged code

5. TLBIMPORT raises System.ExecutionEngineException

6. VC7 Debugger Crashes with System.ExecutionEngineException?

7. System.ExecutionEngineException cant be caught

8. Unhandled Exception: System.Configuration.ConfigurationException: Could not create System Configuration.NameValueSectionHandler, System

9. how to replace System.Globalization.CultureInfo.CurrentCulture with some custom made CultureInfo object

10. suppressing the DOS window when system() call is made

11. C DLL making calls to a COM object

12. Making calls to a COM object from a well-known object

 

 
Powered by phpBB® Forum Software