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

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

                                            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

  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

  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

  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.