Hi,
We have a few bugs that only seem to be reproducible by none developers. We’ve set up our testers with Visual Studio and have them attach it to the running processes, however the game catches the exception and sticks it in a message box, by the time VS knows of the crash the call stack is different, we’ve tried supplying the Debug command in the shortcut but that hasn’t worked.
Cheers.
Running the game with -VADEBUG does the trick.
At least as of 4.11 -VADEBUG seems to have been deprecated (sorry, I don’t have an earlier version synced). I’d check in your codebase whether it’s actually doing anything…
Are you attaching to the game or editor? Which configuration are you running in?
If you look in AssertionMacros.h you’ll see _DebugBreakAndPromptForRemote which should be called by all error handlers and will call DebugBreak for Visual Studio.
(You can type “debug crash” at a console to force a crash and verify behavior).
What type of exception are you getting? Can you post an image of this dialog box?
“DEBUG CRASH” simulates an unhandled exception which it sounds like VS is correctly trapping. There is also “DEBUG CHECK” which simulates a failed assert. This relies on some macro-magic to print the message and break on the correct line if the debugger is present.
From the error screenshot it looks like the main thread is running within an exception guard. This does not happen if you launch the editor from a debugger, but would if you attach it after startup.
If you look at FRunnableThreadWin::GuardedRun in WindowsRunnableThread.cpp you’ll see where the decision to run guarded/unguarded is. If you change
if (FPlatformMisc::IsDebuggerPresent() && !GAlwaysReportCrash)
To
if ((FPlatformMisc::IsDebuggerPresent() || FParse::Param( FCommandLine::Get(), TEXT("nothreadguard") )) && !GAlwaysReportCrash)
And run the editor with -nothreadguard then crashes should always be unhandled