www.digitalmars.com         C & C++   DMDScript  

c++.mfc - mfc crash on exit problem -- help

reply "Yochanan" <yochanan israel.net> writes:
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
parent reply Arjan Knepper <arjan ask.me.to> writes:
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
parent reply "Yochanan" <yochanan israel.net> writes:
                                                                             
                                            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
parent reply %u <acorkan ptilabs.com> writes:
  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
parent reply Andy <acorkan ptilabs.com> writes:
  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
parent Andy C <acorkan someaddress.org> writes:
  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