EpicGamesExt
Locals not found after debug trap on first run
I've found an issue with using __debugbreak() and __builtin_trap() (i.e. in an assert macro) and not being able to see any locals after the trap is hit on the first run. This happens with executables produced as /SUBSYSTEM:WINDOWS. Here's a minimal example to help explain:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
int WINAPI WinMain(HINSTANCE Instance, HINSTANCE PrevInstance, PSTR CmdLine, int ShowCmd)
{
int Foo = 69;
__debugbreak();
return 0;
}
I've compiled this with MSVC and clang, trying these commands: cl hi.c /Z7, cl hi.c /Zi, clang hi.c -o hi.exe -g
I load the exe using raddbg hi.exe and run without setting any breakpoints, and it stops on the trap as expected. I put Foo in a watch window and I keep a locals window open. The first time I run immediately after compiling I get Foo could not be found in the watch window and nothing in the locals window, not even the WinMain args. I run it again (either Restart or Kill All -> Run) without compiling and I see Foo in the watch window and everything in the locals window as expected. If I recompile (whether or not I make any changes to the code) the same thing happens and I have to restart to see the locals.
I get what I expect on the first run immediately after compiling when I use *((int *)0) = 0; as the trap instruction, with both MSVC and clang. Changing the entry point to a standard int main(int argc, char **argv) so the exe is linked as /SUBSYSTEM:CONSOLE also gives me what I expect.
I'm using raddbg v0.9.24-alpha, MSVC 19.44.35217, and clang 19.1.5 on Windows 11.
This is probably related to your file path casing - the debugger will incorrectly disqualify the PDB as being needed for breakpoint resolution if the debugger has breakpoints placed on a file path that is cased differently than whatever is stored in your PDB. I have this on my list to fix.
