I worked on one of the Windows Error Reporting (WER) server components that detected memory corruption from bluescreen memory dumps submitted to the WER service. It's a debugger extension called !chkimg (http://msdn.microsoft.com/en-us/library/windows/hardware/ff5...). It compares the executable code in the memory dumps with the actual binaries that Microsoft shipped and flags differences between the two. This way you can tell what code was actually running on the machine vs what it should have been running. It was quite effective at detecting corruption patterns this way. Usually one-bit corruptions (just a single bit flip) and stride patterns (i.e. one corruption after every 4, 8, 16 or 32 bytes etc) were a good indicator of hardware problems.
I worked on one of the Windows Error Reporting (WER) server components that detected memory corruption from bluescreen memory dumps submitted to the WER service. It's a debugger extension called !chkimg (http://msdn.microsoft.com/en-us/library/windows/hardware/ff5...). It compares the executable code in the memory dumps with the actual binaries that Microsoft shipped and flags differences between the two. This way you can tell what code was actually running on the machine vs what it should have been running. It was quite effective at detecting corruption patterns this way. Usually one-bit corruptions (just a single bit flip) and stride patterns (i.e. one corruption after every 4, 8, 16 or 32 bytes etc) were a good indicator of hardware problems.