A customer had a program that crashed occasionally with a heap corruption bug, but in their efforts to isolate the problem, they found that if they ran the program in Safe Mode, the program never crashed. What is so special about Safe Mode that prevents heap corruption bugs? (Can we build the whole airplane out of Safe Mode?)
One of the things that makes Safe Mode safe is that it loads only very basic video drivers. Some parts of video drivers run inside the user-mode process, which means that their memory allocations will intermingle with the process’s memory allocations, and it is the nature of heap corruption bugs that small perturbations in memory allocation patterns can drastically alter the way a heap corruption bug manifests itself, possibly even masking it entirely.
The customer knew that they had a heap corruption bug on their hands (and some time with Application Verifier quickly found the source of the corruption). They were just wondering why Safe Mode seemed to hide it.
And no, they weren’t going to tell their users, “For best results, run this program in Safe Mode.”
Bonus reading: Windows Confidential: The Healing Powers of Safe Mode, and The magical healing properties of safe mode – bonus content.
Sounds a bit like the (possibly apocryphal) story that a version of Word Perfect was shipped to customers in “debug” mode because every attempt to make a release build with optimization and NOPed asserts or whatever was too unstable.
Luckily with modern automated testing techniques that kind of thing would *never* happen today.
;-/
I expect that the video driver must use a completely isolated heap. No?
I guess some data is better kept in the client process. Perhaps this is why the Vulkan API lets you provide an allocator for the driver to use.