When I began to work with Windows 10, I was able to shut the laptop down without Googling to find the power button icon; a great improvement over Windows 8. My next interest was determining what to do when the OS falls over, generating a Blue Screen of Death. This article will describe how to set your system up so that, when it does, you’ll be able to find the cause of most crashes in less than a minute for no cost.
In Windows 10, the Blue Screen looks the same as in Windows 8/8.1. It’s that screen with the frown emoticon and the message “Your PC ran into a problem . . .” This screen appears more friendly than the original Blue Screens, but a truly friendly screen would tell you what caused the problem and how to fix it; something that would not be difficult since most BSODs are caused by misbehaved third party drivers that are often easily identified by the MS Windows debugger.
Just to be clear, this article deals with system crashes, not application crashes or system hangs. In a full system crash, the operating system has concluded that something has gone so wrong (such as memory corruption) that continued operation could cause serious or catastrophic results. Therefore, the OS attempts to shut down as cleanly as possible – saving system state information in the process – then restarts (if set to do so) as a refreshed environment and with debug information ready to be analyzed.
Why Windows 10 crashes
To be sure, Windows has grown in features and size since its introduction in 1985 and has become more stable along the way. Nevertheless, and in spite of the protection mechanisms built in to the OS, crashes still happen.
Once known as the Ring Protection Scheme, Windows 10 operates in both User Mode (Ring 3) and Kernel Mode (Ring 0). The idea is simple; run core operating system code and device drivers in Kernel Mode and software applications and user mode drivers in User Mode. For applications to access the services of the OS and the hardware, they must call upon Windows services that act as proxies. Thus, by blocking User Mode code from having direct access to Kernel Mode, OS operations are generally well protected.
The problem is when Kernel Mode code goes awry. In most cases, it is third-party drivers living in Kernel Mode that make erroneous calls, such as to non-existent memory or to overwrite OS code, that result in system failures. And, yes, it is true that Window itself is seldom at fault.
Sign up for CIO Asia eNewsletters.