If it crashes in a way that opens the debugger, it won't be running in the debugger. There's a window that shows the call stack but I think it's closed by default. To see it, you probably have to go to Debug : Windows and select the Call Stack window.
So far as I know, that particular error only gets noticed in debug builds and when they happen, the debugger breaks in and displays a dialog box, so I don't bother logging them.(do you have a log file where messages like
HEAP[mojo.exe]: HEAP: Free Heap block 20efa68 modified at 20efa90 after it was freed
would go when starting from windows normally ?)
Most errors that can occur in release builds get logged in two files in
%localappdata%
If a memory error causes a crash, the program's "last resort" exception handler should be creating a mini dump with crash data including the address of the error. When the debugger gets called up automatically like it's doing for you, I think it already has the crash dump loaded.
You're running your own build, right, so the debugger should have all the symbol tables etc. that it needs to show you everything.
You can run the program in the debugger to begin with. That way when it crashes it will just stop wherever it crashed.
Open the Call Stack window (explained above) and you should be able to see instantly where it crashed.
Connect With Us