BSOD fix anyone?

Tidester · July 21, 2018

Dump file:


DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000018, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
Arg4: 0000000000000018, address which referenced memory

Debugging Details:
------------------

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
 0000000000000018 

CURRENT_IRQL:  2

FAULTING_IP: 
+0
00000000`00000018 ??              ???

PROCESS_NAME:  System

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  AV

BAD_PAGES_DETECTED: efc8

TRAP_FRAME:  fffffb87eb38f3b0 -- (.trap 0xfffffb87eb38f3b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffffb87eb38fbc0
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000018 rsp=fffffb87eb38f540 rbp=fffffb87eb38f540
 r8=ffffb38155143180  r9=0000000000000000 r10=0000000000000001
r11=0000000000000020 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
00000000`00000018 ??              ???
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff802e9da8f69 to fffff802e9d98430

FAILED_INSTRUCTION_ADDRESS: 
+0
00000000`00000018 ??              ???

STACK_TEXT:  
fffffb87`eb38f268 fffff802`e9da8f69 : 00000000`0000000a 00000000`00000018 00000000`00000002 00000000`00000008 : nt!KeBugCheckEx
fffffb87`eb38f270 fffff802`e9da5be5 : ffffb381`55143180 ffffe280`32d1a200 fffffb87`eb38f4c0 fffff802`ea563df5 : nt!KiBugCheckDispatch+0x69
fffffb87`eb38f3b0 00000000`00000018 : ffffb381`55479180 ffffb381`55489100 ffffe280`3adaf700 ffffb381`55489100 : nt!KiPageFault+0x425
fffffb87`eb38f540 ffffb381`55479180 : ffffb381`55489100 ffffe280`3adaf700 ffffb381`55489100 00000000`00000001 : 0x18
fffffb87`eb38f548 ffffb381`55489100 : ffffe280`3adaf700 ffffb381`55489100 00000000`00000001 fffff802`ff91ba00 : 0xffffb381`55479180
fffffb87`eb38f550 ffffe280`3adaf700 : ffffb381`55489100 00000000`00000001 fffff802`ff91ba00 00000000`00000000 : 0xffffb381`55489100
fffffb87`eb38f558 ffffb381`55489100 : 00000000`00000001 fffff802`ff91ba00 00000000`00000000 fffff802`e9d9f106 : 0xffffe280`3adaf700
fffffb87`eb38f560 00000000`00000001 : fffff802`ff91ba00 00000000`00000000 fffff802`e9d9f106 00000000`00000001 : 0xffffb381`55489100
fffffb87`eb38f568 fffff802`ff91ba00 : 00000000`00000000 fffff802`e9d9f106 00000000`00000001 ffffe280`3a801a90 : 0x1
fffffb87`eb38f570 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : dxgmms2!VidSchiReleaseSyncObjectReference+0x10


STACK_COMMAND:  kb

SYMBOL_NAME:  PAGE_NOT_ZERO

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

BUCKET_ID:  PAGE_NOT_ZERO

Followup: MachineOwner
---------

 *** Memory manager detected 61384 instance(s) of page corruption, target is likely to have memory corruption.

This free analysis is provided by OSR Open Systems Resources, Inc.
Want a deeper understanding of crash dump analysis? Check out our Windows Kernel Debugging and Crash Dump Analysis Seminar (opens in new tab/window)

TetraSky · July 21, 2018

Sound like a memory issue to me. Either that or a highly unstable overclock that cause memory issues.

If you've overclock, I suggest dialing it down.

After that starts the long and boring troubleshooting phase.

If after dialing back your overclock, you're no longer experiencing a BSOD, it means that was the problem.

If you still do(or if you hadn't overclocked), it might be a bad stick of RAM.

In which case you will need to identify which stick exactly is causing issues by testing each individual sticks one by one, for 8 to 12 hours, using Memtest.

_{Or Prime95 Blend for two or three hours and input all available ram (see in task manager). But that's only if you have adequate cooling for your CPU.}

I suggest testing with all your RAM sticks first, to make sure it's actually the RAM in the first place. (If you have more than 16GB total of RAM, consider letting the test run for 24h or until an error shows up)

Once a bad stick of RAM has been ID, I suggest putting a tiny piece of easily removable tape that preferably doesn't leave residue behind, on a metal part of the heatspreader(like painters tape), so as to not "lose sight of it" among your other, probably still working stick(s) of RAM... wouldn't want to have to redo all the tests because you don't remember which stick it was, right?

Then, see if the RAM is still under warranty (most RAM these days have a Lifetime Warranty, but depending on the manufacturer, that may not apply), RMA it and get a new stick. Easy right?

Tidester · July 21, 2018

17 minutes ago, TetraSky said:

Sound like a memory issue to me. Either that or a highly unstable overclock that cause memory issues.

If you've overclock, I suggest dialing it down.

After that starts the long and boring troubleshooting phase.

If after dialing back your overclock, you're no longer experiencing a BSOD, it means that was the problem.

If you still do(or if you hadn't overclocked), it might be a bad stick of RAM.

In which case you will need to identify which stick exactly is causing issues by testing each individual sticks one by one, for 8 to 12 hours, using Memtest.

_{Or Prime95 Blend for two or three hours and input all available ram (see in task manager). But that's only if you have adequate cooling for your CPU.}

I suggest testing with all your RAM sticks first, to make sure it's actually the RAM in the first place. (If you have more than 16GB total of RAM, consider letting the test run for 24h or until an error shows up)

Once a bad stick of RAM has been ID, I suggest putting a tiny piece of easily removable tape that preferably doesn't leave residue behind, on a metal part of the heatspreader(like painters tape), so as to not "lose sight of it" among your other, probably still working stick(s) of RAM... wouldn't want to have to redo all the tests because you don't remember which stick it was, right?

Then, see if the RAM is still under warranty (most RAM these days have a Lifetime Warranty, but depending on the manufacturer, that may not apply), RMA it and get a new stick. Easy right?