HELP! constant blue screens, can't find a solution

[D4M4GED]

Hey,

I've been having blue screen errors for months now, pretty infrequently, seemingly randomly.

I'm on a pc that I built years ago, and I haven't had issues with it for years, until now.

its an:
- asrock 990fx extreme9 motherboard
- 8 Gb corsair vengeance RAM
- OCZ agility 60Gb SSD for the OS, and a 1Tb storage drive, another 60Gb ocz agility SSD for storage and an old 120Gb drive for more storage,
- HIS Radeon 7970 3Gb GDDR5 GPU

I have tried all the obvious stuff like updating drivers, doing system file checker, clean windows installs, windows is up to date, pretty much everything i can think of, what I'm hoping for now is for someone to have a look at my dump files, and give me a better idea of what is wrong.

the most common blue screen errors are "IRQL_NOT_LESS_OR_EQUAL_TO" and "SYSTEM_SERVICE_EXCEPTION"

thanks in advance!

here are a few of my most recent dump files:

crash dump 1:

Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 8 Kernel Version 10586 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 10586.672.amd64fre.th2_release_sec.161024-1825
Machine Name:
Kernel base = 0xfffff803`6b81e000 PsLoadedModuleList = 0xfffff803`6bafbcd0
Debug session time: Mon Dec 12 05:25:30.362 2016 (UTC - 5:00)
System Uptime: 1 days 1:04:11.796
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000084080, memory referenced
Arg2: 00000000000000ff, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8036b8a7ca8, address which referenced memory

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

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:

Use '!findthebuild' command to search for the target build information.

If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: fffff8036b81e000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 580ef0e6

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
0000000000084080

CURRENT_IRQL: 0

FAULTING_IP:
nt!KeInsertQueueDpc+bc8
fffff803`6b8a7ca8 440f0000 sldt word ptr [rax]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

LAST_CONTROL_TRANSFER: from fffff8036b96b4e9 to fffff8036b960970

STACK_TEXT:
fffff803`6d45f5e8 fffff803`6b96b4e9 : 00000000`0000000a 00000000`00084080 00000000`000000ff 00000000`00000000 : nt!KeBugCheckEx
fffff803`6d45f5f0 fffff803`6b969cc7 : ffffe000`04981d01 ffffe000`00000008 00000000`00000000 00000000`00000000 : nt!setjmpex+0x3c99
fffff803`6d45f730 fffff803`6b8a7ca8 : ffffe000`02494ef0 ffffe000`04d7e010 ffffe000`04d7e320 fffff803`6bb3a180 : nt!setjmpex+0x2477
fffff803`6d45f8c0 fffff803`6b8a75a9 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeInsertQueueDpc+0xbc8
fffff803`6d45fa10 fffff803`6b96372a : 00000000`00000000 fffff803`6bb3a180 fffff803`6bbb0740 ffffe000`0803d500 : nt!KeInsertQueueDpc+0x4c9
fffff803`6d45fc60 00000000`00000000 : fffff803`6d460000 fffff803`6d45a000 00000000`00000000 00000000`00000000 : nt!KeSynchronizeExecution+0x210a


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KeInsertQueueDpc+bc8
fffff803`6b8a7ca8 440f0000 sldt word ptr [rax]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt!KeInsertQueueDpc+bc8

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntkrnlmp.exe

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner


Crash dump 2:



Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (http://www.osr.com)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 8 Kernel Version 10586 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 10586.672.amd64fre.th2_release_sec.161024-1825
Machine Name:
Kernel base = 0xfffff802`dc690000 PsLoadedModuleList = 0xfffff802`dc96dcd0
Debug session time: Mon Nov 21 00:21:57.673 2016 (UTC - 5:00)
System Uptime: 1 days 10:07:14.439
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc000001d, The exception code that was not handled
Arg2: fffff802dc719fe8, The address that the exception occurred at
Arg3: ffffe001b3eef080, Parameter 0 of the exception
Arg4: fffff802dc690000, Parameter 1 of the exception

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

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_EXCEPTION_POINTERS ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:

Use '!findthebuild' command to search for the target build information.

If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: fffff802dc690000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 580ef0e6

EXCEPTION_CODE: (NTSTATUS) 0xc000001d - {EXCEPTION} Illegal Instruction An attempt was made to execute an illegal instruction.

FAULTING_IP:
nt!KeInsertQueueDpc+f08
fffff802`dc719fe8 16 ???

EXCEPTION_PARAMETER1: ffffe001b3eef080

EXCEPTION_PARAMETER2: fffff802dc690000

ERROR_CODE: (NTSTATUS) 0xc000001d - {EXCEPTION} Illegal Instruction An attempt was made to execute an illegal instruction.

BUGCHECK_STR: 0x1e_c000001d

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff802dc84fc7e to fffff802dc7d2970

FAILED_INSTRUCTION_ADDRESS:
nt!KeInsertQueueDpc+f08
fffff802`dc719fe8 16 ???

STACK_TEXT:
fffff802`de234a48 fffff802`dc84fc7e : 00000000`0000001e ffffffff`c000001d fffff802`dc719fe8 ffffe001`b3eef080 : nt!KeBugCheckEx
fffff802`de234a50 fffff802`dc7d8a1d : fffff802`dc9c0000 fffff802`dc690000 0004c500`007ca000 00000000`00000000 : nt!KeRegisterNmiCallback+0x14a
fffff802`de234a90 fffff802`dc6fa559 : 00000000`00000000 00000000`000000e9 fffff802`de235090 00000000`00000000 : nt!_chkstk+0x5d
fffff802`de234ac0 fffff802`dc78204c : fffff802`de2359d8 fffff802`de2356f0 fffff802`de2359d8 00000000`00000001 : nt!RtlCaptureStackBackTrace+0x4c5
fffff802`de2351c0 fffff802`dc7dd5c2 : ffffe001`b1f656d4 ffffe001`b2f75050 00000000`00000000 ffffe001`b4ba7a20 : nt!KeSaveExtendedProcessorState+0x86c
fffff802`de2358a0 fffff802`dc7db2c6 : ffffd000`22ff0a64 00000000`00000000 00000000`00000000 00000000`00000000 : nt!setjmpex+0x3d72
fffff802`de235a80 fffff802`dc719fe8 : ffffd001`ff58a180 00000000`00000002 fffff802`de235c38 fffff802`dc9ac180 : nt!setjmpex+0x1a76
fffff802`de235c10 fffff802`dc7195a9 : ffffe001`00000000 ffffe001`b1dc9b20 fffff802`de235e68 00000000`00000002 : nt!KeInsertQueueDpc+0xf08
fffff802`de235d60 fffff802`dc7d76a5 : 00000000`00000000 fffff802`dc9ac180 ffffd001`ffd9f280 00000000`00000000 : nt!KeInsertQueueDpc+0x4c9
fffff802`de235fb0 fffff802`dc7d74b0 : 00000000`00000000 00000000`00445000 00000000`00000102 00000000`00000000 : nt!KeSynchronizeExecution+0x4085
ffffd000`22e3bac0 fffff802`dc7d5f85 : 00000000`00000000 fffff802`dc7d3741 ffffe001`b3eef080 00000000`00000000 : nt!KeSynchronizeExecution+0x3e90
ffffd000`22e3baf0 fffff802`dc7d3741 : ffffe001`b3eef080 00000000`00000000 ffffd000`22e3bad8 ffffe001`b4ada5b0 : nt!KeSynchronizeExecution+0x2965
ffffd000`22e3bb00 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeSynchronizeExecution+0x121


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KeInsertQueueDpc+f08
fffff802`dc719fe8 16 ???

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: nt!KeInsertQueueDpc+f08

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntkrnlmp.exe

BUCKET_ID: WRONG_SYMBOLS

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


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)

if anyone has any pointers for how to better share my dump files so that someone with the necessary skills can read them, please let me know.

 

[johnbl]

you would copy the files in c:\windows\mindump directory to a cloud server like Microsoft onedrive, google docs or media fire. then share the files for public access and post a link here.
then someone could download the memory dump files and look at them in a windows debugger.

not many people actually will do this so you might try to run bluescreenview.exe or whocrashed.exe
to get a idea of the cause of the problem.

in your case it looks like something is trying to run data as code and the CPU found invalid instructions.
it could be data corruption, malware, overheated CPU, wrong voltages for the CPU clock frequency selected.
(old bios version running with a new CPU)
it can even be power problems, too low voltage or too high of a voltage on one of the newer processers.

sometimes the memory dump is pretty clear as to the cause, other times you have to add debug switches and produce a new memory dump with proper diagnostics. for this problem you might need to make a kernel memory dump just to get at the correct error logs and full driver debug info.

I would first update the BIOS and motherboard drivers just to save time. Then run memtest to confirm your memory timings (they are most likely ok, in this case)

I would then set the memory dump type to kernel and attempt to get a new memory dump.
A kernel memory dump is stored in a different file and location than a mini dump.
the file will be c:\windows\memory.dmp but it will contain proper debug info.
the minidumps can also be of use, they will show if any of your windows files are corrupt and will provide the list of drivers loaded and basic bios info about your machine, and any overclocking drivers will be listed and bios overclocking might also be shown.

you can put the memory dumps an a server and post a link and I will try to take a look.

 

[D4M4GED]

you would copy the files in c:\windows\mindump directory to a cloud server like Microsoft onedrive, google docs or media fire. then share the files for public access and post a link here.
then someone could download the memory dump files and look at them in a windows debugger.

not many people actually will do this so you might try to run bluescreenview.exe or whocrashed.exe
to get a idea of the cause of the problem.

in your case it looks like something is trying to run data as code and the CPU found invalid instructions.
it could be data corruption, malware, overheated CPU, wrong voltages for the CPU clock frequency selected.
(old bios version running with a new CPU)
it can even be power problems, too low voltage or too high of a voltage on one of the newer processers.

sometimes the memory dump is pretty clear as to the cause, other times you have to add debug switches and produce a new memory dump with proper diagnostics. for this problem you might need to make a kernel memory dump just to get at the correct error logs and full driver debug info.

I would first update the BIOS and motherboard drivers just to save time. Then run memtest to confirm your memory timings (they are most likely ok, in this case)

I would then set the memory dump type to kernel and attempt to get a new memory dump.
A kernel memory dump is stored in a different file and location than a mini dump.
the file will be c:\windows\memory.dmp but it will contain proper debug info.
the minidumps can also be of use, they will show if any of your windows files are corrupt and will provide the list of drivers loaded and basic bios info about your machine, and any overclocking drivers will be listed and bios overclocking might also be shown.

you can put the memory dumps an a server and post a link and I will try to take a look.

thanks for answering me, I will take your advice and update my bios, but other than that it doesnt sound like any of those could be the issue, I haven't been overclocking, never do to save issues like this. It could be heat, but there's not much I can do about that except buy a whole new case and cooling system, but i currently have a closed loop liquid cooler on my cpu. I will get a kernel dump file if i can work out how to do it, and I will upload them to a google doc and share them here.

thanks for the help.

 

[johnbl]

some of the liquid coolers have a USB connector and a really bad device driver.
if you have one of these you need to change your memory dump to a kernel memory dump and provide the c:\window\memory.dmp file. it will have proper debug info in the memory dump.