mikew wrote: ↑2023-Nov-09, 10:45The debug builds are crashing even on a PC with VS installed. No error box, but the gui is visible for about a second, then disappears.
Have you tried to run them with a debugger attached, e.g. from the Visual Studio IDE? I know that there is a place in extension setup that does not give proper error messages but just runs into hard-coded breakpoints on error. Could be it. I’ll create a ticket so I don’t forget to clean this up …
Also, (and this may be standard behaviour) these files stay active for a long time after I exit the game. I know this because I can't delete the 'tfxplorer' folder until they exit which is maybe after 15 minutes or so. Not something I do often though.
hangms.PNG
Okay, this one is a bit more complicated.
So the compiler generates debug information, i.e. which instruction in the executable maps to which line in the code, how our data structures are laid out, etc. This debug information goes to a PDB file (
Program DataBase or some other stone age term) and that’s pretty straightforward if your program consists of a single C++ file.
But if you have multiple C++ files and compile in parallel, you’ll have 10 compiler instances trying to write the debug information from 10 C++ files at the same time. The first instinct is to synchronize access. But this introduces more performance problems, as every compiler instance needs to open the existing PDB, parse it entirely, then place its new information there, and close it.
That became a bottleneck and so Microsoft decided they’d have a background service. That’s
mspdbsrv.exe –
MicroSoft Program DataBase SeRVice. Now the first compiler instance launches the service and instead of opening the PDB file itself, just passes on the debug information to the service. And so do all other instances. The service opens the PDB only once, so the
O(n²) becomes
O(n).
But that only works if the service sticks around for a while (doesn’t shut down during compilation) – or at least MS thinks so. So MS gave this service a timeout of several minutes before it closes.
And
that is why you can’t delete the repository right after compiling:
mspdbsrv.exe still sticks around, in case that someone needs to write more debug information for the EXE.
So usually it’s enough to open the Task Manager and kill
mspdbsrv.exe. But here’s the catch: Due to some Microsoft black magic, it sometimes doesn’t show up in Task Manager. (Really interesting topic, I’d love to talk about that with an IT security pro one day!) So if that’s the case for you, go to the
Performance tab, click
Open Resource Monitor at the very bottom, and terminate it from there.
- image.png (34.53 KiB) Viewed 2474 times
Sorry for the text, but this is pretty much undocumented and it’s probably better to understand the problem instead of having me say
“Just terminate that EXE from my repository that’s invisible in your Task Manager and it’ll be fine, trust me bro!” And for the paranoid (like me): That EXE is digitally signed by Microsoft, as you can check in the file properties. So it’s no malware, or at least not more harmful than other Microsoft products.