Re: Mixed assembly crashes on exit

Oleg,

1. I ran PageHeap with the mods to the registry that you suggested. I
rebuilt the application, both the Visual C++ /clr part, and the C# .NET part
with /MD instead of /MDd. I ran under the debugger. I didn't get any breaks
until the one at the end: The Output window shows:

An unhandled exception of type 'System.StackOverflowException' occurred in
mscorlib.dll


The stack shows:

->mscorlib.dll!System.Collections.Stack.GetEnumerator()
msvcm80.dll!<CrtImplementationDetails>.ModuleUninitializer.SingletonDomainUnload(objec
source = {System.AppDomain}, System.EventArgs arguments = null) + 0x6a bytes
kernel32.dll!_BaseThreadStart@8() + 0x37 bytes

2. When I run this on another development machine, I get a better sense of
where this is happening. I can set a breakpoint in DomainUnload() in
MSTARTUP.CPP. This breakpoint gets hit just before the crash. Here is a
snippet from DomainUnload():
=============
static void DomainUnload(Object^ source, EventArgs^ arguments)
{
if (CurrentDomain::Initialized &&
!Interlocked::Exchange(CurrentDomain::Uninitialized, (int)1))
{
#if defined (_M_CEE_MIXED)
bool lastDomain = (Interlocked::Decrement(AllDomains::Count) ==
0);
#endif /* defined (_M_CEE_MIXED) */

UninitializeAppDomain();
=============================

The error occurs when it makes a call to the function named
UninitializeAppDomain(). That function is also defined in MSTARTUP.CPP. It
has just one line:

_app_exit_callback();

I can put a breakpoint in that line, but it never gets there.

3. When the error occurs, using the call stack, I can look into
ModuleUninitializer::SingletonDomainUnload(). If I expand the "this" pointer,
it shows two items: System::Collections::Stack^ and _ModuleUninitializer. If
I expand _ModuleUninitializer, it contains two items:
System::Collections::Stack^ and _ModuleUninitializer. This seems to continue
recursively, i.e. each _ModuleUninitializer contains two items:
System::Collections::Stack^ and another _ModuleUninitializer. As far as I can
tell, there is no end to this nesting.

Does this give you any idea of how to debug this further?

Thanks,
Jim



"Oleg Starodumov" wrote:


I have reproduced the problem on two development systems. While the final
error is different on the two systems, is different, it occurs in the same
general area. I have tracked the code to MINTERNAL.H,
ModuleUninitializer::SingletonDomainUnload(). It is using a C++ for each
statement to iterate through a collection of handlers presumably to unload
the modules of the program. It is possible that this collection has gotten
corrupted.


Since the application has native components, I would recommend to start
by checking for possible native heap corruptions (which could, as a side effect,
cause this problem), an effective way to do it is shown by the link below:
http://www.debuginfo.com/tips/userbpntdll.html
(when running the app under debugger, watch also for unexpected first chance
exceptions in Debug Output window, or configure the debugger to stop
when an access violation exception is "thrown" - see Debug | Exceptions dialog)

If it does not help, and if you can reproduce the problem under debugger,
try to inspect the stack collection used by ModuleUninitializer object.
Will there be anything strange in the data?
Also try to set breakpoint in SingletoneDomainUnload function and step
through it, into the modules - will it be able to step at least into one module
(into its DomainUnload), or will it break immediately?

When the crash occurs, what functions are on the call stack?
Also, how does the disassembly around the place of crash look?

--
Oleg
[VC++ MVP http://www.debuginfo.com/]






.

Relevant Pages

  • Re: throw(int) crashes on XP-SP2
    ... The technique to debug this one is to set a breakpoint on the ... Either one of the handlers is regarded as invalid, ... For the first case, it could be a corrupted stack frame, a SafeSEH image, ... does not recognized the exception record. ...
    (microsoft.public.vc.language)
  • Re: Some impressions with D7
    ... Apparently Visual studio is able to recover the stack and also shows local data. ... If your app hits an exception after half an hour, then I'd like to start there and not guess where to set a breakpoint and wait for another half hour if it was even repeatable. ...
    (borland.public.delphi.non-technical)
Loading