Sussing things out, they uploaded a "config" file that had a .sys extension that caused all the trouble.
.sys files are supposed to be protected system files and require specual privileges to touch. I imagine Crowdstrike requires some special type of Windows "root access" to operate effectively (like many antivirus packages) in order to detect and block low level attacks.
So where things likely went pear-shaped was Crowdstrike's QA process for config updates is possibly less stringent than core code updates. But because they were using .sys files it was actually given elevated privileges and gets installed during boot.
As for the actual bug, I expect it was either something like the sys file referencing itself or some sort of stack overflow somewhere, both of which I would pin on Microsoft for not being able to detect and recover from during boot up.
All of this is straight guesswork based solely on experience as a longtime Windows user.
>.sys files are supposed to be protected system files and require specual privileges to touch. I imagine Crowdstrike requires some special type of Windows "root access" to operate effectively (like many antivirus packages) in order to detect and block low level attacks.
Any file in C:\windows\ is protected by default and requires administrative privileges to modify. There isn't any extra protections for .sys files specifically.
>As for the actual bug, I expect it was either something like the sys file referencing itself or some sort of stack overflow somewhere, both of which I would pin on Microsoft for not being able to detect and recover from during boot up.
Since when is it the operating system's responsibility to recover from badly written kernel mode code?
How do you know which driver is responsible for the crash? It's all in kernel mode so everything is sharing the same address space. Even if you could determine that the crashed code belonged to a given driver, it's impossible to know whether that was responsible the crash, or some other driver called it with bad parameters. Even if you could get past all those problems, not loading a driver also comes with other problems. If the driver is required for some critical functionality, not loading the driver might cause other crashes. It also means you can disable an antivirus by getting to crash 3 times in a row.
.sys files are supposed to be protected system files and require specual privileges to touch. I imagine Crowdstrike requires some special type of Windows "root access" to operate effectively (like many antivirus packages) in order to detect and block low level attacks.
So where things likely went pear-shaped was Crowdstrike's QA process for config updates is possibly less stringent than core code updates. But because they were using .sys files it was actually given elevated privileges and gets installed during boot.
As for the actual bug, I expect it was either something like the sys file referencing itself or some sort of stack overflow somewhere, both of which I would pin on Microsoft for not being able to detect and recover from during boot up.
All of this is straight guesswork based solely on experience as a longtime Windows user.