Thread overview |
---|
September 12, 2006 mfc crash on exit problem -- help | ||||
---|---|---|---|---|
| ||||
bs"d Hi-- I am having a problem where every mfc program that I write crashes with an Access Violation (0xc0000005) on exit in debug mode, and in release mode, the program nominally exits, however, remains running in the background, and then I need to close the process from the Windows task manager. When I try to step through the exit sequence with the debugger, it reaches the end of the ExitInstance main app function and then displays an Assembly code window with the address FEEEFEEE ??? 'no code' and the Access violation message. If I try to single step out of the ExitInstance() function, the debugger calls for the file exit.c --- (which I can't find) before crashing. Can you help me with this probelem? Thanks. Yochanan |
September 13, 2006 Re: mfc crash on exit problem -- help | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yochanan | Yochanan wrote:
> bs"d
>
>
> Hi-- I am having a problem where every mfc program that I write crashes with an Access Violation (0xc0000005) on exit in debug mode, and in release mode, the program nominally exits, however, remains running in the background, and then I need to close the process from the Windows task manager.
>
> When I try to step through the exit sequence with the debugger, it reaches the end of the ExitInstance main app function and then displays an Assembly code window with the address FEEEFEEE ??? 'no code' and the Access violation message.
>
> If I try to single step out of the ExitInstance() function, the debugger calls for the file exit.c --- (which I can't find) before crashing.
exit.c is probably the one in de %DMCROOT%\src\core\ directory.
Did you rebuild the mfc libs with DMC? Are you sure the compiler flags and defines are the same for MFC libs and your apps?
Arjan
|
September 13, 2006 Re: mfc crash on exit problem -- help | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arjan Knepper | bs"d Hi Arjan, Thanks for helping with this. I didn't rebuild the MFC libs with DMC, and -- to the best of my memory I've got the entire system including libraries straight off of the version 8.31 DM cd. Although I may have tried to upgrade from the digitalmars web site at some time afterwards, the files all seem to date from before 12/2002. I found the exit.c in the src directory. /*_ exit.c Sat Sep 1 1990 Modified by: Walter Bright */ /* Copyright (C) 1985-1994 by Digital Mars */ /* All Rights Reserved */ /* $Revision: 1.1.1.3 $ */ Stepping through the code I get the access violation at this line: (**_atexitp)(); /* call registered function */ (line 53 in exit.c ) in the void exit (int errstatus) function after going through the while (*_atexitp) { ... loop a number of times. The next level down is uncommented assembler code. What could the problem be? "Arjan Knepper" <arjan@ask.me.to> ??? ??????:ee8eh8$2d2m$1@digitaldaemon.com... > Yochanan wrote: >> bs"d >> >> >> Hi-- I am having a problem where every mfc program that I write crashes with an Access Violation (0xc0000005) on exit in debug mode, and in release mode, the program nominally exits, however, remains running in the background, and then I need to close the process from the Windows task manager. >> >> When I try to step through the exit sequence with the debugger, it reaches the end of the ExitInstance main app function and then displays an Assembly code window with the address FEEEFEEE ??? 'no code' and the Access violation message. >> >> If I try to single step out of the ExitInstance() function, the debugger calls for the file exit.c --- (which I can't find) before crashing. > > exit.c is probably the one in de %DMCROOT%\src\core\ directory. > > Did you rebuild the mfc libs with DMC? Are you sure the compiler flags and defines are the same for MFC libs and your apps? > > Arjan |
October 17, 2006 Re: mfc crash on exit problem -- help | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yochanan | This happens to me _every_ time in Debug mode under windbg. If I run either Debug or Release version I have no problem. I am running under Eclipse so I don't use the integrated debugger in the IDE but I recall having this problem years ago as well. I do not have the problem of the program staying resident in background. Did you build the program using the App wizard? Try building a simple MFC app and get it to fail (or not), or maybe one of the sample programs. This will help pinpoint the problem in your code or settings. I will post if I remember the solution. Andy |
October 17, 2006 Re: mfc crash on exit problem -- help - followup | ||||
---|---|---|---|---|
| ||||
Posted in reply to %u | I think your original problem may be two different issues. Crash when debugging (0xc0000005: Access Violation) will crash the debugger (Windbg.exe I think). There is nothing you can do since the debugger itself is crashing. I don't know what options you have or what alternative programs there are. I know that Windbg has problems with Exception handling (I see this in the trace of your problem and in my current applications). I tested this with the latest CD release and it happens even with a simple MDI MFC app generated with AppExpress - so it is not you! Program still in memory. This is probably somthing you are doing incorrectly. Maybe not killing all your threads or windows properly. This probably is you! It would be nice if there were an alternative debugger, one that was up to date and could run under Eclipse. Not likely to happen. :) Andy |
May 14, 2007 Re: mfc crash on exit problem -- more info... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy | The crash is occuring because in MFC4.x (what DMC uses) the CWinApp::Enable3dControls implements a series of functions that are, in the words of microsoft: "In MFC 5.0, Enable3dControls and Enable3dControlsStatic are obsolete because their functionality is incorporated into Microsoft's 32-bit operating systems." As a result a bunch of function pointers related to 3D-controls point to 0xfeeefeee, instead of the correct functions. This is a problem when _AFX_CTL3D_THREAD::~_AFX_CTL3D_THREAD() is called because it accesses a function if the ptr is not null, and this causes a crash. Look in ..\dm\mfc\src\32-bit\app3d.cpp. If I can redirect the ptr or change the pointer value I will report on success. |
Copyright © 1999-2021 by the D Language Foundation