I have to imagine it was a lot of long hours, and the testing was insane. The last thing I want to do is put this tool out and it somehow messes things up more.
But glad it’s out. Hopefully it helps with the remaining machines and with any that are being problematic.
Man was I always afraid and stressed that the tool meant to help users when they were already having a failure was also having a failure.
https://learn.microsoft.com/en-us/windows-hardware/manufactu...
Still, customizing the toolchain to fit this particular scenario and making sure it works, in two days, is commendable effort.
...on a weekend.
Under the immense pressures, I'm sure one or two of the usual steps were missed or reduced (perhaps this is what you were insinuating?)
No, they don't. This is the same company that has turned the Windows OS into an advertisement platform within the OS [0]. A company that puts buggy telemetry collection over their end users [1]. And a platform that is known to spy on its end users [2]. So, no - Microsoft really doesn't care about its end users with "higher quality assurance concerns". They care about turning a profit.
[0] https://www.theverge.com/2024/4/12/24128640/microsoft-window... [1] https://www.maketecheasier.com/fix-microsoft-compatibility-t... [2] https://www.techradar.com/news/is-windows-11-spying-on-you-n...
I've already heard from multiple non-technical people presenting this as a "Microsoft problem". "Omg, did you hear what Microsoft just did to their customers?". I don't know if CS subtly pulling strings to look less guilty, but probably just happens by simple association "blue screen of death = Windows problem". Can't image Microsoft is too happy to take this kind of a reputational hit.
This certainly happens. Before driver signing, an extremely common cause of BSODs was a page fault in the kernel caused by a driver bug that failed to lock down a page during I/O. Only if you had the hex codes of the various exceptions memorized would you be in a position to tell a driver-caused BSOD from some other cause. So.... "it must be Windows again". This was a powerful motivation for MSFT to start a driver validation lab that they forced vendors through.
And then... you have OS/2 -- where they actually used more than two security rings. Kernel in ring 0, user space in ring 3, and drivers in ring 1. Now the kernel can properly blame the driver. But of course, that can't be ported to CPU's with only 2 security levels.
They had no idea the two were probably the same vendor.
Also, while they're at it, add Trellex.
Also makes me wonder about a software configuration management system that operated on disks while the virtual hosts were powered down. With windows it feels like that'd be at least very difficult, but Linux could definitely be managed that way. Like an immutable operating system where changes can only come from the central controller, and the OS itself is written with that in mind. Dunno what benefit that might bring, but it's a fun mental excursion.
Worst case, I imagine you could boot to the bootloader menu, then scrape the unwrapped bitlocker key from RAM.
(I agree that the org that mandated cloudstrike would collectively lay an egg if they realized this was possible.)
Going forward, I could foresee Microsoft requiring endpoint protection solution providers certify their QA processes to get signing. But staged rollouts and canary builds have already been an industry standard process long before CrowdStrike. There was no way Microsoft could have known that they were dealing with a company so incompetent as CrowdStrike to cause this to happen.
