Question Windows 11 Random BSODs (HYPERVISOR_ERROR) Cause Unknown

[ConorDuey2000]

Hello. My computer keeps on getting these BSODs completely at random. They just say "HYPERVISOR_ERROR". I do have VMWare installed on my computer, but I have every VMWare service stopped and set to start manually. I've also never opened Windows Subsystem for Linux before I got that BSOD.

The cause of the BSOD is unknown. When I opened up "WinDBG" as an administrator, it told me that "amdppm.sys" resulted in the BSOD, but the process that caused it was "System". Therefore, I don't know what caused that BSOD. This isn't the only time I've gotten this type of BSOD and it's driving me so crazy that I've contemplated buying a new computer.

I've searched up "amdppm.sys BSOD" and I was told to change a registry value (I backed up my registry before doing so just in case.) and change my computer's power plan to "Balanced (recommended)" in the control panel. I did those two things, but I don't think that this will stop me from getting random and unknown "HYPERVISOR_ERROR" BSODs.

Anyway, here is the BSOD in question. Hopefully, you can find what's wrong with me computer and help me fix it.

By the way, my computer has an AMD Ryzen CPU, 16GB of RAM, an ASUS motherboard, and an NVIDIA GeForce RTX 2060 graphics card.

 

[ubuysa]

It would be lovely if the faulty driver was highlighted in the dump, but sadly it almost never is. The analyze -v command does some triage processing and does its best to identify the failing driver, but even this is wrong most of the time. The reason for using Driver Verifier is precisely because the resulting BSOD occurs in the flaky driver that it's such a useful tool. You can easily make new Windows installation media using an 8GB (min) USB stick and the Windows Media Creation Tool. I would do that on a different PC however.

That said, in your latest dump there is something interesting in the call stack (that analyze -v doesn't find)...

fffffc06`8a4e5f38  fffff807`38e3a134 nt!KiPageFault+0x474
fffffc06`8a4e5f40  00000000`00002710
fffffc06`8a4e5f48  00000000`00000000
fffffc06`8a4e5f50  00000000`00000000
fffffc06`8a4e5f58  fffff807`3b506ffb stornvme!NVMePowerActive+0x428b
fffffc06`8a4e5f60  00000000`00000000
fffffc06`8a4e5f68  00001f80`01010000
fffffc06`8a4e5f70  fffffc06`8a4e6170
fffffc06`8a4e5f78  00000000`00000000
fffffc06`8a4e5f80  00000000`00000000
fffffc06`8a4e5f88  00000000`00000020
fffffc06`8a4e5f90  00000000`0000003f
fffffc06`8a4e5f98  fffff807`38c98910 nt!KeReleaseInStackQueuedSpinLockFromDpcLevel
fffffc06`8a4e5fa0  ffff8081`d0f30350
fffffc06`8a4e5fa8  fffff807`3b502d4b stornvme!NVMeHwAdapterControl+0x4b

You read these call stacks from the bottom up, notice the call to stornvme.sys just before the page fault that caused the BSOD? The stornvme.sys driver is the Windows NVMe driver, and because it's a Windows driver it's not at fault. I'm wondering whether the issue is your NVMe drive?

I've seen M.2 drives causing niggly issues that were resolved by re-seating the drive. So first off, remove the NVMe drive and re-seat it fully.

If it's a Samsung SSD download Samsung Magician and use that to a) test the drive, b) see whether there is an updated Samsung driver for it, and c) see whether there is a firmware update for it.

 

[ConorDuey2000]

It would be lovely if the faulty driver was highlighted in the dump, but sadly it almost never is. The analyze -v command does some triage processing and does its best to identify the failing driver, but even this is wrong most of the time. The reason for using Driver Verifier is precisely because the resulting BSOD occurs in the flaky driver that it's such a useful tool. You can easily make new Windows installation media using an 8GB (min) USB stick and the Windows Media Creation Tool. I would do that on a different PC however.

That said, in your latest dump there is something interesting in the call stack (that analyze -v doesn't find)...

fffffc06`8a4e5f38  fffff807`38e3a134 nt!KiPageFault+0x474
fffffc06`8a4e5f40  00000000`00002710
fffffc06`8a4e5f48  00000000`00000000
fffffc06`8a4e5f50  00000000`00000000
fffffc06`8a4e5f58  fffff807`3b506ffb stornvme!NVMePowerActive+0x428b
fffffc06`8a4e5f60  00000000`00000000
fffffc06`8a4e5f68  00001f80`01010000
fffffc06`8a4e5f70  fffffc06`8a4e6170
fffffc06`8a4e5f78  00000000`00000000
fffffc06`8a4e5f80  00000000`00000000
fffffc06`8a4e5f88  00000000`00000020
fffffc06`8a4e5f90  00000000`0000003f
fffffc06`8a4e5f98  fffff807`38c98910 nt!KeReleaseInStackQueuedSpinLockFromDpcLevel
fffffc06`8a4e5fa0  ffff8081`d0f30350
fffffc06`8a4e5fa8  fffff807`3b502d4b stornvme!NVMeHwAdapterControl+0x4b

You read these call stacks from the bottom up, notice the call to stornvme.sys just before the page fault that caused the BSOD? The stornvme.sys driver is the Windows NVMe driver, and because it's a Windows driver it's not at fault. I'm wondering whether the issue is your NVMe drive?

I've seen M.2 drives causing niggly issues that were resolved by re-seating the drive. So first off, remove the NVMe drive and re-seat it fully.

If it's a Samsung SSD download Samsung Magician and use that to a) test the drive, b) see whether there is an updated Samsung driver for it, and c) see whether there is a firmware update for it.

I do have an M.2 Samsung SSD so I downloaded Samsung Magician. However, according to that program, it doesn't seem that my SSD has any problems and its firmware's up to date.

I did get another BSOD this morning. This time, it was a DPC_WATCHDOG_VIOLATION minidump that was caused by tcpip.sys. Here is the minidump.

 

[ubuysa]

This latest dump is very similar, but since you've (probably) eliminated the NVMe drive we need to look elsewhere. The bugcheck indicates that the BSOD occurred because a single DPC (Deferred Procedure Call - the 'back-end' of interrupt processing) ran for too long. The watchdog analysis shows that it was a DPC running on processor #8...

DPC Watchdog Captures Analysis for CPU #8.
   DPC Watchdog capture size: 108 stacks.
   Number of unique stacks: 1.
   No common functions detected!

The captured stacks seem to indicate that only a single DPC or generic function is the culprit.
Try to analyse what other processors were doing at the time of the following reference capture:
fffff8075aa099b8: Unable to get Flags value from nt!KdVersionBlock
CPU #8 DPC Watchdog Reference Stack (#0 of 108) - Profiling started at time since boot: 347 Min 27 Sec 765.62 mSec
 # RetAddr           Call Site
00 fffff8075a024e13  nt!KiUpdateRunTime+0xF4 
01 fffff8075a02429a  nt!KeClockInterruptNotify+0x763 
02 fffff8075a1453fe  nt!HalpTimerClockInterrupt+0x10A 
03 fffff8075a22b55a  nt!KiCallInterruptServiceRoutine+0x19E 
04 fffff8075a22bdc7  nt!KiInterruptSubDispatchNoLockNoEtw+0xFA 
05 fffff8075a11d1bf  nt!KiInterruptDispatchNoLockNoEtw+0x37 
06 fffff8075a098960  nt!KxWaitForLockChainValid+0x1F 
07 fffff8075e4f4a1a  nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0x50 
08 fffff8075e4f3271  tcpip!TcpProcessExpiredTcbTimers+0xBA 
09 fffff8075a0be11a  tcpip!TcpPeriodicTimeoutHandler+0x431 
0a fffff8075a0bd924  nt!KiExecuteAllDpcs+0x54A 
0b fffff8075a22e1fe  nt!KiRetireDpcList+0xFE4 
0c ----------------  nt!KiIdleLoop+0x9E

You can see the nt!KiExecuteAllDpcs call, which is when we begin DPC processing. The first DPC is for tcpip.sys ( tcpip!TcpPeriodicTimeoutHandler), so if we examine this function call in more detail...

8: kd> .frame /r 0b
0b ffffcf8b`988d1250 fffff807`5a0be11a     tcpip!TcpPeriodicTimeoutHandler+0x431
rax=0000000000000000 rbx=00000000013dd41f rcx=ffffcf8b988d1170
rdx=0000000000000000 rsi=0000000000000008 rdi=0000000000000000
rip=fffff8075e4f3271 rsp=ffffcf8b988d1250 rbp=ffffcf8b988d1350
 r8=0000000000000000  r9=000000000000003f r10=fffff8075a098910
r11=ffffe70a9b92f0c8 r12=0000000000000008 r13=0000000000000010
r14=ffffe70a9b998cc0 r15=000000000000ffff
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
tcpip!TcpPeriodicTimeoutHandler+0x431:
fffff807`5e4f3271 0fb705a8082000  movzx   eax,word ptr [tcpip!PartitionCount (fffff807`5e6f3b20)] ds:002b:fffff807`5e6f3b20=????

You can see at the bottom of the above the instruction that caused the BSOD. The tcpip.sys driver is accessing a memory address referenced by tcpip!PartitionCount but the resulting address is invalid (notice the ????).

The tcpip.sys driver is not the one at fault however, because its a Windows driver, so we need to look lower down in the network stack and the third-party network adapter driver. I don't know whether you're Ethernet or WiFi connected so I'll look at both drivers...

The Ethernet port driver is rt640x64.sys and it's almost two years old...

15: kd> lmDvmrt640x64
Browse full module list
start             end                 module name
fffff807`6ef30000 fffff807`6f048000   rt640x64   (deferred)             
    Image path: \SystemRoot\System32\drivers\rt640x64.sys
    Image name: rt640x64.sys
    Browse all global symbols  functions  data
    Timestamp:        Tue May 11 06:30:41 2021 (6099FA61)
    CheckSum:         00128358
    ImageSize:        00118000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

The wireless card driver is Netwtw08.sys and it's a little more current...

15: kd> lmDvmrt640x64
Browse full module list
start             end                 module name
fffff807`6ef30000 fffff807`6f048000   rt640x64   (deferred)             
    Image path: \SystemRoot\System32\drivers\rt640x64.sys
    Image name: rt640x64.sys
    Browse all global symbols  functions  data
    Timestamp:        Tue May 11 06:30:41 2021 (6099FA61)
    CheckSum:         00128358
    ImageSize:        00118000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

The problem could also be the Ethernet or wireless adapter themselves of course.

I note that you mention that the problem appeared after opening the Windows Subsystem for Linux and you're running VMWare (which has its own networking drivers). I know nothing at all about the Windows Subsystem for Linux, nor how it integrates with Windows, but I wonder whether your network adapter driver doesn't play well with the Windows Subsystem for Linux?

 

[ConorDuey2000]

I'm back. I got another IRQL_NOT_LESS_OR_EQUAL BSOD this morning. I analyzed it in WinDbg and it just told me that the process name was "System". Therefore, I don't know what caused that BSOD.

I also have another problem. I have Logitech G HUB installed on my computer and it's not showing up in the system tray. Whenever I try to manually launch "lghub_system_tray.exe", it just crashes.

Anyway, here is the minidump and here is the crash dump that I compressed in a ZIP file.

 

[ubuysa]

One war at a time (though they might be related).

I think it's time we enabled Driver Verifier on your system to try and catch the flaky driver(s). Driver Verifier causes specific additional checks to be done on selected drivers each time they are used, if a driver fails any of these extra checks the system will BSOD. Save all the dumps produced by Driver Verifier BSODs and upload them here after you turn Driver Verifier off.

Warning: Before you enable Driver Verifier take a manual restore point. This is because it's possible that Driver Verifier might BSOD a driver during the boot process. If that happens you'll be in a BSOD boot loop. If that happens boot the Windows installation media, select Repair my computer, navigate to the System Restore section and restore from the restore point you just took. The system will then be bootable and Driver Verifier will be off.

To enable Driver Verifier in the Run command box (or in a Command prompt window) enter verifier and click OK.

In the first dialog check the radio button for Create custom settings (for code developers) and click Next.

In the second dialog select (check) the following tests (and only these tests) and then click Next.
▪ Special Pool
▪ Force IRQL checking
▪ Pool Tracking
▪ Deadlock Detection
▪ Security Checks
▪ Miscellaneous Checks
▪ Power framework delay fuzzing
▪ DDI compliance checking

One the next dialog check the bottom radio button (Select driver names from a list ) and click Next.

In the driver selection list dialog click on the heading for 'Provider' to sort the drivers on that field (this makes it easier to exclude Microsoft drivers).

Select (check) ALL drivers that DO NOT have Microsoft as the provider.

Then select these Microsoft drivers (and only these):
▪ Wdf01000.sys
▪ ndis.sys
▪ fltMgr.sys
▪ Storport.sys

Then click on Finish and reboot. Driver Verifier will be enabled (and will stay enabled even across shutdowns and restarts).

Leave Driver Verifier enabled for at least 24 hours and use your PC normally during that time. There is probably little point in leaving it enabled longer than 48 hours. If it BSODs (which is good) just restart and keep testing. We'd like many dumps - at least five ideally.

To disable driver verifier in the Run command box (or a Command prompt window) enter verifier /reset and reboot, Driver Verifier will be disabled.

 

[ConorDuey2000]

One war at a time (though they might be related).

I think it's time we enabled Driver Verifier on your system to try and catch the flaky driver(s). Driver Verifier causes specific additional checks to be done on selected drivers each time they are used, if a driver fails any of these extra checks the system will BSOD. Save all the dumps produced by Driver Verifier BSODs and upload them here after you turn Driver Verifier off.

Warning: Before you enable Driver Verifier take a manual restore point. This is because it's possible that Driver Verifier might BSOD a driver during the boot process. If that happens you'll be in a BSOD boot loop. If that happens boot the Windows installation media, select Repair my computer, navigate to the System Restore section and restore from the restore point you just took. The system will then be bootable and Driver Verifier will be off.

To enable Driver Verifier in the Run command box (or in a Command prompt window) enter verifier and click OK.

In the first dialog check the radio button for Create custom settings (for code developers) and click Next.

In the second dialog select (check) the following tests (and only these tests) and then click Next.
▪ Special Pool
▪ Force IRQL checking
▪ Pool Tracking
▪ Deadlock Detection
▪ Security Checks
▪ Miscellaneous Checks
▪ Power framework delay fuzzing
▪ DDI compliance checking

One the next dialog check the bottom radio button (Select driver names from a list ) and click Next.

In the driver selection list dialog click on the heading for 'Provider' to sort the drivers on that field (this makes it easier to exclude Microsoft drivers).

Select (check) ALL drivers that DO NOT have Microsoft as the provider.

Then select these Microsoft drivers (and only these):
▪ Wdf01000.sys
▪ ndis.sys
▪ fltMgr.sys
▪ Storport.sys

Then click on Finish and reboot. Driver Verifier will be enabled (and will stay enabled even across shutdowns and restarts).

Leave Driver Verifier enabled for at least 24 hours and use your PC normally during that time. There is probably little point in leaving it enabled longer than 48 hours. If it BSODs (which is good) just restart and keep testing. We'd like many dumps - at least five ideally.

To disable driver verifier in the Run command box (or a Command prompt window) enter verifier /reset and reboot, Driver Verifier will be disabled.

I guess I don't have a choice. If the BSODs continue to happen, then I'll run driver verifier. I'll also create a restore point and the Windows installation media before I do that.

 

[Ralston18]

I suggest going back a bit.

Update your post to include full system hardware specs and OS information (Windows 11 noted).

Include PSU. Make, model, wattage, age, condition (original to build, new, refurbished, used)? Were any PSU cables other than the cables that came with the PSU used?

Disk drive(s): make, model, capacity, how full?

Look in Reliability History and Event Viewer for error codes, warnings, or even informational events that occurred just before or at the time of the BSODs.

Look in Update History for any problem or failed updates.

Manually download drivers directly from the applicable manufacturer's websites. Install and configure drivers as necessary. No third party tools or installers.

Ensure that the website is indeed the manufacturer. Just because the manufacturer's name appears in the URL that does not mean that the website is the manufacturer.

Run "sfc /scannow" and "dism".

References:

https://www.lifewire.com/how-to-use-sfc-scannow-to-repair-windows-system-files-2626161

How to use DISM command tool to repair Windows 10 image | Windows Central

= = = =

Power down, unplug, open the case.

Clean out dust and debris. Inspect for signs of damage, loose or missing screws, pinched/kinked wires, bare conductor showing, cracks, etc..

Verify by sight and feel that all connectors, cards, RAM, jumpers, and case connections are fully and firmly in place.

What appears to be properly seated may actually not be fully and properly seated. Carefully unplug and replug everything a few times. Something that seemed okay may suddenly and smoothly slide or click into place. Nothing should need to be forced.

And stay out of the registry. Registry editing is a last resort and should only be attempted after a full system backup (including the Registry itself) has been completed and verified.

 

[ConorDuey2000]

I got another BSOD, this morning. This time, it was a SYSTEM_SERVICE_EXCEPTION that was caused by dxgkrnl.sys and dwm.exe. Here is the minidump.

 

[ConorDuey2000]

I'm gonna start the driver verification, now. I was just using my computer normally until it got a BSOD right out of nowhere. I was just browsing the internet and it gave me a KERNER_SECURITY_CHECK_FAILURE BSOD. After I analyzed it in WinDbg, it told me that USBXHCI.SYS caused that BSOD.

Anyway, here is the minidump.

 

[ubuysa]

This is a KERNEL_SECURITY_CHECK_FAILURE bugcheck with a reason code indicating that a list entry was corrupted. That will be the fault of a third-party driver, almost certainly.

The USBXHCI.sys driver named by analyze -v is the USB3.0 host controller driver, that would suggest that the issue here was with the driver for a USB3.0 attached device. The USBXHCI.sys driver is a WIndows driver so it's not the root cause however, the problem will be a third-party driver for a device that's attached to a USB3.0 port.

In the call stack, just before the bugcheck, we can see calls to WDF functions, this is the Windows Driver Foundation which provides a set of link libraries to make writing third-party drivers easier. These calls will likely be for the third party driver that's causing the problem.

0xfffff800783abb48 : 0xfffff80079e3eaa9 : nt!KiBugCheckDispatch+0x69
0xfffff800783abc50 : 0xffffdd0b8d5f9ac0 :  dt Wdf01000!FxRequestFromLookaside
0xfffff800783abc58 : 0xffffdd0b8d5b95f0 :  dt Wdf01000!FxIoQueue
0xfffff800783abc88 : 0xfffff80079e3f032 : nt!KiFastFailDispatch+0xb2
0xfffff800783abd90 : 0xffffdd0b8d5f9ac0 :  dt Wdf01000!FxRequestFromLookaside
0xfffff800783abd98 : 0xffffdd0b8d5b95f0 :  dt Wdf01000!FxIoQueue
0xfffff800783abdf0 : 0xfffff80079c91790 : nt!KeAcquireSpinLockRaiseToDpc
0xfffff800783abe48 : 0xfffff80079c4450d : nt!KeInsertQueueApc+0x17d
0xfffff800783abe68 : 0xfffff80079e3ce06 : nt!KiRaiseSecurityCheckFailure+0x346
0xfffff800783abe70 : 0x0000000000000002 :  Trap @ fffff800783abe70
0xfffff800783abec8 : 0xfffff80079c91790 : nt!KeAcquireSpinLockRaiseToDpc
0xfffff800783abf78 : 0xfffff80079cba9a3 : nt!HalpInterruptSendIpi+0x103
0xfffff800783abfa0 : 0xffffdd0b8d5b95f0 :  dt Wdf01000!FxIoQueue
0xfffff800783abfb8 : 0xffffdd0b8d5f9ac0 :  dt Wdf01000!FxRequestFromLookaside
0xfffff800783ac018 : 0xfffff8007deb263d : Wdf01000!FxIrpQueue::RemoveIrpFromQueueByContext+0x51
0xfffff800783ac078 : 0xffffdd0b8b1b3410 :  dt Wdf01000!FxDevice

I can display the device name, by following the dt Wdf01000!FxDevice link at the bottom of the stack trace segment above...

0: kd> dx -id 0,0,ffffdd0b83afc040 -r1 (*((Wdf01000!_UNICODE_STRING *)0xffffdd0b8b1b34f8))
(*((Wdf01000!_UNICODE_STRING *)0xffffdd0b8b1b34f8))                 : "\Device\USBFDO-3" [Type: _UNICODE_STRING]
    [<Raw View>]     [Type: _UNICODE_STRING]

Unfortunately I have no idea what device USBFDO-3 actually is, but that's the closest I can get to it.

I would try unplugging all USB3.0 devices, reboot (to unload the driver(s)) and verify that it no longer BSODs.

I can also see in your driver list an ASUS Smart Doctor driver, IOMap64.sys (dated Nov 2020)...

0: kd> lmDvmIOMap64
Browse full module list
start             end                 module name
fffff800`905f0000 fffff800`905fa000   IOMap64    (deferred)           
    Image path: \??\C:\WINDOWS\system32\drivers\IOMap64.sys
    Image name: IOMap64.sys
    Browse all global symbols  functions  data
    Timestamp:        Mon Nov  2 08:42:10 2020 (5F9FAA42)
    CheckSum:         0000A0DC
    ImageSize:        0000A000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

This driver is known to cause BSODs on some systems, generally after resuming from sleep. I realise that's not the symptom you're experiencing but it's worth mentioning.

On other thing you might try is to start Windows in Safe Mode. In that mode only Windows drivers are loaded, no third-party drivers are loaded. That does mean that some device will lose functionality, or may not work at all. Your display for example, will have a reduced resolution because you'll be using the Windows basic display driver.

If it still BSODs in Safe Mode then it's most likely to be a hardware issue. If it doesn't BSOD then it's definitely a third party driver at fault and we'll need to figure out which one(s).

 

[ConorDuey2000]

I'm currently running the driver verifier. This morning, my computer froze, but it didn't give me any minidumps or dump files. Hopefully, next time my computer crashes, it'll give me a minidump or a dump file.

 

[ConorDuey2000]

I finally got my first BSOD as a result from running the driver verifier. It's a PFN_LIST_CORRUPT BSOD that was caused by iCUE.exe. Here is the minidump.

 

[ubuysa]

That's not a Driver Verifier created dump, it's actually a PFN_LIST_CORRUPT bugcheck (PFN is a page frame number) and these are typically caused by drivers mucking up their memory use.

Once again however, it seems to be a USB3.0 device that was being accessed at the time. In addition, in this dump there are ACPI calls too, as you can see in this call stack extract...

19 ffffd208`3b184d10 fffff802`21c5b924     Wdf01000!PreprocessIrp+0x57
1a (Inline Function) --------`--------     Wdf01000!DispatchWorker+0x3e11
1b (Inline Function) --------`--------     Wdf01000!FxDevice::Dispatch+0x3e20
1c ffffd208`3b184d40 fffff802`208ed0a5     Wdf01000!FxDevice::DispatchWithLock+0x3e64
1d ffffd208`3b184d90 fffff802`21f51342     nt!IofCallDriver+0x55
1e ffffd208`3b184dd0 fffff802`21f510da     ACPI!ACPIIrpDispatchDeviceControl+0xb2
1f ffffd208`3b184e10 fffff802`208ed0a5     ACPI!ACPIDispatchIrp+0xca
20 ffffd208`3b184e90 fffff809`a16680c0     nt!IofCallDriver+0x55
21 ffffd208`3b184ed0 fffff802`21c8e777     UsbHub3!HUBPDO_EvtDeviceWdmIrpPreprocess+0x4e0
22 ffffd208`3b184f90 fffff802`21c5b924     Wdf01000!PreprocessIrp+0x57
23 (Inline Function) --------`--------     Wdf01000!DispatchWorker+0x3e11
24 (Inline Function) --------`--------     Wdf01000!FxDevice::Dispatch+0x3e20
25 ffffd208`3b184fc0 fffff802`208ed0a5     Wdf01000!FxDevice::DispatchWithLock+0x3e64
26 ffffd208`3b185010 fffff802`21f51342     nt!IofCallDriver+0x55
27 ffffd208`3b185050 fffff802`21f510da     ACPI!ACPIIrpDispatchDeviceControl+0xb2
28 ffffd208`3b185090 fffff802`208ed0a5     ACPI!ACPIDispatchIrp+0xca
29 ffffd208`3b185110 fffff809`a97b1df7     nt!IofCallDriver+0x55

This all suggests that a USB3.0 device driver may not be handling power transitions properly. What devices do you have plugged in to a USB3.0 port? Can you unplug all USB3.0 devices temporarily and see whether the BSODs cease?

 

[ConorDuey2000]

I got another BSOD this morning. Hopefully, this should be a driver verifier created dump. It's an IRQL_NOT_LESS_OR_EQUAL BSOD that was caused by AsusCertService.exe. I have an ASUS motherboard, by the way,

Anyway, here is the minidump.

 

[ConorDuey2000]

I'm bumping this post because so far, I haven't gotten any successful help and I might have to end up buying a new and expensive computer in the future. I also got another BSOD this morning. It's a DPC_WATCHDOG_VIOLATION BSOD that was caused by dwm.exe.

Anyway, here is the minidump.

 

[ubuysa]

I've asked you several times to remove all USB3.0 devices and see whether the problem persists. The indications are, as I have illustrated, apparently related to USB3.0. So far you haven't done that.

If you think my help is not 'successful' enough for you then I'll gladly let others provide you with better assistance.

 

[ConorDuey2000]

I've asked you several times to remove all USB3.0 devices and see whether the problem persists. The indications are, as I have illustrated, apparently related to USB3.0. So far you haven't done that.

If you think my help is not 'successful' enough for you then I'll gladly let others provide you with better assistance.

I apologize for not listening to you. I updated Windows 11, yesterday, and I think that fixed my problem since I didn't get any BSODs this morning. However, once I get another BSOD, I'm unplugging all of the USB 3.0 devices from my computer.

 

[ConorDuey2000]

I recently updated Windows and now, the BSODs seem to have stopped. I'm still worried that it might get a BSOD, again. However, lghub_system_tray.exe is still crashing on startup. I wrote Logitech about this and they just told me to turn on G HUB in the taskbar settings. I did that and it didn't work. I replied to them with a crash dump file and I asked them to debug it. They haven't replied to me since and it's been five days.

Here is the latest crash dump for lghub_system_tray.exe. Hopefully, you can help me stop it from crashing.

 

[ubuysa]

Was the Logitech device (a mouse?) plugged into a USB3.0 port by any chance?

The dump you uploaded is a user mode dump, which means it relates to a problem in user mode code. Only the developer of the user mode application can debug that.

That said, the exception code is 0xC000027B, and that is a specific exception for UWP (Windows Store) apps. It's called a 'stowed exception' and it indicates that an asynchronous operation failed in a UWP app. I think the lghub_system_tray.exe process is a red-herring, it's the process that happened to be in control when the UWP app failed.

There is no indication of which UWP app might have been involved, but I do know that UWP apps (and the Microsoft Store itself) are very fussy about time and date. Ensure that your system time and date are set correctly.

TBH I'm not a fan of Logitech software (like G-Hub) and I stopped using Logitech devices because I found their software to be unreliable.

 

[ConorDuey2000]

Bad news. I got another BSOD, today. I was using Adobe Premiere Pro normally and I got a KMODE_EXCEPTION_NOT_HANDLED BSOD. After analyzing it in WinDbg, it told me that Adobe Premiere Pro.exe was the cause of the BSOD. Here is the minidump.

 

[ubuysa]

Can you upload the full kernel dump please? You'll find it in C:\Windows\memory.dmp. It will be too big to upload here, so upload it to the cloud somewhere with a link to it here. Remember to make it public.

We also need to test your RAM, so please download Memtest86. You will make a bootable USB drive using the downloaded tool. You will then boot that SB drive and Memtest86 will start. Let it complete all four iterations of the 13 different tests.

 

[ConorDuey2000]

Can you upload the full kernel dump please? You'll find it in C:\Windows\memory.dmp. It will be too big to upload here, so upload it to the cloud somewhere with a link to it here. Remember to make it public.

We also need to test your RAM, so please download Memtest86. You will make a bootable USB drive using the downloaded tool. You will then boot that SB drive and Memtest86 will start. Let it complete all four iterations of the 13 different tests.

I'll upload the kernel dump once I get another HYPERVISOR_ERROR BSOD or another IRQL_NOT_LESS_OR_EQUAL BSOD. I'll also upload it to a file sharing site that will only host it for thirty days so download it while you can. Also, I don't think that anything's wrong with my computer's RAM so I'll run Memtest86 as a last resort.

 

[ubuysa]

Well I actually wanted the kernel dump for that BSOD, but it's not important if you don't want to upload it. Note that there is only ever one kernel dump stored, the memory.dmp file will be overwritten by the next BSOD.

 

[ConorDuey2000]

I'm here to bump this thread, again, because after almost a week with no BSODs, I finally got another one. This one was a PAGE_FAULT_IN_NONPAGED_AREA BSOD that was caused by Corsair.Service.exe. I have a Corsair keyboard so I wonder if it has to do with USB 3.0 ports or anything like that.

Anyway, here is the minidump. Also, here is the kernel dump that I've compressed in a ZIP file and uploaded to a temporary file sharing website.

 

[ubuysa]

I'm here to bump this thread, again, because after almost a week with no BSODs, I finally got another one. This one was a PAGE_FAULT_IN_NONPAGED_AREA BSOD that was caused by Corsair.Service.exe. I have a Corsair keyboard so I wonder if it has to do with USB 3.0 ports or anything like that.

Is your Corsair keyboard plugged into a USB 3.0 port? I wouldn't have thought so....

We will need to consider enabling Driver Verifier soon, but before we go there it would be wise to check your RAM. Please download Memtest86 and use the extracted too imageUSB.exe) to create a bootable USB drive (the drive can be small, Memtest isn't large). Then boot that USB drive and Memtest will start running. Allow it to complete all four iterations of the 13 different tests (this may time several hours). If Memtest finds no errors after the four iterations then restart Memtest and do another 4 iterations of the tests.

Let's see how Memtest goes before moving on...