|
|
You're in the
visual studio .net debugging
group:Mixed assembly crashes on exit
visual studio .net debugging:
VS2005 - VC++/MFC: most modules compiled as native. Two modules compiled as
/clr (managed). One of these two modules uses a .NET C# Windows form User control in an MFC dialog box. The program seems to run fine, but crashes when I exit. The same crash occurs even if I immediately exit when the program window opens. 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. Help! I think I am in over my head with this problem. Thanks, Jim
[quoted text, click to view] > 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/]
Oleg,
Thanks for responding to my posting. I have posted this problem in a variety of ways and gotten no help so far. Note that the problem doesn't require much execution of my program. It shows itself immediately. I run the program. When the main window comes up, I select File...Exit and see the problem. ModuleUninitializer() and SingletonDomainUnload() are contained in MINTERNAL.H. I don't seem to be able to set a breakpoint in here. Do you know how to do that? Thanks again for your help. Jim [quoted text, click to view] "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/] > > > > >
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 [quoted text, click to view] "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/] > > > > >
Jim,
Try to enable mixed mode debugging (in the project that you use to start debugging - probably, that's the main .exe's project): (Project properties | Configuration Properties | Debugging | Debugger Type - set to "Mixed" (but not "Auto") It should allow to set breakpoints in all kinds of code. The second time, what exception was reported? Was it also stack overflow, or another one? Is there always the same exception reported after the crash, or are there different exceptions? What does Debug Output window contain after a crash? Are there messages about some other (first chance) exceptions? Try to reproduce the problem several times in a row. Will it always occur in the same place? With the same call stack and exception type? If everything is the same, is it still the same if you let the app run for a while, then exit? (This all may sound like waste of time, but really it should help to see if the problem is random or not; if it always occurs in the same way, probably there is one place where the corruption / misconfiguration occurs, and we will try to find it; if it occurs truly randomly, we will have to invent something else to spot it) Oleg
Oleg,
Thanks for your continued help. 1. On the first development machine: I have now set debugging for both the main project (compiled with /clr) to mixed, and also set debugging for the managed project to mixed. Is that correct? I have tried setting breakpoints at various places in MINTERNAL.H. This appears to be the module where ModuleUninitializer.SingletonDomainUnload() is defined. However, the program never stops at any of these breakpoints. Do you have copies of MINTERNAL.H and MSTARTUP.CPP? If so, you can see where the crash is occurring. When I exit the program, the program crashes the output window shows the following: 'FootanalNovel.exe': Loaded 'C:\WINDOWS\system32\xpsp2res.dll', Binary was not built with debug information. An unhandled exception of type 'System.StackOverflowException' occurred in mscorlib.dll As I said yesterday, the stack trace 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 This is consistent from run to run. If I start the program and wait five minutes, and then exit the program, the same thing happens. =================================================== 2nd Development system: 2. I have also tested this code on the 2nd development machine. That is the one where the problem is occurring within DomainUnload(), defined in the file MSTARTUP.CPP. I can set a breakpoint in this method. As I mentioned in my previous posting in this thread, I can step through DomainUnload() until it reaches the statement: UninitializeAppDomain(); When I try to step into this function, the program crashes. This function, UninitializeAppDomain() is also defined in MSTARUP.CPP. It has a single line of code: _app_exit_callback(); I have set a breakpoint on this line, but it doesn't get hit. But, I am just repeating myself. This is all as I said in my last posting. 3. When the crash occurs attempting to execute UninitializeAppDomain(), there is an "Exception" message. This is the message that I see in the Output window: First-chance exception at 0x7c812a5b in FootanalNovel.exe: 0xE053534F: 0xe053534f. 'FootanalNovel.exe': Loaded 'C:\WINDOWS\system32\xpsp2res.dll', Binary was not built with debug information. 'FootanalNovel.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Culture.dll', No symbols loaded. 'FootanalNovel.exe': Unloaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Culture.dll' Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in 'd:\Program Development\FootAnalNovel\Ver 4.0.1\Debug\FootanalNovel.exe'. Additional Information: The runtime has encountered a fatal error. The address of the error was at 0x7c812a5b, on thread 0xb54. The error code is 0x800703e9. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack. 4. I have repeated this several times on each machine. Each machine is the same as the previous time, but the final errors on the two machines are different, they appear to be occurring in the same general area of code. That is, <CrtImplementationDetails>::ModuleUninitializer::SingletonDomainUnload() =============================================================== I would conclude that the problem is not random, although it occurs in a slightly different place on my two developement systems. Thanks again for your thoughts. Jim [quoted text, click to view] "Oleg Starodumov" wrote:
> Jim, > > Try to enable mixed mode debugging (in the project that you use to start debugging - > probably, that's the main .exe's project): > (Project properties | Configuration Properties | Debugging | Debugger Type - > set to "Mixed" (but not "Auto") > It should allow to set breakpoints in all kinds of code. > > The second time, what exception was reported? Was it also stack overflow, > or another one? Is there always the same exception reported after the crash, > or are there different exceptions? > > What does Debug Output window contain after a crash? Are there messages > about some other (first chance) exceptions? > > Try to reproduce the problem several times in a row. Will it always occur in the same place? > With the same call stack and exception type? If everything is the same, is it still the same > if you let the app run for a while, then exit? > > (This all may sound like waste of time, but really it should help to see if the problem > is random or not; if it always occurs in the same way, probably there is one place > where the corruption / misconfiguration occurs, and we will try to find it; > if it occurs truly randomly, we will have to invent something else to spot it) > > Oleg > > > >
[quoted text, click to view] > 1. On the first development machine: I have now set debugging for both the > main project (compiled with /clr) to mixed, and also set debugging for the > managed project to mixed. Is that correct? > Yes. [quoted text, click to view] > I have tried setting breakpoints at various places in MINTERNAL.H. This > appears to be the module where ModuleUninitializer.SingletonDomainUnload() is > defined. However, the program never stops at any of these breakpoints. > OK, it could be related with the problem, may be. [quoted text, click to view] > Do you have copies of MINTERNAL.H and MSTARTUP.CPP? If so, you can see where > the crash is occurring. > Yes, I see them. The problem is that they are probably not the reason, but victims of a problem that occurs earlier. [quoted text, click to view] > When I exit the program, the program crashes the output window shows the > following: > > 'FootanalNovel.exe': Loaded 'C:\WINDOWS\system32\xpsp2res.dll', Binary was > not built with debug information. > An unhandled exception of type 'System.StackOverflowException' occurred in > mscorlib.dll > Since the application was clean when tested with PageHeap, I would now suspect a kind of stack corruption problem. Do the projects have /GS compiler option enabled? If they don't, will enabling it change anything? Also, if the app's design allows, try to temporarily disable some pieces of code that are used at shutdown phase. May be this way it will be possible to see where the corruption occurs (if the problem goes away after disabling some code). Also, when the debugger has stopped at the stack overflow, try to use the steps described here (assuming that you are debugging the Debug build): http://www.debuginfo.com/articles/easywindbg.html#debugstackoverflow It will not necessarily help (since the app is mixed, not pure native), but still it would be interesting to see the output of the commands ('kf' mainly) Btw, are you familiar with WinDbg? If you are, we could check some additional things with its help. Oleg
Oleg,
I was thinking of recreating the application in an incremental fashion, starting with the MSDN example of a mixed assembly. At each step, build the app and make sure that I can start it, and then immediately exit without errors. My belief is that there is some bug in loading certain modules. I guess is that the basic analysis part of the program will work fine. I suspect that when I start including the parts that use COM and ATL that I might see the problem. Any thoughts on that? Jim [quoted text, click to view] "Oleg Starodumov" wrote:
> > > 1. On the first development machine: I have now set debugging for both the > > main project (compiled with /clr) to mixed, and also set debugging for the > > managed project to mixed. Is that correct? > > > > Yes. > > > I have tried setting breakpoints at various places in MINTERNAL.H. This > > appears to be the module where ModuleUninitializer.SingletonDomainUnload() is > > defined. However, the program never stops at any of these breakpoints. > > > > OK, it could be related with the problem, may be. > > > Do you have copies of MINTERNAL.H and MSTARTUP.CPP? If so, you can see where > > the crash is occurring. > > > > Yes, I see them. The problem is that they are probably not the reason, but victims > of a problem that occurs earlier. > > > When I exit the program, the program crashes the output window shows the > > following: > > > > 'FootanalNovel.exe': Loaded 'C:\WINDOWS\system32\xpsp2res.dll', Binary was > > not built with debug information. > > An unhandled exception of type 'System.StackOverflowException' occurred in > > mscorlib.dll > > > > Since the application was clean when tested with PageHeap, I would now suspect > a kind of stack corruption problem. Do the projects have /GS compiler option enabled? > If they don't, will enabling it change anything? > > Also, if the app's design allows, try to temporarily disable some pieces of code > that are used at shutdown phase. May be this way it will be possible to see where > the corruption occurs (if the problem goes away after disabling some code). > > Also, when the debugger has stopped at the stack overflow, try to use the steps > described here (assuming that you are debugging the Debug build): > http://www.debuginfo.com/articles/easywindbg.html#debugstackoverflow > It will not necessarily help (since the app is mixed, not pure native), but still > it would be interesting to see the output of the commands ('kf' mainly) > > Btw, are you familiar with WinDbg? If you are, we could check some additional > things with its help. > > Oleg > > > >
[quoted text, click to view]
> I was thinking of recreating the application in an incremental fashion, > starting with the MSDN example of a mixed assembly. At each step, build the > app and make sure that I can start it, and then immediately exit without > errors. > Yes, recreating the app incrementally might help, too, if you find it more convenient. [quoted text, click to view] > My belief is that there is some bug in loading certain modules. I guess is > that the basic analysis part of the program will work fine. I suspect that > when I start including the parts that use COM and ATL that I might see the > problem. > I would be more suspicious to interop things (but I don't know specifics of the app, of course). Btw, do you have MDAs enabled? If not, try to enable them, may be they will detect something. http://msdn2.microsoft.com/en-us/library/d21c150d(vs.80).aspx Oleg
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
| home · blog · groups | Questions? Comments? Contact the dn |