Microsoft acknowledged a bug in its Desktop Bridge technology last night that could crash Windows 10 with the error KERNEL_SECURITY_CHECK_FAILURE and potentially put your machine into an endless boot loop.
You may recall that Desktop Bridge (previously Project Centennial) is a new feature in Windows 10 Anniversary Update that allows developers to take Win32 and .NET apps and plug them into the Universal Windows Platform and ship them via the Windows Store.
I used this technology to get handy utility EarTrumpet into the Windows Store last month. It’s fantastic stuff.
But it’ll be even better when it’s safer to use.
Right now, simply launching an affected app – like EarTrumpet, Kodi, Tweeten, Arduino IDE, or Evernote – could crash your machine. Or they could work for a while and crash the machine later. Worse, if any of those apps are configured to start at boot, you could end up in an endless reboot-crash-reboot cycle.
Users running Windows 10 and the latest AMD Catalyst drivers represent the popular class of folks having the issue. But the problem isn’t specific to AMD customers. It could snag you via another driver that Microsoft hasn’t seen yet.
Looking at the crash dumps I’ve received from EarTrumpet users, it seems the issue boils down to some bad assumptions made by both driver makers and Microsoft surrounding registry access from kernel space.
Driver makers, for example, are still accessing the registry (via RtlQueryRegistryValues) in a manner that hasn’t been safe for several years. But that dusty code may not have been updated because the operating system wasn’t moving around the registry cheese, so to speak. Assumptions held true and everything worked great until now.
Microsoft should have found this in its testing. But the feature didn’t get a lot of attention because it shipped non-functional Desktop Bridge tooling in many of its Windows Insider builds, and apps built on the stuff weren’t allowed in the Store until last month. (Though, it’s not clear Windows Insider testing would have caught this issue due to the low variability of machine configurations. Ars Technica’s Peter Bright has written about this topic great length and it is worth a read.)
Hindsight is 20/20, of course. And there is some good news to be had here: Microsoft already fixed the issue internally. You should see a fix go out to Windows Insiders very soon and, barring any issues, to everyone else this month.
I’ll follow up with an all-clear when that happens.