MEMORY_MANAGEMENT BSOD / Bugcheck Details

[cjsks]

Hi, I just bought a HP DV8T refurb, with Windows 7, 64-bit, i7 720 quad-core, 4gb ram (2 x 2gb). All of the "critical" windows updates are in. In the process of transferring files, loading software, etc., I've had a few BSOD "MEMORY_MANAGEMENT" errors.

I ran windows sfc /scannow, no issues. I ran a pass of memtest 3.4, before I realized there is a memtest 4.1. 3.4 didn't find any errors, but I plan on running 4.1 overnight tonight.

I installed WDK and loaded a few mini dmp files, but I don't know how to interpret... Could someone have a look?


Thanks!


*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000041287, The subtype of the bugcheck.
Arg2: 00000000000012d1
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
------------------

BUGCHECK_STR: 0x1a_41287
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
TRAP_FRAME: fffff88003d3f520 -- (.trap 0xfffff88003d3f520)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff98040f77009 rbx=0000000000000000 rcx=000000000000ff1a
rdx=0000000000005003 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80003139fcc rsp=fffff88003d3f6b0 rbp=fffff6fcc0123220
r8=fffff780c0000000 r9=00000000000012d1 r10=fffff780c0000488
r11=00000000000012d1 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt! ?? ::FNODOBFM::`string'+0x2a1ea:
fffff800`03139fcc e82f06f9ff call nt!KeBugCheckEx (fffff800`030ca600)
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80003076b6e to fffff800030ca600
STACK_TEXT:
fffff880`03d3f3b8 fffff800`03076b6e : 00000000`0000001a 00000000`00041287 00000000`000012d1 00000000`00000000 : nt!KeBugCheckEx
fffff880`03d3f3c0 fffff800`030c86ee : 00000000`00000000 00000000`670cc921 fffff8a0`00000100 fffffa80`0459c180 : nt! ?? ::FNODOBFM::`string'+0x42be5
fffff880`03d3f520 fffff800`03139fcc : 00000000`1e4c9921 fffff6fc`c0123218 00000000`00000018 fffff6fc`c0123280 : nt!KiPageFault+0x16e
fffff880`03d3f6b0 fffff800`030e756f : fffff6fc`c0123280 00000000`00000001 fffff880`00000010 ffffffff`ffffffff : nt! ?? ::FNODOBFM::`string'+0x2a1ea
fffff880`03d3f820 fffff800`0310eb8e : fffff980`24640000 00000000`00240000 fffff800`00000000 00000000`00000002 : nt!MmCheckCachedPageStates+0x3ef
fffff880`03d3f9d0 fffff800`0332ff4a : 00000000`035c0000 00000000`035c0000 00000000`00240000 00000000`00040001 : nt!CcFetchDataForRead+0x10e
fffff880`03d3fa30 fffff800`0307cb1c : fffffa80`0832d3b0 00000000`035c0000 00000000`00040000 fffff800`0326f501 : nt!CcMapAndCopyFromCache+0xba
fffff880`03d3fad0 fffff800`030be472 : fffffa80`07c83940 fffff880`03d3fc00 00000000`00000005 fffffa80`00000000 : nt!CcPerformReadAhead+0x3b8
fffff880`03d3fc00 fffff800`030d7861 : fffffa80`03d06ab0 fffff800`033c7804 fffff800`032d1150 fffffa80`00000002 : nt!CcWorkerThread+0x21e
fffff880`03d3fcb0 fffff800`0336fa86 : 00000100`00000000 fffffa80`03d02b60 00000000`00000080 fffffa80`03c75b30 : nt!ExpWorkerThread+0x111
fffff880`03d3fd40 fffff800`030a8b06 : fffff880`03b67180 fffffa80`03d02b60 fffff880`03b720c0 00000000`00000400 : nt!PspSystemThreadStartup+0x5a
fffff880`03d3fd80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb
FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+42be5
fffff800`03076b6e cc int 3
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+42be5
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4b88cfeb
FAILURE_BUCKET_ID: X64_0x1a_41287_nt!_??_::FNODOBFM::_string_+42be5
BUCKET_ID: X64_0x1a_41287_nt!_??_::FNODOBFM::_string_+42be5
Followup: MachineOwner
---------

 

[cjsks]

Had this one too, not sure if it's related or not...

...........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7F, {8, 80050033, 6f8, fffff800030d5e90}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
Followup: MachineOwner
---------
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050033
Arg3: 00000000000006f8
Arg4: fffff800030d5e90
Debugging Details:
------------------

BUGCHECK_STR: 0x7f_8
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 2
TRAP_FRAME: fffff880039f5fc0 -- (.trap 0xfffff880039f5fc0)
Unable to read trap frame at fffff880`039f5fc0
LAST_CONTROL_TRANSFER: from fffff800030d7469 to fffff800030d7f00
STACK_TEXT:
fffff880`039d9de8 fffff800`030d7469 : 00000000`0000007f 00000000`00000008 00000000`80050033 00000000`000006f8 : nt!KeBugCheckEx
fffff880`039d9df0 fffff800`030d5932 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`039d9f30 fffff800`030d5e90 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
fffff880`039f5fc0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x10

STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KiDoubleFaultAbort+b2
fffff800`030d5932 90 nop
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiDoubleFaultAbort+b2
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600
FAILURE_BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b2
BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b2
Followup: MachineOwner
---------

 

[cjsks]

Last but not least...



*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1A, {41287, 8948b043, 0, 0}
Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+42be5 )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000041287, The subtype of the bugcheck.
Arg2: 000000008948b043
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
------------------

BUGCHECK_STR: 0x1a_41287
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
TRAP_FRAME: fffff80000ba4d30 -- (.trap 0xfffff80000ba4d30)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff980105cb809 rbx=0000000000000000 rcx=00000000fffffffe
rdx=000000000000137b rsi=0000000000000000 rdi=0000000000000000
rip=fffff800030bc454 rsp=fffff80000ba4ec8 rbp=fffff80000ba4ec8
r8=fffff780c0000000 r9=0000000000004b6e r10=fffff780c0000488
r11=000000000000221b r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di ng nz na pe nc
nt!KiGeneralProtectionFault+0x14:
fffff800`030bc454 488945b0 mov qword ptr [rbp-50h],rax ss:0018:fffff800`00ba4e78=0000000000000000
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff8000306ab6e to fffff800030be600
STACK_TEXT:
fffff800`00ba4bc8 fffff800`0306ab6e : 00000000`0000001a 00000000`00041287 00000000`8948b043 00000000`00000000 : nt!KeBugCheckEx
fffff800`00ba4bd0 fffff800`030bc6ee : 00000000`00000001 00000000`2a25a921 00000000`00000000 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x42be5
fffff800`00ba4d30 fffff800`030bc454 : fffff780`c0000488 00000000`0000221b 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x16e
fffff800`00ba4ec8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiGeneralProtectionFault+0x14

STACK_COMMAND: kb
FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+42be5
fffff800`0306ab6e cc int 3
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+42be5
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4b88cfeb
FAILURE_BUCKET_ID: X64_0x1a_41287_nt!_??_::FNODOBFM::_string_+42be5
BUCKET_ID: X64_0x1a_41287_nt!_??_::FNODOBFM::_string_+42be5
Followup: MachineOwner
---------

 

[cjsks]

p.s. Ran memtest86+ v4.1, it completed 3 passes with no errors found. If anyone has any insight into the above dmp's, I'd appreciate it.

p.s.s. Also, just thought I'd mention that I've lost the video display a few times... always comes back within a few seconds, msg says something about nVidia was lost but has been found... What's the best way to test the GPU drivers and hardware?

Thanks again.

 

[cjsks]

One more quick update... I let memtest v4.1 completely finish (it stopped and windows rebooted after 5 passes I think is was up to).