c++.mfc - mfc crash on exit problem -- help
- Yochanan (14/14) Sep 12 2006 bs"d
- Arjan Knepper (5/21) Sep 13 2006 exit.c is probably the one in de %DMCROOT%\src\core\ directory.
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
Sep 12 2006
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
Sep 13 2006
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
Sep 13 2006
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
Oct 17 2006
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
Oct 17 2006
Andy C <acorkan someaddress.org> 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.
May 14 2007