NGen introduces instability

  • Thread starter Thread starter Bill
  • Start date Start date
B

Bill

We have a section of code that executes cleanly until that code is
NGen'ed. After a native image has been created, that same section of
code produces a .NET Runtime Fatal Execution Engine Failure and the
application closes without warning.

Here is the error for the Event Viewer: .NET Runtime version
2.0.50727.42 - Fatal Execution Engine Error (7A05E2B3) (80131506)

We've re-created this issue on XP, Win2000, and Win2003. We've executed
the native image in the debugger; however the debugger does not produce
anything insightful.

Has anyone else encountered this?

Thank you for your time,
Bill O'Neill
 
Bill said:
We have a section of code that executes cleanly until that code is
NGen'ed. After a native image has been created, that same section of
code produces a .NET Runtime Fatal Execution Engine Failure and the
application closes without warning.

Here is the error for the Event Viewer: .NET Runtime version
2.0.50727.42 - Fatal Execution Engine Error (7A05E2B3) (80131506)

We've re-created this issue on XP, Win2000, and Win2003. We've executed
the native image in the debugger; however the debugger does not produce
anything insightful.

Has anyone else encountered this?

Thank you for your time,
Bill O'Neil
Click to expand...

I'm guessing it's the variable called "blarg", on line 32.

You say you've reproduced this on XP, 2000 and 2003. Can you produce a
simple sample piece of code that exhibits this problem, or can you only
reproduce it with your full solution.

It's a *lot* easier to diagnose problems when we have code in front of
us.

Damien
 
Damien said:
I'm guessing it's the variable called "blarg", on line 32.

You say you've reproduced this on XP, 2000 and 2003. Can you produce a
simple sample piece of code that exhibits this problem, or can you only
reproduce it with your full solution.

It's a *lot* easier to diagnose problems when we have code in front of
us.

Damien
Click to expand...

The code should not matter, right? The IL executes just fine, but as
soon as it is NGen'ed, the same code causes .NET to fail. It's my
understanding that NGen should not alter the behavior of the program.
We are not using any unsafe code blocks or unmanaged code in the
problematic method.

To answer your question, I don't know what causes it to crash. I belive
it occurs after a call to ShowDialog(), but I can not confirm. I've
NGened the debug versions of the program in an attempt to isolate the
issue, but the debug version does not crash, only the NGen'ed release
version.

Thanks,
Bill
 
Bill said:
The code should not matter, right? The IL executes just fine, but as
Click to expand...
But obviously the code does matter. Otherwise, your statement is the
same as saying that every application/library that is NGen'ed crashes.
And if that was the case, I'm sure more people would have noticed that
by now.
soon as it is NGen'ed, the same code causes .NET to fail. It's my
understanding that NGen should not alter the behavior of the program.
We are not using any unsafe code blocks or unmanaged code in the
problematic method.

To answer your question, I don't know what causes it to crash. I belive
it occurs after a call to ShowDialog(), but I can not confirm. I've
NGened the debug versions of the program in an attempt to isolate the
issue, but the debug version does not crash, only the NGen'ed release
version.

Thanks,
Bill
Click to expand...
I think you'll have to find the problem the hard way - commenting out
large chunks of code til the problem goes away, then adding code back
until you can reliably reproduce the problem. You'd then probably be
able to provide some repro code so that others can throw their eyeballs
at the problem.

Damien
 
Damien said:
But obviously the code does matter. Otherwise, your statement is the
same as saying that every application/library that is NGen'ed crashes.
And if that was the case, I'm sure more people would have noticed that
by now.

I think you'll have to find the problem the hard way - commenting out
large chunks of code til the problem goes away, then adding code back
until you can reliably reproduce the problem. You'd then probably be
able to provide some repro code so that others can throw their eyeballs
at the problem.
Click to expand...

Also look at production debugging:

Debugging Tools for Windows - Overview
http://www.microsoft.com/whdc/devtools/debugging/default.mspx

How to use ADPlus to troubleshoot "hangs" and "crashes"
http://support.microsoft.com/default.aspx/kb/286350

It shouldn't be too hard to at least find the where the crash is occuring.
David
 
Thank you; I will give those tools a try.

I've narrowed it down to one line, but I can not re-create the issue in
a simple, stand-alone, NGen'ed assembly.

=== begin code ===
try
{
Class1 c1 = new Class1( );
Class2 c2 = new Class2( c1.SomeProp ); // This is the line that causes
the problem.
}
catch
{
}
=== end code ===

c1.SomeProp raises an exception. The catch block is hit but the
application begins to degrade and quickly crashes after the exception
is raised. If I call c1.SomeProp outside of the argument list to the
Class2 constructor the exception is raised but the application executes
normally:

Class1 c1 = new Class1( );
Image img = c1.SomeProp; //The exception is raised here
Class2 c2 = new Class2( img );

I believe the underlying problem is a threading issue. We are
performing background processing an Application.Idle event handler. The
application seems to choke in this event handler code, but I can't tell
for sure yet. I'll try your suggested tools.

Thanks again for your help.

Bill
 
Back
Top