I think if I understand the systems right Windows can roll back a bad driver update but the CS update wasn’t an update to the driver but instead updated a configuration file which CS updated outside of Windows Update. So from the Windows Update perspective the system started failing to boot with no changes to the system. Again though I don’t know if I totally understand what CS did and what capabilities Windows Update has.

No you can’t roll back bad driver updates in any OS, if you could then by definition they do not sit in the kernel space. You just want the security code to not run in kernel space, which is a decision MS could maybe make and become like Apple, though most security software would in that case rebel.

> No you can’t roll back bad driver updates in any OS, if you could then by definition they do not sit in the kernel space.

drivers and kernel binaries are typically installed and maintained by user space programs that run with some sort of elevated privileges.

"kernel space" is just a runtime context, what gets loaded into there typically comes ordinary (protected) files on the disk.

it depends on how bad. in Linux you can rmmod to get rid of the bad one if you haven't wedged it and fix your code, compile, and try again. I can't imagine that's actually different on windows if you know what you're doing. how do you think driver development happens?

That doesn't make any sense.

The OS loads file A into the kernel. It crashes. It reboots. It decides not to load file A this time.

Wow, it's a rollback of kernel-space code.

Unless your argument is that you can't guarantee a rollback of every possible kernel driver, because it might have installed a rootkit while it had full control? Okay, cool, but this isn't a malware removal idea. It's an idea for normal drivers.

Good explanation about this point at 11:15 over at https://youtu.be/wAzEJxOo1ts?si=wGXDJZtUczcIui9F

It was not a driver update.