MFC Application has encountered a problem and needs to close. HELP
Alan Williams-Key
Whenever I run my program in release configuraiton it always crashes with
the above error message offering me an option to send a message to Microsoft.
I have discovered it is an access violation (code 5).
Whenever I run the program in debug configuration it runs OK.
I have two main questions:
1 How can the program behave so differently in the two configurations? I can
find no explanation of this in the help files.
2 How can I get useful information about the access violation?
I cannot save the crash dump produced which the exception handler offers to
send to Microsoft for me because it is deleted as soon as I click out of the
dialog and my Norton wizard for recovering lost files doesn't look in the
right directory. Is it possible to disable the MFC exception handling so that
I can generate a drwtsn32 crash dump? If I can, will Visual Studio 6.0 read
it?
I have tried analysing the stack dump in the crash file (a laborious process
using the small scroll window in the report viewer) to find addresses from my
program space, but so far this hasn't led to anything.
Ideally I would like to make the debug configuration detect the access
violation so that I can investigate but I cannot find any options that allow
me to force the debug version to behave in the same way as the release
version. Is there such an option (this is obviously related to my main
question No 1).
Alan
AliR (VC++ MVP)
bug could be the result of Optimization, or the fact that some variables get
initialized in debug mode, where they don't in release.
There are a couple of options for finding the problem, first try to turn on
debug information in your release mode and see if still crashes, which at
that point you should be able to see the callstack and hopefully find the
problem.
If the crash goes away when you add debug information, then turn off the
debug info, and resort to MessageBoxs/TRACEs to find the location of the
bug.
AliR.
"Alan Williams-Key" <AlanWil...@discussions.microsoft.com> wrote in
message news:E04D7A53-A26D-4960...@microsoft.com...
Jim T.
> I have two main questions:
> 1 How can the program behave so differently in the two configurations? I can
> find no explanation of this in the help files.
The main thing I run into is that variables are initialized
differently between Debug and Release builds. It is quite frustrating
at times.
> 2 How can I get useful information about the access violation?
I use map files to help find crashes in release builds. The following
article is what originally informed me about the process:
http://www.codeproject.com/debug/mapfile.asp
There's a few other articles on Code Project that discuss release mode
issues:
http://www.codeproject.com/debug/releasemode.asp
http://www.codeproject.com/debug/survivereleasever.asp
Good luck!
- Jim T.
David Webber
"Alan Williams-Key" <AlanWil...@discussions.microsoft.com> wrote in
message news:E04D7A53-A26D-4960...@microsoft.com...
> Whenever I run the program in debug configuration it runs OK.
>
> I have two main questions:
> 1 How can the program behave so differently in the two configurations? I
> can
> find no explanation of this in the help files.
a) If there is significant code inside a portion which exists only in the
_DEBUG compilation. Not just inside a chunk with #ifdef _DEBUG explict,
but also implicitly inside ASSERT and TRACE and so on.
b) The debug version initialises uninitialised variables. So an
uninitialised variable can have different initial values in the debug and
release versions. It is definitely worth getting used never to writing
int *p;
but always
int *p = .....
including if necessary
int *p = NULL;
And before you do anything else, try "clean solution" in the project both on
the debug and release versions, delete the .ncb .ilk and .aps files for good
measure, and rebuild both. It's amazing how often that makes problems go
away!
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Norbert Unterberg
Alan Williams-Key schrieb:
> Whenever I run my program in release configuraiton it always crashes with
> the above error message offering me an option to send a message to Microsoft.
> I have discovered it is an access violation (code 5).
>
> Whenever I run the program in debug configuration it runs OK.
Why don't you run the release version of your applciation in the debugger to see
what happens?
Norbert
Tom Serface
(local variables) or array indexes. If you know about where the crash
happens, I'd start by just looking at the code and seeing if there is a
variable you may have used, pointer, index, etc. that wasn't ever
initialized. You could also use WinDbg with the release version and a .pdb
file to see if you can figure out where it crashes.
Tom
"Alan Williams-Key" <AlanWil...@discussions.microsoft.com> wrote in
message news:E04D7A53-A26D-4960...@microsoft.com...
Alan Williams-Key
now I have some avenues of investigation.
Alan
Joseph M. Newcomer
>This is driving me nuts.
>
>Whenever I run my program in release configuraiton it always crashes with
>the above error message offering me an option to send a message to Microsoft.
>I have discovered it is an access violation (code 5).
>
>Whenever I run the program in debug configuration it runs OK.
>
>I have two main questions:
>1 How can the program behave so differently in the two configurations?
****
Actually, this is not at all surprising; in fact, it might even be expected.
*****
> I can
>find no explanation of this in the help files.
****
Explanation of what? That release is different than debug?
****
>2 How can I get useful information about the access violation?
>
>I cannot save the crash dump produced which the exception handler offers to
>send to Microsoft for me because it is deleted as soon as I click out of the
>dialog and my Norton wizard for recovering lost files doesn't look in the
>right directory. Is it possible to disable the MFC exception handling so that
>I can generate a drwtsn32 crash dump? If I can, will Visual Studio 6.0 read
>it?
****
This has absolutely nothing to do with "MFC exception handling", which is completely
unrelated to the problem.
Run the release version under the debugger!
****
>
>I have tried analysing the stack dump in the crash file (a laborious process
>using the small scroll window in the report viewer) to find addresses from my
>program space, but so far this hasn't led to anything.
>
>Ideally I would like to make the debug configuration detect the access
>violation so that I can investigate but I cannot find any options that allow
>me to force the debug version to behave in the same way as the release
>version. Is there such an option (this is obviously related to my main
>question No 1).
****
This statement doesn't even make sense. If the access fault appears only in the release
version, it seems unlikely that it will appear in the debug version. You don't "make the
debug configuration" detect a bug that doesn't appear in the debug version.
See my essay "surviving the release version", on my MVP Tips site. Among other things, it
tells how to debug a release version.
joe
****
>
>Alan
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
joe