But the offending module is not necessarily the module listed in the BSOD. It could be a victim too, one that got its memory corrupted by someone else.

That's one reason why they removed it, because it was causing end users to blame vendors/MS when they often had nothing to do with whatever the problem was.

That edge case is certainly their official excuse.

Ultimately to determine the underlying root-cause you'd still need to dig this same information out, and all they've done is moved the starting line behind several walls. In essence adding extra work, without solving this edge case/issue.

Regardless of if the information is in the BSOD, Event Log, or only via WinDbg, understanding the information relies on the expertise of the person reviewing/contextualizing it. They've gone out of their way to make contextualizing it harder.

For example, to determine if it is a direct failure or an associative failure (e.g. RAM failing causing different BSODs in unrelated modules), you want that context to be obvious. But without the module being in the Event Logs, you're now loading up half a dozen MiniDumps in WinDbg to find that same very key information - which people may miss or fail to do.

What I am saying is: If we believe that excuse (which I don't), they've done absolutely nothing to address it and just made that same problem worse with their childish games.

while not root cause, wouldn’t a module having corrupted memory still be an issue with either the OS (for not protecting it) or the module (for not sanitizing input)?