Re: Illegal memory reference handler?
Except it did...
You've thrown an exception in ring 0, all bets at this point are now off. The safest way to deal with this is to die gracefully. If kernal exceptions are being thrown around *anything* could happen and you can't count that the system is going to behave the way it should. The best thing is to just shut down as best you can and tell the user it's all gone sideways. If you are throwing critical exceptions, in a priviledged, protected area of program space as this was, you need to die cleanly before you really break something.
If an illegal access was thrown and something bad(tm) has happened in kernal ram, how do you know the reference you have for what threw the exception is good? The stack may well be a pile of broken bits or even now pointed at arbitrary memory locations. Hell your illegal access may have been legal till something else did something stupid before. SO maybe we handle it incorrectly, tel the user that all is good, but the kernal is still screwed. User goes on, hits save on on something important and it turns out the process we handled wasn't the cause and boom, there goes the file or even the whole filesystem. What if this is the first sign of bad RAM? Bad RAM can destroy the software on a machine pretty damn quickly, once filesystem caches start getting nerfed the fun really startes.
Every single modern OS does just the same thing. I beleive on a Linux update of Crowdstrike this exact thing DID happen.
The issue here was that MS put in a LOT of ground work to stop drivers buggering about with things, issued certification and along come Crowdstrike, totally sidestep this process, and have thaier "driver" load unsigned, un tested (and aparaently, with no QA) code into ring 0, something that's not supposed to be done. And on top of that aparently they do no sanity/bounds checking loading that unsigned code.
Much as I hate it, MS have done their best here and Crowdstrike just jumped the guard rails.