Daily BSOD - Windows 10 PRO 22H2

Every day it's some new BSOD.

Ive run MemTest86 overnight with zero errors. It passed.

Ive sfc /scannow hundreds of times

Ive run the restorehealth using DISM

Ive gone into Device Manager and one by one selected Update drivers/Search automatically. They were all up to date already.

Ive used DDU to cleanly uninstall my graphics driver and reinstalled fresh.

ive Run CHKDSK /F /R /X on my boot drive (initiated after a reboot)

Ive updated bios a week or two ago and made sure i had all the latest chipsets

This is a fairly modern AMD Ryzen 7 3700X system with 32 GB of RAM, an EVGA SuperNOVA G2 750w PSU, Gigabyte x570 Aorus mobo using a 1TB m.2 nvme as a boot drive. Nvidia RTX 3080 as GPU

Doing some digging I thought it is an Nvidia driver problem or maybe even just an issue with my GPU itself. So after seeing some suggestions I downloaded Afterburner so that I could underclock the GPU by about -50. It still crashed so now im trying -100.

I will say right when the BSOD happens it definitely looks like a GPU crash on my 2nd monitor. Random characters on the screen, etc.

Also of note is that the BSOD doesnt typically happen when the machine or the gpu is under load. In fact more often than not it happens during periods of inactivity. Sometimes I hear the post beep from the other room telling me that the PC has crashed while it was sleeping.

MV-HOME-(2023-04-11_12-28-44).zip - Google Drive

Two of your BSODs occurred whilst a mouse or keyboard operation was underway, the HIDCLASS driver appears often on the two call stacks. One BSOD occurred during storage access, the NTFS driver appears often on the call stack. One BSOD is inconclusive, I'm not sure what's causing that one.

The one that's of real interest in the DRIVER_VERIFIER_DETECTED_VIOLATION. Although you have Driver Verifier enabled it doesn't have the recommended options enabled, but it's still managed to catch a third-party driver that is misbehaving. That driver is GUBootStartup.sys as you can see from the call stack...

Code:

0: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffff9183`0e206558 fffff802`2b7dae34     nt!KeBugCheckEx
01 ffff9183`0e206560 fffff802`2b7d0b7c     nt!VerifierBugCheckIfAppropriate+0xe0
02 ffff9183`0e2065a0 fffff802`2b7e6045     nt!VfUtilSynchronizationObjectSanityChecks+0x70
03 ffff9183`0e2065e0 fffff802`2b7e4c5e     nt!ViKeInitializeMutexCommon+0x19
04 ffff9183`0e206610 fffff80a`9990103c     nt!VerifierKeInitializeMutex+0xe
05 ffff9183`0e206640 00000000`00000000     GUBootStartup+0x103c

The GUBootStartup.sys driver appears to be a component of Glary Utilities and from the name it would seem that this one is loaded at Windows startup and thus is always present. The version you have is about 18 months old...

Code:

0: kd> lmDvmGUBootStartup
Browse full module list
start             end                 module name
fffff80a`99900000 fffff80a`99909000   GUBootStartup T (no symbols)           
    Loaded symbol image file: GUBootStartup.sys
    Image path: \??\C:\Windows\System32\drivers\GUBootStartup.sys
    Image name: GUBootStartup.sys
    Browse all global symbols  functions  data
    Timestamp:        Wed Jan 20 13:33:49 2021 (6008151D)
    CheckSum:         00007809
    ImageSize:        00009000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

I would suggest either looking for any update to Glary Utilities or, better still, uninstalling it completely. Interestingly I note that Glary Utilities doesn't appear in your list of installed software?

I can't be certain that the other BSODs are related to this driver but we need to proceed one step at a time. We know now that GUBootStartup.sys is faulty and needs removing or updating before we look at anything else.

Hi yes I failed to mention I also saw that Glary’s associated BSOD at which point proceeded to uninstall it. Doing so at least took me out of the BSOD on startup loop with drive verifier active. I was able to login to my pc at that point. But then within about a minute or so I’d get another BSOD.

More than happy to run drive verifier again if there are recommended options I didn’t use.

- - - Updated - - -

And I do see it crashed again overnight when not in use

Ive gone ahead and re-run the log collector. Results here:
MV-HOME-(2023-04-12_08-46-02).zip - Google Drive

- - - Updated - - -

and another crash just now. Bad GPU or CPU or mobo causing phantom BSOD's elsewhere in the system?

On Wed 4/12/2023 11:59:44 AM your computer crashed or a problem was reported
crash dump file: C:\WINDOWS\Minidump\041223-12140-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x3FBC10)
Bugcheck code: 0xA (0x0, 0xFF, 0x0, 0xFFFFF8076BF957FB)
Error: IRQL_NOT_LESS_OR_EQUAL
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 Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above. This is a software bug.
This bug check belongs to the crash dump test that you have performed with WhoCrashed or other software. It means that a crash dump file was properly written out.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Wed 4/12/2023 11:59:44 AM your computer crashed or a problem was reported
crash dump file: C:\WINDOWS\MEMORY.DMP
This was probably caused by the following module: ntkrnlmp.exe (nt!setjmpex+0x8A99)
Bugcheck code: 0xA (0x0, 0xFF, 0x0, 0xFFFFF8076BF957FB)
Error: IRQL_NOT_LESS_OR_EQUAL
Bug check description: This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above. This is a software bug.
This bug check belongs to the crash dump test that you have performed with WhoCrashed or other software. It means that a crash dump file was properly written out.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.

That bugcheck code (IRQL_NOT_LESS_OR_EQUAL) is almost always a bad third-party driver. The best way to locate it (them?) is to run Driver Verifier again with a full set of tests, so please re-enable Driver Verifier using these instructions...

1. Take a restore point or a disk image of your system drive (with Acronis, Macrium Reflect or similar). THIS IS IMPORTANT because if Driver Verifier BSODs a bad driver at boot time you'll be stuck in a boot loop. You can either boot the Windows installation media and use system restore in there to restore to your restore point, or you can restore the disk image, to recover.

2. Start Driver Verifier via the verifier command.

3. Make these selections -
a. On first dialog select 2nd option - Create custom settings (for code developers)
b. On next dialog select 2nd option - Select individual settings from a full list
c. Check these boxes -
▪ Special Pool
▪ Force IRQL checking
▪ Pool Tracking
▪ Deadlock Detection
▪ Security Checks
▪ Miscellaneous Checks
▪ Power framework delay fuzzing
▪ DDI compliance checking
d. On the next dialog select last option - Select driver names from a list
e. Click on the Provider heading - this sorts the list by Provider
f. Check ALL boxes where "Microsoft" IS NOT the Provider, with the exception of the following:
▪ Wdf01000.sys
▪ ndis.sys
▪ fltMgr.sys
▪ Storport.sys
These are the only Microsoft drivers which should be enabled.
g. Click on Finish
h. Re-boot

4. Leave Driver Verifier enabled for at least 24 hours, we want as many BSODs as we can get because more dumps is better! Once you have 10 dumps or after 48 hours, stop driver verifier as follows
a. Enter the command verifier /reset
b. Re-boot

5. Run the log collector app again and upload the zip file.

Just a little update. Since starting verifier yesterday I have not yet crashed, frustratingly. Didnt want you to think I abandoned this thread. I'll keep it running until it does and report back, though.

No worries. If it was BSODing every day it should still be. Try and reproduce what you normally do on it.

ya super weird. im doing everything i usually do on it but today its playing nice.



Those two days of nothing the PC was turned off.

As long as Driver Verifier isn't causing you any usability issues it would be handy to leave it running.

Can you just check that Driver Verifier is actually running? Open a command prompt and enter the command verifier /query.

Left it up and running all weekend which in the past would still crash. I may have clean installed a new graphics driver when it became available recently? Other than that I'm not sure what else could have changed. Or a Windows update.


- - - Updated - - -

ok it finally BSOD'd just now.

MV-HOME-(2023-04-17_16-57-05).zip - Google Drive

- - - Updated - - -

and again just now. (but without verifier running)

MV-HOME-(2023-04-17_18-48-16).zip - Google Drive

Ah, now this is interesting. It's not good, but it's a HUGE clue. The dump you had whilst Driver Verifier was still enabled is a CLOCK_WATCHDOG_TIMEOUT, which indicates that one processor failed to respond to a clock interrupt (a synchronisation signal) within a specified time. 99% of the time this indicates a CPU fault. That's not what you want to hear I know, but for the first time we have a really good indication of where the problem lies.

The way to determine whether this is a CPU fault or a very rare driver fault is to enable Driver Verifier. If it's a very rare driver fault then Driver Verifier should find the driver. If Driver Verifier Doesn't BSOD any drivers and you still get a CLOCK_WATCHDOG_TIMEOUT BSOD then you can be pretty certain that you're looking at a faulty CPU. Sadly, that's where you are now.

A faulty CPU would of course explain the randomness of the other BSODs. I suggest you run a stress test on your CPU to see whether you can make it fail. For AMD CPUs the best test to use is Prime95, details on where to get that and what tests to run can be found here. Be sure to have some temperature monitoring software running to keep an eye on temps.

Let me know how that testing goes.

BTW. The last dump was a classic IRQL_NOT_LESS_OR_EQUAL and they are almost always a flaky third-party driver, but there are no third-party drivers in the call stack - that's also generally indicative of a hardware issue.

I know you're going to ask why the CPU issue didn't appear with Driver Verifier enabled, and I don't know. It may be because the extra tests to which every third-party driver (and a handful of critical Windows drivers) were subjected to helped to mask whatever the CPU error was? What's important here is that Driver Verifier did not find any flaky drivers, and that is an extremely strong (almost positive) indication that there is a CPU problem there.