An exercise in de-analysis[15]
This is a free floating explanation based on loose associations. Its extreme version uses G∥del incompleteness theorems (undecidable crashes and hangs), quantum mechanics (in small time delta any bug can appear and disappear without being caught) or hydrodynamics (code fluidity, turbulence around processor cores) for abnormal software behaviour explanation (similar to Fashionable Nonsense[16] in philosophy, humanities and social sciences). Its milder version is slightly modified original analysis monologue we found when searching Google for stack traces (we provide our comments below):
"Two hints make me assume this can be a physical memory problem:"
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: e37cc20e, memory referenced.
Arg2: 00000001, value 0 = read operation, 1 = write operation.
Arg3: 8083fe2c, If non-zero, the instruction address which referenced the bad memory address.
Arg4: 00000000, (reserved)
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
We wouldn't be so quick. Check Hardware Error pattern (Volume 2, page 221). So let's de-analyze the analysis.
"c0000005 is Access Denied where C is virtual memory, meaning usually disk cache"
"c" is just STATUS_SEVERITY_ERROR (0×3 or 0y11) 11000000000000000000000 000000101 and doesn't have any connection to cache or crash beyond a mere coincidence. See NTSTATUS bit descriptions[17].
"It could be RAM and/or it could be savrt.sys if you're using something like an antivirus. Check to see if you need updates for them, Norton, Symantec, McAfee."
Of course, it is either RAM or antivirus, what else? What about a virus? All are household names.
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". "The memory could not be "%s"." means there is something wrong with the debugger itself; those should be addresses, not percent signs and alphanumeric garbage."
Now even a debugger is corrupt. RAM again? It's not an ASCII garbage; they're format codes (like for printf C function) to print actual addresses.
"8083fe2c" this address called a pointer, it referenced "e37cc20e" again, that "e" has specific meaning, some virtual device or another, probably CD ROM, trying to transfer data to RAM. This implies either SCSI or PCI buss or DMA buss timing problems."
RAM again... Evidence mounts stronger and stronger. It's all about timing. A bus buzzes.
"Which is usually caused by a bad driver, not RAM, but sometimes replacing the RAM "masks" out the failure."
You never know... Having a bit of doubt?
"This normally happens with 64-bit machines that take advantage of the 64-bit superfast address access and indexing, known as Vector Indirect Addressing, which is, apparently, too fast for even recent Operating System code."
We always suspected these machines run ×64 times faster... we can only imagine horrors when Vector Indirect Addressing hits an old Operating System code. However, the crash under discussion is ×86...
"A write to the "e" device; so, is it some kind of CDR or DVDR or other storage device?"
I guess that was a rhetorical question... or let me finish this thread of thought to connect dots, e-devices, virtual memory, disk cache and CD ROM. What if a page file was configured on a DVD-R?