[jborean93]

> having Windows roll back to the last known version of a driver/extension after a failed boot (or several)

One of the problems with CrowdStrike was the update was a definition/config file that was pushed out by CrowdStrike. There was no driver update and the BSOD was caused by the existing driver failing to parse/load the new file pushed out. This means there was no last known good state to rollback to in terms of driver updates.

Granted I still agree that MS can hopefully improve things to avoid this problem in the future but this isn't a simple problem that the OS can guard from short of stopping 3rd party kernel drivers.

[colmmacc]

For robust rollback you need an encapsulation of the full dependency closure that can be rolled forwards and backwards atomically. These days containers are a decent enough solution for that. Anything changes means everything changes, at the same time. We have the technology.

[M95D]

Remember the Windows safe mode? Remember F8 step-by-step confirmation for config.sys, autoexec.bat and .vxd drivers?

Why does it have to be automatic?

[perryizgr8]

> This means there was no last known good state to rollback to in terms of driver updates.

Windows should unload the misbehaving driver after a couple of failed boots.

[jborean93]

Sure I can agree with this (if it's actually viable to do). My reply was mostly to try and explain that the issue wasn't due to a driver update but rather an existing driver failing to work with a new file it was using hence why the last known good configuration feature didn't work.

[TiredOfLife]

So all a virus has to do is cause the driver to crash.

[perryizgr8]

If a virus has infiltrated the system to such an extent that it can crash a kernel mode driver then it's already game over.

[throwaway4pp24]

I really don't think so. Crashing the system is still a long way from controlling the system - no implication there.