Windows once had a very bad reputation regarding stability. Windows NT improved the overall stability significantly, but perhaps Windows XP was the first Windows version that could be called stable. Due to sloppy programming of third party devices drivers, Vista's stability suffered considerably. Windows 7 was remarkably stable right from the beginning, thanks to Vista's groundwork.
- OpenVPN IPv6 and IPv4 configuration - Mon, Mar 1 2021
- 4sysops author and member competition 2020 - Fri, Jan 1 2021
- Assign an IPv6 address to an EC2 instance (dual stack) - Tue, Dec 15 2020
Blue Screen of Death (BSOD) ^
It can be quite annoying if a system is continuously crashing with the famous blue screen of death (BSOD). There are several ways to find the culprit. The Windows Eventlog is always the first place you have to check, if problems occur. If Windows has already been already running smoothly for some time and only started bucking lately, then newly-added devices or updated drivers are most likely the culprit. As to my experience, applications rarely cause system crashes. But be aware that some applications install nonhardware drivers (anti-virus software, encryption tools etc.).
On a newly installed system, you have to remove device by device to find the malfunctioning component. Disabling the corresponding drivers in the Device Manager is also an option. Sometimes it is the interaction of two components that causes the problem. I recently had an issue with Microsoft's Network Monitor and my Bluetooth driver. Both components were working perfectly on their own, but whenever the corresponding drivers were running at the same time, it was only a matter of minutes until my Vista box crashed.
Analyze Windows crash dump files ^
If you can't track down the culprit with the above mentioned methods, then the last resort is to analyze the crash dump memory file. By default, Windows dumps the memory to a file in the c:\Windows\Minidump folder whenever the blue screen of death appears. However, there are cases when Windows crashes so badly that even this doesn't work anymore. The dump file contains various bits of information that can be helpful in finding the cause of the crash. Unfortunately, usually only system developers are able to make sense of this information.
However, it can't be wrong if you have a look at the crash dump yourself. For this you have to download and install the Windows debugging tools. This KB article has a short introduction of how to open the dump file and how to configure crash dumping, and this page offers more links with further information about Windows debugging.
If you don't like to work on the command prompt, you can install the free (for private use) WhoCrashed tool that can display the most essential information in the crash dump file. But don't expect too much from this tool. I fed it with two Windows 7 dump files that my laptop created before I updated all my drivers. All it found is that ntoskrnl.exe was involved, but it wasn't able to identify the device driver that was the real cause. Note that the tool requires the abovementioned Windows debugging tools which are automatically installed when you launch the WhoCrashed setup program. There also is a professional version of WhoCrashed that enables you to remotely analyze dump files.