Strange bug with MFC release build

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

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.

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.

#include
#include
#include

LONG
WINAPI
ExceptionHandler(LPEXCEPTION_POINTERS pe) {

   char acModule[MAX_PATH];

   MEMORY_BASIC_INFORMATION mbi;
   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);

   return EXCEPTION_EXECUTE_HANDLER;
}

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

rvaxcept

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.

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 ...

ZOPPO

>>>> 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).  

>>>> 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.