What kind of information would you like to see? NT4, Win2k and Windows XP dumped all the info including the CPU registers, but I don’t think anyone did anything about it.

At the time of error checking, Windows doesn’t have the context most people are looking for. It doesn’t necessarily know which driver or hardware device is causing the problem, so it can’t indicate either. Most of the BSODs I had in the kernel itself turned out to be driver issues anyway, and one or two of the Intel blue network boot screens turned out to be caused by a bug in a piece of software I was using to collect network stats. If Windows starts stating “I think this is” in those cases, it will be of absolutely no use.

If you want to solve the problem yourself (assuming the problem is more common), you can run a minidump through a debugger like windbg, run WhoCrashed which does it automatically, or use kd via the command line to extract the necessary data. This is easier with consistent crashes if you enable a full memory dump (rather than a minidump which is generated by default). I usually do this on consistent blue screens and I can tell you that once or three times I got jammed and some RAM got out of hand, you can’t do anything about it. This could be bad RAM, unstable overclocking, bad motherboard, bad PSU, write corruption, or a software bug in any possible driver.

Blue death is the last resort. Unless you have some knowledge about how the Windows kernel works, you can’t do anything with it. As far as I know it still shows a STOP icon that you can look up on MSDN (in the example SESSION1_INITIALIZATION_FAILED, a manual bug check that only records the response code for an internal API) but if you can’t manage that, the chance of solving it yourself is very slim. This is why Windows sends things like this to MS so that someone in many similar crashes can check the error with a debugger and distribute an update (or ask the manufacturer to fix their driver).

See also Linux kernel panic: you get a stack trace, a log dump, a memory dump, and sometimes even a partial decompilation of the last instructions that failed. Does this help me as an end user? No, not really. I can search for the driver that appears to have the error (which is not always the driver that has the error, as when the heap is broken) and I can try to think with the assembly which should have been a line of code, but I’m not a kernel developer, and I don’t have access To the binary points some devices need, and it shouldn’t be my job as a user to fix this, at most to report it.

[Reactie gewijzigd door GertMenkel op 13 november 2021 15:34]