Windows 10 freezes, requiring hard reboot, while gaming/general computing. Occasionally BSOD

[Valban]

Good evening,

First time PC builder and aspiring IT student here. I do not yet have the expertise needed to diagnose this ongoing issue I have been having with my PC. The issue started at the beginning of this year.

My computer will randomly freeze with a sound loop requiring a hard reboot. The issue will happen randomly with no warning signs or common causes that I can determine. Sometimes it won't happen for a few months, other times it may happen 2 - 3 times in a day.

Recently, I have been receiving BSOD errors which have not happened to this PC in the past. The BSOD errors are mixed in with the hard locks. The BSOD does not give any specific error other than the screen stating "We ran into a problem and need to reboot".

I was hoping the issues may have been due to a faulty stick of RAM, however I have tested my memory with Memtest which stated that there were no issues with my RAM. I have also clean installed all drivers related to my GPU with no change to the issue. I have been browsing other threads with common issues to mine, but was hoping someone here could point me in the best direction to continue troubleshooting.

I have downloaded and ran WhoCrashed and have posted the results of the program below. Any help would be much appreciated as I do not currently know where I should turn next to try and resolve my issue.

Regards,



System Information (local)
--------------------------------------------------------------------------------

Computer name: DESKTOP-6RAJ0C8
Windows version: Windows 10 , 10.0, build: 14393
Windows dir: C:\WINDOWS
Hardware: ASUSTeK COMPUTER INC., Z170-A
CPU: GenuineIntel Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz Intel586, level: 6
8 logical processors, active mask: 255
RAM: 17106022400 bytes total (Corsair Vengeance 2x8GB) 288Pin DDR4 (PC4 17000)
GPU: Nvidia GTX 980 TI



--------------------------------------------------------------------------------
Crash Dump Analysis
--------------------------------------------------------------------------------

Crash dump directory: C:\WINDOWS\Minidump

Crash dumps are enabled on your computer.

On Tue 7/11/2017 7:52:28 PM your computer crashed
crash dump file: C:\WINDOWS\Minidump\071117-7109-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x14ECE0)
Bugcheck code: 0x4A (0x7FFF48676874, 0x1, 0x0, 0xFFFFDF806E214B00)
Error: IRQL_GT_ZERO_AT_SYSTEM_SERVICE
file path: C:\WINDOWS\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that a thread is returning to user mode from a system call when its IRQL is still above PASSIVE_LEVEL.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Tue 7/11/2017 7:52:28 PM your computer crashed
crash dump file: C:\WINDOWS\memory.dmp
This was probably caused by the following module: ntkrnlmp.exe (nt!KeBugCheckEx+0x0)
Bugcheck code: 0x4A (0x7FFF48676874, 0x1, 0x0, 0xFFFFDF806E214B00)
Error: IRQL_GT_ZERO_AT_SYSTEM_SERVICE
Bug check description: This indicates that a thread is returning to user mode from a system call when its IRQL is still above PASSIVE_LEVEL.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Sat 6/24/2017 6:27:27 PM your computer crashed
crash dump file: C:\WINDOWS\Minidump\062417-5921-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x14E7C0)
Bugcheck code: 0x1A (0x41201, 0xFFFFB80000383A08, 0x9E9000013A0E1825, 0xFFFF9581899CD450)
Error: MEMORY_MANAGEMENT
file path: C:\WINDOWS\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that a severe memory management error occurred.
This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules. This problem might also be caused because of overheating (thermal issue).
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Sat 2/4/2017 4:42:08 PM your computer crashed
crash dump file: C:\WINDOWS\Minidump\020417-6968-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x14A6F0)
Bugcheck code: 0x19 (0xD, 0xFFFF8B01493FF8F0, 0x93C9D73EA56555E0, 0x93C9D73EA76555E0)
Error: BAD_POOL_HEADER
file path: C:\WINDOWS\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that a pool header is corrupt.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. This might be a case of memory corruption. More often memory corruption happens because of software errors in buggy drivers, not because of faulty RAM modules. This problem might also be caused because of overheating (thermal issue).
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.





--------------------------------------------------------------------------------
Conclusion
--------------------------------------------------------------------------------

4 crash dumps have been found and analyzed. No offending third party drivers have been found. Connsider using WhoCrashed Professional which offers more detailed analysis using symbol resolution. Also configuring your system to produce a full memory dump may help you.


Read the topic general suggestions for troubleshooting system crashes for more information.

Note that it's not always possible to state with certainty whether a reported driver is responsible for crashing your system or that the root cause is in another module. Nonetheless it's suggested you look for updates for the products that these drivers belong to and regularly visit Windows update or enable automatic updates for Windows. In case a piece of malfunctioning hardware is causing trouble, a search with Google on the bug check errors together with the model name and brand of your computer may help you investigate this further.

 

[johnbl]

The pool header of a freed block has been modified after it was freed. This is not typically the fault of the prior owner of the freed block; instead it is usually (but not always) due to the block preceding the freed block being overrun

this means that a driver over wrote over another drivers Pool data structures.
you would want to run verifier.exe and set debug flags to catch the bad driver as it overwrites data

you would run cmd.exe or powershell and run
verifier.exe /all /standard
and reboot your system
if windows finds a bad driver it will bugcheck the system and save a memory dump that will name the bad driver. You would have to copy the memory dump file to a server and provide a link.

note be sure you know how to get into safe mode so you can turn off verifier via
verifier.exe /reset

you have to turn off verifier after you are done testing or your machine will run slowly until you do.

 

[Valban]

The pool header of a freed block has been modified after it was freed. This is not typically the fault of the prior owner of the freed block; instead it is usually (but not always) due to the block preceding the freed block being overrun

this means that a driver over wrote over another drivers Pool data structures.
you would want to run verifier.exe and set debug flags to catch the bad driver as it overwrites data

you would run cmd.exe or powershell and run
verifier.exe /all /standard
and reboot your system
if windows finds a bad driver it will bugcheck the system and save a memory dump that will name the bad driver. You would have to copy the memory dump file to a server and provide a link.

note be sure you know how to get into safe mode so you can turn off verifier via
verifier.exe /reset

you have to turn off verifier after you are done testing or your machine will run slowly until you do.

Thank you kindly for your response!

I ran "verifier.exe /all /standard" as instructed and rebooted the system. It appears that everything must have checked out because there were no memory dump files that were created after rebooting. I booted into safe mode, reset verifier.exe, and ran it again just to be sure I didn't miss something the first time. There were still no memory dump files.

Does this mean that there were no bad drivers that were found?

 

[johnbl]

some times you have to run verifier for a few days before you hit a problem. Try starting verifier then put the machine into a few sleep/wake cycles and just leave verifier on while you use your system. you might also want to change the memory dump type to kernel so more debug info will be saved into the memory dump when you do get a crash.

The pool header of a freed block has been modified after it was freed. This is not typically the fault of the prior owner of the freed block; instead it is usually (but not always) due to the block preceding the freed block being overrun

this means that a driver over wrote over another drivers Pool data structures.
you would want to run verifier.exe and set debug flags to catch the bad driver as it overwrites data

you would run cmd.exe or powershell and run
verifier.exe /all /standard
and reboot your system
if windows finds a bad driver it will bugcheck the system and save a memory dump that will name the bad driver. You would have to copy the memory dump file to a server and provide a link.

note be sure you know how to get into safe mode so you can turn off verifier via
verifier.exe /reset

you have to turn off verifier after you are done testing or your machine will run slowly until you do.

Thank you kindly for your response!

I ran "verifier.exe /all /standard" as instructed and rebooted the system. It appears that everything must have checked out because there were no memory dump files that were created after rebooting. I booted into safe mode, reset verifier.exe, and ran it again just to be sure I didn't miss something the first time. There were still no memory dump files.

Does this mean that there were no bad drivers that were found?

 

[Valban]

some times you have to run verifier for a few days before you hit a problem. Try starting verifier then put the machine into a few sleep/wake cycles and just leave verifier on while you use your system. you might also want to change the memory dump type to kernel so more debug info will be saved into the memory dump when you do get a crash.

Ok, thanks! I've restarted the verifier and did a few sleep/wake cycles and changed the dump type to kernel. I'll monitor over the next few days and report back what I find.