I was actually inclined to agree with Harry (as usual) that software was a possibility as well, but since you've just attached the latest crash dumps, I now don't think so. Here's why:
PAGE_FAULT_IN_NONPAGED_AREA (50) bug check as we've seen.
This indicates that invalid system memory has been referenced.
Bug check 0x50 usually occurs after the installation of faulty hardware or in the event of failure of installed hardware (usually related to defective RAM, be it main memory, L2 RAM cache, or video RAM).
Another common cause is the installation of a faulty system service.
Antivirus software can also trigger this error, as can a corrupted NTFS volume.
BugCheck 50, {
fffffa806589b700, 0,
fffff803fd7133d4, 2}
^^ Address
fffffa806589b700 was written to by the instruction at address
fffff803fd7133d4.
Code:
6: kd> r cr2
cr2=[COLOR=#ff0000]fffffa806589b700[/COLOR]
^^ The 1st parameter address was stored in cr2 prior to calling the page fault handler.
Code:
6: kd> !pte fffffa806589b700
VA fffffa806589b700
PXE at FFFFF6FB7DBEDFA8 PPE at FFFFF6FB7DBF5008 PDE at FFFFF6FB7EA01960 PTE at FFFFF6FD4032C4D8
contains 000000021EFFF863 contains 0000000000000000
GetUlongFromAddress: unable to read from fffff803fd9e20e4
pfn 21efff ---DA--KWEV [COLOR=#ff0000]not valid[/COLOR]
^^ We can see from the above that the address
fffffa806589b700 is indeed invalid. With this said, why did
fffffa806589b700 attempt to write to
fffff803fd7133d4?
Given this is not a kernel-dump, we cannot kv to check the trapfame on a pagefault. We can try and dump the registers for the bugcheck:
Code:
6: kd> r
rax=0000000000000002 rbx=0000000000000000 rcx=0000000000000050
rdx=fffffa806589b700 rsi=fffff88002f32660 rdi=0000000000000000
rip=fffff803fd6e4440 [COLOR=#4b0082]rsp=fffff88002f324f8[/COLOR] rbp=fffff88002f32611
r8=0000000000000000 r9=fffff88002f326e0 r10=fffffa8006705700
r11=fffffa806589b700 r12=0000000000000000 r13=fffff88002f326e0
r14=0000000000000000 r15=fffffa806589b700
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000246
nt!KeBugCheckEx:
[COLOR=#006400]fffff803`fd6e4440[/COLOR] 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:[COLOR=#a52a2a]fffff880`02f32500[/COLOR]=0000000000000050
^^ On the instruction we failed on, address
fffff803`fd6e4440 deferenced
rsp where
rsp is
fffff88002f324f8. All of this would result in a memory write to the address
fffff880`02f32500.
Code:
6: kd> !pte fffff880`02f32500
VA fffff88002f32500
PXE at FFFFF6FB7DBEDF88 PPE at FFFFF6FB7DBF1000 PDE at FFFFF6FB7E2000B8 PTE at FFFFF6FC40017990
contains 00000002189A5863 contains 00000002189A4863 contains 0000000001E78863 contains 80000000031D0963
GetUlongFromAddress: unable to read from fffff803fd9e20e4
pfn 2189a5 ---DA--KWEV GetUlongFromAddress: unable to read from fffff803fd9e20e4
pfn 2189a4 ---DA--KWEV GetUlongFromAddress: unable to read from fffff803fd9e20e4
pfn 1e78 ---DA--KWEV GetUlongFromAddress: unable to read from fffff803fd9e20e4
pfn 31d0 -G-DA--KWEV
Code:
6: kd> dd fffff880`02f32500
fffff880`02f32500 00000050 00000000 6589b700 fffffa80
fffff880`02f32510 00000000 00000000 02f326e0 fffff880
fffff880`02f32520 00000002 00000000 065eb840 fffffa80
fffff880`02f32530 00ff64e4 fffff880 06705700 fffffa80
fffff880`02f32540 02f32611 fffff880 0000007f 00000000
fffff880`02f32550 00000001 00000000 fd7c3acf fffff803
fffff880`02f32560 00000000 00000000 080e2080 fffffa80
fffff880`02f32570 02f32600 fffff880 00000000 00000000
Right, so the code wanted to write to
fffff880`02f32500 which as we can see above is a completely valid address. The 1st parameter and cr2 however note we failed writing to address
fffffa806589b700. This does not make sense, and is essentially not logically possible.
The hardware was told to write to
fffff880`02f32500, and the hardware came back and said 'I cannot write to
fffffa806589b700'. Another way to think about it is if you kindly asked the waiter of your table for more water, he writes it down, but comes back and says 'I'm sorry, but we're all out of coffee'.
Also, this was a verifier enabled crash dump -- DEFAULT_BUCKET_ID:
VERIFIER_ENABLED_VISTA_MINIDUMP
Code:
Verify Level 2092b ... enabled options are:
Special pool
Special irql
All pool allocations checked on unload
Deadlock detection enabled
Security checks enabled
Miscellaneous checks enabled
Summary of All Verifier Statistics
RaiseIrqls 0x0
AcquireSpinLocks 0xfbf4b4
Synch Executions 0x124b88
Trims 0xa77
Pool Allocations Attempted 0x28395e
Pool Allocations Succeeded 0x28395e
Pool Allocations Succeeded SpecialPool 0x28395e
Pool Allocations With NO TAG 0x26
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0
Current paged pool allocations 0xa8 for 00100740 bytes
Peak paged pool allocations 0xbc for 002387F0 bytes
Current nonpaged pool allocations 0x6eb9 for 0099F300 bytes
Peak nonpaged pool allocations 0x6f4f for 009B0B08 bytes
With this said, I believe best course of action should be to run Memtest for NO LESS than ~8 passes (several hours):
Memtest86+:
Download Memtest86+ here:
Memtest86+ - Advanced Memory Diagnostic Tool
Which should I download?
You can either download the pre-compiled ISO that you would burn to a CD and then boot from the CD, or you can download the auto-installer for the USB key. What this will do is format your USB drive, make it a bootable device, and then install the necessary files. Both do the same job, it's just up to you which you choose, or which you have available (whether it's CD or USB).
Do note that some older generation motherboards do not support USB-based booting, therefore your only option is CD (or Floppy if you really wanted to).
How Memtest works:
Memtest86 writes a series of test patterns to most memory addresses, reads back the data written, and compares it for errors.
The default pass does 9 different tests, varying in access patterns and test data. A tenth test, bit fade, is selectable from the menu. It writes all memory with zeroes, then sleeps for 90 minutes before checking to see if bits have changed (perhaps because of refresh problems). This is repeated with all ones for a total time of 3 hours per pass.
Many chipsets can report RAM speeds and timings via SPD (Serial Presence Detect) or EPP (Enhanced Performance Profiles), and some even support changing the expected memory speed. If the expected memory speed is overclocked, Memtest86 can test that memory performance is error-free with these faster settings.
Some hardware is able to report the "PAT status" (PAT: enabled or PAT: disabled). This is a reference to Intel Performance acceleration technology; there may be BIOS settings which affect this aspect of memory timing.
This information, if available to the program, can be displayed via a menu option.
Any other questions, they can most likely be answered by reading this great guide here:
FAQ : please read before posting
especially with the IRQL Level being Passive, so we're not experiencing any interrupt level problems.
Code:
4: kd> [COLOR=#008000]!irql[/COLOR]
Debugger saved IRQL for processor 0x4 -- [COLOR=#ff0000]0[/COLOR] (LOW_LEVEL)
I've recently read on the ntdebugging blog that according to Windows Internals 4th edition, despite what !irql reports, in most cases it's not properly saved at the time of the crash, especially in minidumps.
Windows Internals 4th Edition notes that IRQL may not be saved; this explains the 0
Regards,
Patrick
