|
|
|
|
|
|
by rdtsc
704 days ago
|
|
|
It's interesting Microsoft is dealing with this. I wonder how they feel about CS? Can't imagine they are happy with them. So I would guess it's less of "let's work with our friends at CS" and more like "Those $#%!, they made a mess and we're left to clean it up". 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.