Avatar of tussfw

asked on 

Strange bug with MFC release build


I'm having a very strange bug with the release build. The program we are developing crashes with the release build, but only if running out side MS VC++ 6.0. If I run it from the IDE it's fine. The debug version is fine also.

I'm not sure how to go about debuging such a problem. It seems to be a memory related access problem but with out further information it's very hard to track down (the code base is very large). Has any one come across a similar problem? What tools did/do you use to debug outside of the IDE??

The problem is only present when a specific check box is ticked, which does limit the scope of the code somewhat, but is not enough to fix the problem.

Any inputs are welcome :D
Editors IDEsSystem ProgrammingC++

Avatar of undefined
Last Comment
Avatar of jkr
Flag of Germany image

You could try to start with http://msdn.microsoft.com/en-us/library/fsk896zz(VS.71).aspx ("Debugging a Release Build")
Avatar of tussfw


Like I said in my question. The bug only shows up if you run the exe outside VC++. Running release build with debug info in the IDE does not produce the bug. The only way of getting this bug is to go to the executable folder and double click on the exe file.

I guess I'm asking for a way of debugging the program outside of VC++, or at least get a bit more info other than the windows error message.
Avatar of jkr
Flag of Germany image

If you have a map file for your application, you can use that one along with an exception handler in order to locate the faulting function. Consider e.g.


ExceptionHandler(LPEXCEPTION_POINTERS pe) {

   char acModule[MAX_PATH];

   HMODULE hMod;

   VirtualQuery (pe->ExceptionRecord->ExceptionAddress,&mbi,sizeof(mbi));

   ptrdiff_t RVA = (char*)pe->ExceptionRecord->ExceptionAddress - (char*)mbi.AllocationBase;

   hMod = (HMODULE) mbi.AllocationBase;

   GetModuleFileName(hMod,acModule,sizeof (acModule));

   printf( "Detected Exception in %s at RVA 0x%08X\n", acModule, RVA);


void FaultingFunction () {

   LONG* p = NULL;
   *p = 42;

void main(){

   SetUnhandledExceptionFilter (ExceptionHandler);
   FaultingFunction ();

(compiled with "cl rvaxcept.cpp /link /map")

which prints

Detected Exception in C:\tmp\cc\rvaxcept.exe at RVA 0x00001088

The map file is


Timestamp is 44660958 (Sat Jul 19 18:29:12 2008)

Preferred load address is 00400000

Start         Length     Name                   Class
0001:00000000 00004938H .text                   CODE

Address         Publics by Value              Rva+Base     Lib:Object

0001:00000000       _ExceptionHandler@4        00401000 f   rvaxcept.obj
0001:0000007a       _FaultingFunction          0040107a f   rvaxcept.obj
0001:00000092       _main                      00401092 f   rvaxcept.obj
0001:000000a7       _printf                    004010a7 f   LIBC:printf.obj
0001:000000d8       _mainCRTStartup            004010d8 f   LIBC:crt0.obj
0001:000001b7       __amsg_exit                004011b7 f   LIBC:crt0.obj

You can see the 'Rva+Base' column, base is given as 'Preferred load address is 00400000'

Add that to the faulting module RVA of 0x00001088 and you get 0x00401088, then look that up in the above (i.e. the 'nearest symbol' and you can see that it is 'FaultingFunction'

0001:0000007a       _FaultingFunction          0040107a f   rvaxcept.obj
0001:00000092       _main                      00401092 f   rvaxcept.obj

The address is between main and FaultingFunction, which starts before 0x00401088, the next function is main and starts later.
Avatar of Zoppo
Flag of Germany image

Hi tussfw,

as addition to jkr's suggestion: In such an exception handler you could create a crash dump using 'MiniDumpWriteDump' for post-mortem debuggin - if you have written such a crash dump you can load this dump i.e. in WinDbg - then you can see it as if you were debugging the application ...

>>>> but only if running out side MS VC++ 6.0.
The difference is that in the IDE the paths were taken from Tools-Options-Directories-Executable Directories while outside they were taken from PATH environment variable (type: PATH at the command prompt). If you synchronize both it should work.
Another difference maybe the working directory which is the project directory when starting from the IDE, while it maybe the .\Release subdirectory when starting from the explorer (open a command window, change directory to the project folder and type 'Release\your_app' to have the same working dir).  
Avatar of tussfw

Blurred text
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
>>>> I'm still not sure why this did not cause a problem in the IDE.  
The debugger provides initialized (all zeros) memory while the operation system does not.

C++ is an intermediate-level general-purpose programming language, not to be confused with C or C#. It was developed as a set of extensions to the C programming language to improve type-safety and add support for automatic resource management, object-orientation, generic programming, and exception handling, among other features.

Top Experts
Get a personalized solution from industry experts
Ask the experts
Read over 600 more reviews


IBM logoIntel logoMicrosoft logoUbisoft logoSAP logo
Qualcomm logoCitrix Systems logoWorkday logoErnst & Young logo
High performer badgeUsers love us badge
LinkedIn logoFacebook logoX logoInstagram logoTikTok logoYouTube logo