I use Visual Studio 2019.

Once in a while, I encounter some insane bugs that debug-mode can't help, e.g. heap corruption.

Lucky for me, Windbg can almost detect them in every scenario.

However, I feel ashamed to open gflag.exe, set correct project, recompile as /Z7, disable incremental linking, …, debug in VS in special CPU-profiling mode, and press F5 repeatedly in Windbg.exe.

My workspace is like a frankenstein!

Are there any cooler approach? … or did I miss something?

---------

I learnt Windbg from :-

• https://www.reddit.com/r/windows/comments/3wdlfd/where_to_get_windbg_for_windows_7_nowadays/
• http://stackoverflow.com/questions/35209951/gflags-command-lines
• http://stackoverflow.com/questions/865546/generating-symbols-in-release-binaries-with-visual-studio
• https://stackoverflow.com/questions/30019889/how-to-set-up-symbols-in-windbg

You should in 99% of all cases be able to locate those bugs even without the need to run windbg. Compile in release mode and either turn off optimizations or use a compiler hint to certaina rea of your code you don't want to optimize. Just define an optimization hint and place it on top of the code you want to debug in release mode, do the same after the code is over to turn optimizations on again.

Most bugs appear when you are doing mistakes in development, for example you miss to initialize a local variable but refer to it in the the following lines of code. In debug build, those variables are nulled for you by the debug runtime, in release mode their appear bugs no can't find because in debug anything works fine

Shaarigan said:
You should in 99% of all cases be able to locate those bugs …

Thank! I agree with the whole reply. … but what about 1% minority?

My S-grade bugs will continue to haunt me a few times per year.

In those dark time, I will have to hold the giant Windbg sword.

The 1% minority from my years of experience have several causes in

• GPU related stuff: we had frequently memory leaks in one game caused by shaders allocated but never released on the GPU
• Malfunctionous code: A project I worked on has had the DPad coupled to the Left Control Stick and so playing “as normal” caused the player figure to act incredibly slow
• Uncought memory issues: Once I was working on my own allocator there was an issue in the RBTree structure that caused to write into protected heap at certain circumstances and so deallocation wasn't possible. It caused a memory leak that wasn't visible in first place but caused the allocator to report it on destruction
• Mathematical issues: once I started implementing my own elliptic curve cryptography code there was a bug that anywhere in code some calculations went wrong and I wasn't able to verify the signature. I then completely wiped the code and rewrote it from scratch (previously using a third-party library)
• Last but not least, race conditions/ threading issues (and related): creating my task scheduler was the most pain in the a** moment ever when it threw exceptions infrequently. Turned out that something got cached in threads executing tasks and overritten by something invalid when the task returned. I took me two weeks of intensive testing to get that out and know it runs smooth and as far as I use it, free of those errors. Another error that also occured earlier was that in debug mode some locking structures work different than in release. So for example are Mutex in WINAPI protected against self locking, but not in debug mode. I wanted to have the thread being self locking into infinity while there is no work to do and waked up from a different thread. Using Semaphore solved the problem

Shaarigan said:

The 1% minority from my years of experience have several causes in ….

Those are exciting (horror) stories worth telling grandsons in bedtimes.

I almost feel the thrill as if I encountered those experience myself. Thanks for sharing.