-
Debugging crashdump
I'm trying to figure out why that pesky bluescreen occurred, but seeing as I haven't done it before, I'd like to see if anyone could give any good information as to where to start on debugging the cause of this.
Since, as usual, the screen did not provide any information about where the error occurred. The only thing I do know is
0x1000008e (0xc0000006, 0x8060bf81, 0x8a86d5dc, 0x00000000).
From what I'm told, it's a kernel exception.
Information would be appreciated.
-
0x1000008e is "kernel mode trap not handled", and 0xC0000006 means "STATUS_IN_PAGE_ERROR" (or "EXCEPTION_IN_PAGE_ERROR"), which seems to indicate a "not-present page" in general.
Edit:
0x8060bf81 = EIP at exception
0x8a86d5dc = Address being accessed.
0x00000000 = read/write flag (0 = read).
--
Mats
-
Does not help identify the culprit.
But I'm guessing it means something along the lines that the kernel was starved for memory or because something screwed up and tried to use pages memory.
-
The EIP at crash should be possible to use to identify the culprit, but you need the loaded symbol table at the time of the crash. If you have WinDBG you can load the minidump and type "!analyze -v" to give you that.
It may be that you are running low on memory and the page should be locked in memory, when it actually isn't, and thus gets paged out.
--
Mats
-
It's true that there was a process that was frozen and eating up all virtual memory, but... I hope this isn't a Windows bugs, but merely a driver who was inproperly coded.
I do, after all, have a whopping 3 GB of memory. It could easily page out something else.
-
If the driver writes weren't using the "make all unlocked memory unavailable" tool when writing the driver, it would seem a plausible explanation. I have yet to see Windows itself fail in this manner.
--
Mats
-
Seems the culprit is "Procmon11.sys", at least according to WinDbg. At least it isn't Windows. That's good news.
I'm uninstalling Process Monitor until they fix it.