'System.ExecutionEngineException' occurred in Unknown Module

  • Thread starter Thread starter Mountain Bikn' Guy
  • Start date Start date
M

Mountain Bikn' Guy

I have started encountering the following exception frequently:

"An unhandled exception of type 'System.ExecutionEngineException' occurred
in Unknown Module."

I have having trouble determining the exact steps to reproduce it, but it
does happen frequently -- several times per day, and often as many as 3-4
times in a row (within a few minutes) after simple code changes. Then it
goes away for a few edits/builds, but it comes right back within a few more
edits/builds on various code files within my solution.

Does anyone have any suggestions on how to narrow down this issue? Can
anyone suggest to me how I might start getting a clue about what is causing
this?

I'm using managed C#. The most recent change that seems (possibly) related
is the use of visual inheritance. I have some UserControls that inherit from
other UserControls. I use some well-known 3rd party controls on these
inherited UserControls.

I do have some calls into unmanaged DLLs, and some unsafe code blocks, but
I've used all that code for a long time (more than a year) and it hasn't
changed recently at all. All the recent changes are related to UserControls
and forms.
 
'System.ExecutionEngineException' are mostly related to marshaling between managed and unmanaged code, so maybe you should start to
inspect your PInvoke declarations.

Willy.
 
I should have mentioned that every time the exception happens while I'm
debugging, the call stack and the autos windows in the debugger are empty
and the debugger reports no source code is available for this location. The
amount of info available is nil.
 
I have read that 'System.ExecutionEngineExceptions' are mostly related to
marshaling between managed and unmanaged code, but in my case all recent
changes to the code have been entirely in the managed code portions. The
unmanaged code (unsafe blocks and/or calls to unmanaged DLLs) are well over
a year old and are all isolated in their own projects (that are part of this
solution). This portion of the code has been extensively tested and it has
not been a problem under intensive actual use. The problem started when I
added new forms and UserControls. The UI elements are in completely separate
projects -- the whole UI layer is segregated from the other layers of the
app. There is no unmanaged code in the UI layer.
Dave

Willy Denoyette said:
'System.ExecutionEngineException' are mostly related to marshaling
Click to expand...
between managed and unmanaged code, so maybe you should start to
 
I would suggest one the following:

1. Use the Customer Debug Probes (CDB) in v1.1. Like I told you most EEExceptions are due to bad marshaling, You can download a tool
from http://www.gotdotnet.com/Community/...mpleGuid=c7b955c7-231a-406c-9fa5-ad09ef3bb37f (watch linewraps)
that helps you to find and diagnose these kind of bugs using CDB's.
2. If 1 doen't show up, start a debugger on the process at the time of the exception and investigate the call stack.

Willy.
 
I've encountered this problem when doing large numbers of asynchronous web
method calls within multiple app domains. It was ultimately due to a bug in
the runtime - in one of the callbacks the runtime tried to do a security
check on a null pointer.

Willy Denoyette said:
'System.ExecutionEngineException' are mostly related to marshaling
Click to expand...
between managed and unmanaged code, so maybe you should start to
 
Willy,
Thanks for the tips.

Here's where I have gotten so far:
There is a form that hosts a UserControl which itself hosts another
UserControl which is derived from a base UserControl (and that base class
itself is finally derived from
System.Windows.Forms.UserControl).

When the form's constructor is called, InitializeComponent is called. The
derived UserControl is initialized within InitializeComponent. Immediately
after InitializeComponent exits (but while control is still within the
ctor), things get weird. For example, stuff that was initialized or created
within InitializeComponent is null. This includes simple/obvious stuff such
as the "text" field of the form object. Most objects that make up the form
object are now null. In fact, most everything inside the form object is now
null. And of course, the next statement after this will cause a null
reference exception.

This null ref exception error happens about 1/3 the time. The
ExecutionEngineException happens about 1/3 the time. And the other 1/3 the
time the app runs without any errors.

All the code related to this is managed code and almost all of it (or all of
it) was created by the designers.

I bet one of my associates that we could fix this bug by getting rid of the
visual inheritance -- but I sure hate to have to do that as a solution
because we'll then have lots of code duplicated in different classes.

Dave



Willy Denoyette said:
I would suggest one the following:

1. Use the Customer Debug Probes (CDB) in v1.1. Like I told you most
Click to expand...
EEExceptions are due to bad marshaling, You can download a tool
from
Click to expand...
http://www.gotdotnet.com/Community/...mpleGuid=c7b955c7-231a-406c-9fa5-ad09ef3bb37f
(watch linewraps)
that helps you to find and diagnose these kind of bugs using CDB's.
2. If 1 doen't show up, start a debugger on the process at the time of the
Click to expand...
exception and investigate the call stack.
 
Back
Top