Question Random BSODs over the past month

ronizu

Honorable
Sep 10, 2017
25
0
10,530
Over the past month or so I've had various random BSODs. A few have happened while using the PC but it feels like most of them happen when my PC is idle, I go out of my room to do something and when I come back my PC has restarted. According to event viewer, the BSODs are the following:

0x50 PAGE_FAULT_IN_NONPAGED_AREA
0xA IRQL_NOT_LESS_OR_EQUAL
0x3B SYSTEM_SERVICE_EXCEPTION
0x139 KERNEL_SECURITY_CHECK_FAILURE
0x10000007E SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M
0x4A IRQL_GT_ZERO_AT_SYSTEM_SERVICE
0x162 KERNEL_AUTO_BOOST_INVALID_LOCK_RELEASE
0x1E KMODE_EXCEPTION_NOT_HANDLED
0x133 DPC_WATCHDOG_VIOLATION

Edit: The most common ones are 0x139 (by far the most common, accounts for like 50% of all my BSODs), 0xA and 0x50. The other ones were either one-offs or few and far between.

Minidump of today's BSOD: https://drive.google.com/file/d/1BlbkiwK0LCeOtPIZizZMFEpOlsgYht-x/view?usp=sharing

I'm not sure what more is needed to solve the problem, if you need more information (logs, screenshots etc.) please do ask.

R7 3700X
MSI Armor OC RX 580 8GB
Asus PRIME B350-PLUS
WD Blue 1TB HDD
Crucial MX500 SSD
2x Kingston 8GB 3200MHz
 
Last edited:

ronizu

Honorable
Sep 10, 2017
25
0
10,530
Please state the BIOS version for your motherboard? Make and model of your PSU and it's age? Where did you source the installer for the OS?
BIOS version: 5602, 07/14/2020
PSU: Seasonic S12II 620W, I bought it in May 2019.
As for the OS, I really don't remember, I've upgraded my PC multiple times over the years and I don't remember when I reinstalled Windows etc. Can I find that out by any means?
 
Last edited:

ronizu

Honorable
Sep 10, 2017
25
0
10,530
Can you think of any recent changes made to the system prior to the issue? New hardware? OS update?
The latest change I did was upgrading my RAM last September. So no, not in quite a while. I've been having some BSODs prior as well (like, a few times per month) but only since around February they have actually gotten common, with like 1 every other day on average.
 

Colif

Win 11 Master
Moderator
As for the OS, I really don't remember, I've upgraded my PC multiple times over the years and I don't remember when I reinstalled Windows etc. Can I find that out by any means?
windows 10 only remembers as far back as its last version update

I will ask a friend to convert dumps
0x4A IRQL_GT_ZERO_AT_SYSTEM_SERVICE << i don't see this often
 
Jan 4, 2022
50
3
45
The latest change I did was upgrading my RAM last September. So no, not in quite a while. I've been having some BSODs prior as well (like, a few times per month) but only since around February they have actually gotten common, with like 1 every other day on average.

Colif is going to get your .dmp file analyzed so hopefully that returns some useful information. What is your PSU?

I've found that removing as many peripherals as possbile and trying to recreate the problem can help you narrow down what the issue might be like a bad GPU, bad RAM, bad HDD. So maybe remove your GPU, use on board, test your RAM, and remove any extra drives you don't need to run. See if it BSOD then.
 

Colif

Win 11 Master
Moderator

ronizu

Honorable
Sep 10, 2017
25
0
10,530
Colif is going to get your .dmp file analyzed so hopefully that returns some useful information. What is your PSU?

I've found that removing as many peripherals as possbile and trying to recreate the problem can help you narrow down what the issue might be like a bad GPU, bad RAM, bad HDD. So maybe remove your GPU, use on board, test your RAM, and remove any extra drives you don't need to run. See if it BSOD then.
The problem is that I'm not getting constant BSODs. Sometimes my PC works just fine for a week without a single BSOD, sometimes I get five in one day. So the "See if it BSODs then" part is a bit problematic because they are so inconsistent, I don't know any single thing that causes one always. Even if I did remove my HDD for example, I wouldn't know if that fixed the issue or if it's just not appearing unless I actually ran the PC for weeks on end without any issues without the HDD. Also, my CPU doesn't have an onboard GPU so that wouldn't work.
 

gardenman

Splendid
Moderator
Hi, I ran the dump files through the debugger and got the following information: https://jsfiddle.net/uqhf5zyk/show This link is for anyone wanting to help. You do not have to view it. It is safe to "run the fiddle" as the page asks.

File information:040722-14093-01.dmp (Apr 7 2022 - 13:06:58)
Bugcheck:KERNEL_SECURITY_CHECK_FAILURE (139)
Probably caused by:ntkrnlmp.exe (Process running at time of crash: OverwolfHelper)
Uptime:1 Day(s), 7 Hour(s), 31 Min(s), and 24 Sec(s)

Comment: The overclocking driver "RTCore64.sys" was found on your system. (MSI Afterburner)

Possible Motherboard page: https://www.asus.com/us/Motherboards-Components/Motherboards/PRIME/PRIME-B350-PLUS/

This information can be used by others to help you. Someone else will post with more information. Please wait for additional answers. Good luck.
 
you should remove this driver:
May 05 2013ScpVBus.sys

it corrupts the data for the drivers that are loaded next to it in memory.
it does not pass verifier.exe tests.
if you do keep the driver, then shutdown your machine often,
also, generally, you do not want to debug problems if a overclock driver is installed.
 

ronizu

Honorable
Sep 10, 2017
25
0
10,530
you should remove this driver:
May 05 2013ScpVBus.sys

it corrupts the data for the drivers that are loaded next to it in memory.
it does not pass verifier.exe tests.
if you do keep the driver, then shutdown your machine often,
also, generally, you do not want to debug problems if a overclock driver is installed.
Hm, you sure about that? I believe that driver is for my SCP Toolkit, which is required for my controller to work with my PC. I wouldn't like to remove it unless necessary. Also, about the MSI Afterburner driver, what do you mean by "you do not want to debug problems if a overclock driver is installed"? My GPU isn't overclocked, I just use my Afterburner for undervolting it for reasonable temps and a custom fan curve so it doesn't fry itself when it doesn't have to.
 
Hm, you sure about that? I believe that driver is for my SCP Toolkit, which is required for my controller to work with my PC. I wouldn't like to remove it unless necessary. Also, about the MSI Afterburner driver, what do you mean by "you do not want to debug problems if a overclock driver is installed"? My GPU isn't overclocked, I just use my Afterburner for undervolting it for reasonable temps and a custom fan curve so it doesn't fry itself when it doesn't have to.
yep, I am sure about the driver. you can turn on verifier.exe flags to check but then your machine will bugcheck more often most likely on bootup. One of its problems is someone need to modify the code and provide a pooltag for all device driver memory allocations. This was optional for windows 7 but now is required for current windows versions. pooltag, is just a 4 character string added to all device driver memory allocations so windows can tell what driver owns the memory allocation.
here is a sample of a driver that made the required change to add pooltags: just fyi:
https://github.com/microsoft/Windows-driver-samples/commit/6e59c4660b8da2de65334b4d732bcf6c85ed2837

I do remember debugging this years ago and there are other issues but this one blocks running verifier.exe from running.
here is the code for your driver:
looks like someone is still making changes, you should look for a update.
note: just looked at the code and it looks like it has been updated.
to use ExAllocatePoolWithTag. so do see if you can find a updated driver. file was last modified in 2016.

I use the afterburner for the same reason. to kick the fan speed up to 100%
but for someone debugging you can spend hours working on a problem only to find that some bit got flipped because of overclocking driver voltage issue. Now windows does a lot more checks and you might see the debugger catching the errors in critical windows code but most of the time it does not.
 
Last edited:

ronizu

Honorable
Sep 10, 2017
25
0
10,530
yep, I am sure about the driver. you can turn on verifier.exe flags to check but then your machine will bugcheck more often most likely on bootup. One of its problems is someone need to modify the code and provide a pooltag for all device driver memory allocations. This was optional for windows 7 but now is required for current windows versions. pooltag, is just a 4 character string added to all device driver memory allocations so windows can tell what driver owns the memory allocation.
here is a sample of a driver that made the required change to add pooltags: just fyi:
https://github.com/microsoft/Windows-driver-samples/commit/6e59c4660b8da2de65334b4d732bcf6c85ed2837

I do remember debugging this years ago and there are other issues but this one blocks running verifier.exe from running.


I use the afterburner for the same reason. to kick the fan speed up to 100%
but for someone debugging you can spend hours working on a problem only to find that some bit got flipped because of overclocking driver voltage issue. Now windows does a lot more checks and you might see the debugger catching the errors in critical windows code but most of the time it does not.
Okay, thanks. I uninstalled SCP Toolkit and found a replacement driver for the controller, maybe that helps. As for the overclocking software thing, that should only happen when I actually have an overclock in place right? And if they do cause issues even without changing any settings in them, how can I add a custom fan curve without one? My GPU cooler is kind of bad which makes the GPU run at like 90C before turning the fans up to max with the stock fan curve and I wouldn't want to have it running at those temps for extended periods of time.

Also, do you suspect that all the BSODs I've been getting have been caused by that one driver or just the one that I had a dump of (KERNEL_SECURITY_CHECK_FAILURE)? Should I provide other dumps as well from different BSODs?
 
Okay, thanks. I uninstalled SCP Toolkit and found a replacement driver for the controller, maybe that helps. As for the overclocking software thing, that should only happen when I actually have an overclock in place right? And if they do cause issues even without changing any settings in them, how can I add a custom fan curve without one? My GPU cooler is kind of bad which makes the GPU run at like 90C before turning the fans up to max with the stock fan curve and I wouldn't want to have it running at those temps for extended periods of time.

Also, do you suspect that all the BSODs I've been getting have been caused by that one driver or just the one that I had a dump of (KERNEL_SECURITY_CHECK_FAILURE)? Should I provide other dumps as well from different BSODs?
I would delete the old memory dumps, then just continue on to see if you get new bugchecks after removing the scp toolkit.
you can also try driver verifier.exe tool if you still can not find the problem.
it makes the system run slow but forces the drivers to use special pool that windows will do a bunch of error checking on. If a error is detected the system bugchecks at the time of the error and names the driver in the memory dump. The biggest problem is the driver you removed would bugcheck before the system finished booting. on current versions of windows it bugchecked because the pooltag was not there. on old versions of windows the driver would overrun its buffers and cause pool corruption of other drivers. This will bugcheck at the time of corruption if verifier is turn on for the driver. Then you have to boot in safe mode and turn verifier off by running
verifier.exe /reset
or your machine will never complete a bootup without bugchecking.
people sometimes have issues getting into safe mode and running the command and end up wiping the machine and reinstalling. they then blame verifier.exe for the problem.
 

ronizu

Honorable
Sep 10, 2017
25
0
10,530
I would delete the old memory dumps, then just continue on to see if you get new bugchecks after removing the scp toolkit.
you can also try driver verifier.exe tool if you still can not find the problem.
it makes the system run slow but forces the drivers to use special pool that windows will do a bunch of error checking on. If a error is detected the system bugchecks at the time of the error and names the driver in the memory dump. The biggest problem is the driver you removed would bugcheck before the system finished booting. on current versions of windows it bugchecked because the pooltag was not there. on old versions of windows the driver would overrun its buffers and cause pool corruption of other drivers. This will bugcheck at the time of corruption if verifier is turn on for the driver. Then you have to boot in safe mode and turn verifier off by running
verifier.exe /reset
or your machine will never complete a bootup without bugchecking.
people sometimes have issues getting into safe mode and running the command and end up wiping the machine and reinstalling. they then blame verifier.exe for the problem.
I just tried running verifier and you were right, I couldn't even boot the system without a BSOD. Turned it off in safemode, here's the dump: https://drive.google.com/file/d/1BlbkiwK0LCeOtPIZizZMFEpOlsgYht-x/view?usp=sharing
 
i think you gave me a old memory dump. it indicated the system was up for 7 hours before the crash. the running process was
OverwolfHelper (rest of the file name was truncated because of a debugger bug)
it could be overwolfhelper.exe or maybe overwolfhelper64.exe

looks like a buffer overflow that corrupted data inside the kernel.
0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

after you turn on the verifier flags you should reboot. that way you will get the driver checking beginning at load time. It takes a while to get the system booting bugs worked out.

I would remove the overwolf software and see if that has an effect. I have installed it before but had issues and removed it within 30 minutes. (this was years ago, I do not know what issues it might have today)

the debugger could not read any that any verifier flags were set. normally, it could even if you had not turned it on.

also, the stack showed that the call came from a service. you might be able to bring up task manager (control alt delete) go to the services tab, scroll down to the service and stop the service and disable it for testing.
 
Last edited:

ronizu

Honorable
Sep 10, 2017
25
0
10,530
after you turn on the verifier flags you should reboot. that way you will get the driver checking beginning at load time. It takes a while to get the system booting bugs worked out.
That's what I did. That dump was the only one that appeared. Or are the verifier dumps somewhere other than C:\Windows\Minidums\?
 
That's what I did. That dump was the only one that appeared. Or are the verifier dumps somewhere other than C:\Windows\Minidums\?
if you changed the memory dump type to kernel then the dump is stored in a different location.
c:\windows directory in the file memory.dmp

for debugging certain issues you want a kernel memory dump
heap problems require a kernel dump.
 
Last edited:

ronizu

Honorable
Sep 10, 2017
25
0
10,530
if you changed the memory dump type to kernel then the dump is stored in a different location.
c:\windows directory in the file memory.dmp

for debugging certain issues you want a kernel memory dump
heap problems require a kernel dump.
I didn't change anything, that's the only dump from today I can find. I can try it again if you want in the morning, but I'll need the location of the new dump.
 
I didn't change anything, that's the only dump from today I can find. I can try it again if you want in the morning, but I'll need the location of the new dump.
set the system to make a kernel dump. the location is user specified but the default is
c:\windows\memory.dmp file
it is one directory higher from the minidump directory. it makes one big file called memory.dmp and each bugcheck will overwrite the previous version. (minidumps use different names based on the date)
 

ronizu

Honorable
Sep 10, 2017
25
0
10,530
debugger does not like your memory dump. indicates it is corrupted and could not be loaded.
will down load it again and see if i can see anything.
-----------
looks like the system ran for 7 seconds and verifier found a driver that unloaded without releasing its memory allocations. problem is the driver name was all blank (zeros)
most of the debugger commands not working but I will see if I can find the driver name.
 
Last edited:
debugger does not like your memory dump. indicates it is corrupted and could not be loaded.
will down load it again and see if i can see anything.
-----------
looks like the system ran for 7 seconds and verifier found a driver that unloaded without releasing its memory allocations. problem is the driver name was all blank (zeros)
most of the debugger commands not working but I will see if I can find the driver name.
This makes it harder, you would not have to run verifier.exe only on a limited set of 3rd party driver each time you boot until you figure out the driver that is causing the failure. Generally, I would use autoruns to disable 3rd party drivers, boot with verifier. if the system boots, then I would use autoruns to enable a third party driver and reboot and see if the system bugchecks. then work thru all of the drivers that you disabled until you find the bad driver. kind of tedious.

generally, you see a corrupted dump if the bug is in a storage driver, rootkit/malware or the machine just has hardware problems. IE will not pass memtest86. in this case you would not get the same bugcheck twice even if you have verifier running.

you can also google "how to force a memory dump using a keyboard" make the registry changes, reboot then use the keyboard to force a kernel dump on the working system. This will make sure that the system can produce a good kernel dump while working. (might fail if you have a rootkit)
also, a lot of errors will show up in a working system kernel memory dump and can be read using the debugger. verifier just makes the process easier to detect problems since it bugchecks at the time of the problem rather than later when the problem causes something to crash.