So I have issues with RemedyBG loading the main pdb for my exe and im wondering if anyone else has a similar issue with a similar build setup.
In short, I get the error "Cannot find or open PDB file" next to the module for my exe. The setup after build scripts is something along these lines:
Under the Session menu, the "Application and Parameters" section reads as follows:
When I am running a debug session, the Modules window has the following:
I do have Fast Link disabled.
When I run from VS2019, the Modules window has all the same values for "Name", "Path" and "Symbol File". However whenever I right click on the line for my application and go to "Symbol Load Information..." it appears that it tries to load a symbol from the Working Directory before finding the symbol in the PDB Path.
I have tried manually copying the PDB to the working directory, but RemedyBG will still give the error while VS will load it from that directory.
There is a *.dll that the build script compiles and places in a similar fashion and the module is able to load. Its the main exe that is failing.
edit:
This is getting compiled with cl.exe from vs2019-14.28.29910.0.0.0.1993836 with these as the main args before includes and defines: /EHsc /d2FH4- /Z7 /Gw /fp:fast /MD /wd4127 /wd4505 /O2 /bigobj /nologo /W4 /WX /Zo /wd4100 /wd4201 /wd4324 /wd4463 /wd4800 /wd4838 /wd4189 /std:c++17 /wd4995 /wd4996 /wd6326 /FC /c
Can you run dumpbin.exe /headers application.exe | findstr RSDS
on your .exe to check what .pdb file it references? I don't think currently Remedy has ability to load .pdb from other location than this referenced path.
Seems weird that VS doesn't automatically load the PDB for the EXE and requires the use of "Load PDB".
RemedyBG's load order is:
However, I just checked, the basename of the EXE is used for (2), so remedy is looking for D:/perforce/workspace/bin/win64/application.pdb rather than D:/perforce/workspace/bin/win64/application_r.pdb which is wrong. I'll get this fixed.
Curious why it can't locate the PDB in the source/build/release directory in the first place. Is there some kind of permissions issue (running or building as admin maybe) or subst'd drive at play here?