As Günter Born recently reported at Born’s Tech and Windows World, KB4592438 has a bug that triggers a blue screen of death when you run the chkdsk c: /f command, leaving the hardware unable to boot. Several others confirmed the issue independently in the various venues and forums. Still others graciously decided to risk their systems and install the update and when they ran the command had zero issues. I tested it myself and also didn’t see a blue screen of death.
So, what is a patcher to do? Install an update that might cause issues? Or don’t install updates and risk attacks?
It’s a conundrum that points to the problem with patches: they aren’t always perfect. In fact, most of the time patches are not perfect. But they’re good enough for the majority of those that install patches.
In this specific case, there is also conflicting information that the chkdsk command should not be used on SSD drives in general. While I love the speed benefits from SSD drives, I make sure I have a full image of the hard drive for any key machine I might need to put back into production quickly. I literally have experienced an abrupt SSD hard drive failure and had to quickly swap in a new drive and restore the machine from backup. It is also why I keep a spare supply of SSD hard drives for emergencies. SSD drives can and do suddenly stop working. Plan accordingly.
When you see issues with patches reported online, unless the update problems are widespread and damaging to systems, Microsoft typically does not block or remove patches. If you have opted into Microsoft telemetry, each time an update successfully installs and your system reboots, Microsoft receives that information and knows the system survived the experience.
Over the years, Microsoft has made it harder for users to block telemetry. Recently, it even started flagging the use of hosts files as a security issue if you attempt to use them to block telemetry. This process of reporting issues with updates is one reason that I encourage enabling telemetry. I want Microsoft to know about the pain it’s caused with updates. In fact, many years ago, Microsoft EU put together a funny video called “We feel your pain” about its supposed feedback program. (In the spoof video, feedback buttons allow you to give direct physical pain to the exact developer who coded the part of the program that gave you pain.)
While the telemetry in Microsoft doesn’t provide that level of feedback to the developers (sadly), it does provide Microsoft with a big-picture view of updates. But it can’t highlight the corner case issues where installed updates are sporadically problematic. Someone’s computer does not boot. Another person sees slow booting. Or someone has a game that will not run properly. There are issues, but not for everyone.
In this specific case, it appears that some group policy setting is triggering a blue screen issue for some — but not all — computers. And because of telemetry, even Microsoft is aware of it. On Monday, it noted in the known-issues section that a fix would be pushed out to anyone who receives their updates from Windows update. Microsoft explained:
“This issue is resolved and should now be prevented automatically on non-managed devices. Please note that it can take up to 24 hours for the resolution to propagate to non-managed devices. Restarting your device might help the resolution apply to your device faster. For enterprise-managed devices that have installed this update and encountered this issue, it can be resolved by installing and configuring a special Group Policy.”
Clearly some adjustment is needed on an unknown number of Windows machines. And therein lies the big problem with the Windows ecosystem: Even though we have had Windows for years, it’s still a very vast and messy ecosystem of hardware vendors, multiple drivers, and software vendors that often build their solutions on something undocumented. Microsoft over the years has clamped down on this “wild west” approach and mandated certain developer requirements. It’s one of the main reasons I strongly recommend that if you want to be in the Insider program or install feature releases on the very first day they are released, that you use Windows Defender as your antivirus, and not something from a third party.
While Microsoft will often follow up with a fix for a patch problem, typically — unlike this issue — it is not released in the same fashion as the original update. Case in point: in November, Microsoft released an update that impacted Kerberos authentication and ticket renewal issues. Later last month, on Nov. 19, it released an out-of-band update for the issue. The update was not released to the Windows update release channel, nor on the Windows Software Update Servicing release channel; instead IT administrators had to manually seek it out and download it or insert it into their WSUS servers.
Bottom line, since Microsoft rarely pulls a patch, here’s how to keeping systems up and running:
- Limit third-party security software. I limit mine, so if I have a machine that’s going to be on the latest feature release when it comes out, I only use Windows Defender. If you use third-party antivirus or multiple antivirus products (such as an antivirus and an anti-malware) I recommend you Windows 10 Professional version and defer feature releases. Always check with your antivirus vendor to see what Windows 10 version they support. Don’t assume they will support a new release on day one.
- Don’t overclock the machine or use any third party software that boosts the performance (or claims to). Often, I see interaction with performance-enhancing software that causes issues.
- Computer games. If you play computer games, also be aware of potential unwelcome In particular, I have seen issues related to game licensing or anti-cheating software.
- Dual booting. As much as many of us love to create dual-boot machines, this is something that can trigger issues. I recommend only doing dual booting if you are an expert user — and ensure you have a backup of the system.
- Watch for other updates that could be impacting your system. Windowslatest reports that KB4592438 when installed with Intel Driver & Software Assistant Tool (DSA) may trigger high CPU usage. Always remember what else you’ve installed along with the main Windows patch and see if it’s the other thing that’s triggered an issue.
- Install video driver updates and BIOS updates. At one point, I would install BIOS updates when I first purchased a computer or laptop and never ever installed BIOS updates after that point. Now, before each feature release, I make sure that my systems have up-to-date BIOS patches installed. I have not had a failure in installing BIOS updates.
- Coincidences do occur. From my experience, sometimes when a system reboots, it can expose and trigger an underlying issue. The problem may not be the update but rather a reboot. For many years, the best practice — especially for servers — was to reboot a system before installing updates to ensure that the system was healthy before the update is installed.
Next week, you’ll see that I’ll still recommend that you install KB4592438. By the time you receive the update, you’ll also receive the fix for the CHKDSK issue and all will be well — proving again that waiting minimizes the risk of the cranky patches and balances it with the risk from attacks.
