> I can fairly reliably (but not exactly) reproduce this error when running my
> application under .NET 1.1.
[quoted text clipped - 8 lines]
> Several articles claim that if the error doesn't occur under .NET 2.0 then
> no further effort should be expended. Is that true?
An execution engine error is either a bug in the CLR or a bug in some
unsafe / unmanaged code (probably causing memory corruption). Ideally,
you'll want to isolate the error to discover what's causing it, to find
out if it's your application or it's the CLR.
If it doesn't occur in .NET 2.0, that doesn't necessarily mean that the
error is gone. If it's a bug in some unsafe / unmanaged code, then it
may simply be corrupting a different location in memory or that some CLR
data structure layouts have changed.
-- Barry

Signature
http://barrkel.blogspot.com/
Valerie Hough - 23 Jul 2006 20:09 GMT
Thanks for your response.
I have some calls to Win32 APIs. Is it safe to say that if the software
never calls any of this unmanaged code before the crash that it cannot be a
programming problem?
Is there any way to track down the problem? I have tried to use the
debugger, but if the corruption occurs earlier than the crash, I do not know
how to find the problem.
Any help is much appreciated.
Barry Kelly - 23 Jul 2006 21:25 GMT
> I have some calls to Win32 APIs. Is it safe to say that if the software
> never calls any of this unmanaged code before the crash that it cannot be a
[quoted text clipped - 3 lines]
> debugger, but if the corruption occurs earlier than the crash, I do not know
> how to find the problem.
If you want a definitive answer (and I would, in your position, given
the nature of the exception), you'll need to pare down the application
to a reproducing case. Depending on the project size / modularity, that
could take time etc.
With respect to the Win32 API calls, to be certain, I'd comment out them
out and the code that calls them.
-- Barry

Signature
http://barrkel.blogspot.com/
Valerie Hough - 23 Jul 2006 20:38 GMT
I don't know if it is significant, but the line of code that is executing
every time the error occurs (by stepping through the code with the debugger)
is SqlCmd.ExecuteNonQuery(), which is contained in a try/catch block.
Barry Kelly - 23 Jul 2006 21:25 GMT
> I don't know if it is significant, but the line of code that is executing
> every time the error occurs (by stepping through the code with the debugger)
> is SqlCmd.ExecuteNonQuery(), which is contained in a try/catch block.
Could possibly be a bug in the DB driver...
-- Barry

Signature
http://barrkel.blogspot.com/