This blog post shows a way to fix the problem with slow C++ debugging in VS2022.
One day, I was debugging my C++ application on Visual Studio 2022 when the computer suddenly froze. Upon reboot, IntelliSense no longer worked but I quickly fixed it by deleting the .SDF file and restarting Visual Studio. However, subsequently I realized that my program ran slowly, obviously not as slowly as what I experienced when using conditional breakpoints, but the execution speed was clearly not normal.
The slowness only happened when the Visual Studio debugger was attached to the debug build of my app. It did not occur if the debug build started standalone, was attached to another debugger or if a release build was used. Clearly, the issue had got to do with Visual Studio. But why exactly?
After a clean and rebuild did not help, I tried to pull the latest commit of my project from the repository, which also didn’t help. I then tried many things such as disabling Just-In-Time debugging, IntelliTrace, Just My Code, expression evaluation, Edit and Continue with no improvements. It also did not make any sense as these settings had been left as default and did not cause any such issues.
After some searching around, inside the property pages for one of the DLLs used by my app, I adjusted the Debug Information Format to Program Database for Edit And Continue (/ZI) inside C/C++ > Code Generation:
and also adjust Runtime Library to Multi-threaded Debug DLL (/MDd):
For some reasons, these settings had been changed to Program Database and Multi-threaded DLL. Finally, inside the Debugging property pages for my C++ Win32 application, I add _NO_DEBUG_HEAP=1
as an additional environment parameter. With this, execution speed improved a bit, but definitely not as fast as before.
As a last resort, I used Tools > Import and Export Settings, chose to Reset all settings and pick General Development Settings. I could not believe it but the debug speed is now normal, e.g., as fast as it can be. I then reverted the _NO_DEBUG_HEAP
setting and realized that the speed was still just as fast, which means setting this value was meaningless.
All in all, I believed some internal Visual Studio settings were corrupted and could only be fixed by resetting all settings. I wasted almost a day on this issue!