Question I'm getting random IRQL_NOT_LESS_OR_EQUAL BSODs on a regular basis ?

[ConorDuey2000]

Hello. As of recently, my computer is having some big problems. It's been getting IRQL_NOT_LESS_OR_EQUAL BSODs on a regular basis. I've tried debugging the BSODs using WinDbg, but they just told me "Process name: System" so that means I have no idea what's causing these BSODs. I've tried reinstalling various drivers, uninstalling various software, updating Windows, updating the BIOS, and everything else that I could do besides reinstalling Windows. I really don't wanna live with these random BSODs, anymore, and I was wondering if any of you could help me stop them from happening.

Here is the kernel dump and here are some minidumps.

PC Specs
Mobo: ASUS TUF GAMING X570-PLUS (WI-FI)
Mobo BIOS Version: American Megatrends Inc. 5021
CPU: AMD Ryzen 7 3800X 8-Core CPU
GPU: Nvidia GeForce RTX 2060
OS: Windows 11 Pro 24H2

UPDATE: I really need help, man. As of writing this, I've gotten at least ten BSODs in a single day and I wasn't even doing anything abnormal with my computer. I ask anybody reading this to try their best to help me stop my computer from getting these BSODs because they're really driving me crazy.

UPDATE 2: My situation has gotten much worse as of writing this. Now, my computer can't even make it past an hour without getting a BSOD. I'm currently doing everything I can to get these to stop. I've tried searching for these problems I have on Google, DuckDuckGo, and other search engines, but I haven't gotten any results. It seems like nobody else has this problem except for me. I'm calling for anybody who reads this to try and help me get these BSODs to stop happening as long as they're able to do so because at this point, my computer's almost unusable.

 

[ConorDuey2000]

have you tried replacing icue with this:

SignalRGB

Control and sync your RGB devices from one free application. SignalRGB is the only RGB software you'll ever need.

signalrgb.com

Armoury crate might be running whether you use it or not. Is it installed?
if you don't use it, uninstall it.

Here's the problem, though. In the past, I've uninstalled Armory Crate as well as iCUE (which I replaced with OpenRGB) and I still got those BSODs. This was before I reseated the RAM, so I should try uninstalling those programs again and see if I still get those BSODs. If I still get them, then I'm gonna leave my computer turned on in Safe Mode overnight and see if I get any BSODs.

 

[Colif]

try the safe mode first since they won't be running in it anyway

 

[ConorDuey2000]

try the safe mode first since they won't be running in it anyway

I tried to boot the computer into safe mode, but as soon as I logged on, I got another one of those IRQL_NOT_LESS_OR_EQUAL BSODs. This must be a hardware problem since no third parry drivers are loaded in safe mode. Is there any way I can get these BSODs to stop without paying hundreds of dollars just to replace my CPU and my motherboard?

 

[ubuysa]

That's not a good result but there is one more thing to try. Go into your current Power Option profile (probably Balanced), click Change advanced power settings, and then expand the Processor Power Management section to expand it. Change BOTH the Minimum processor state AND the Maximum processor state so they are BOTH 99%.

See whether the BSODs continue.

 

[Colif]

Doubt a new 5800x cost that much. Not now the 7800 & 9800 exist.

To be honest, I would take PC to a PC repair store and ask them to swap in a new CPU just to test if you still crash. Not saying buy one but they might have an old 5000 series CPU for testing purposes.
That would tell you if its CPU or motherboard at least.

Crashing in safe mode not good.
I assume you on BIOS 5021
https://www.asus.com/au/motherboard...sk_bios?model2Name=TUF-GAMING-X570-PLUS-WI-FI

 

[ConorDuey2000]

Doubt a new 5800x cost that much. Not now the 7800 & 9800 exist.

To be honest, I would take PC to a PC repair store and ask them to swap in a new CPU just to test if you still crash. Not saying buy one but they might have an old 5000 series CPU for testing purposes.
That would tell you if its CPU or motherboard at least.

Crashing in safe mode not good.
I assume you on BIOS 5021
https://www.asus.com/au/motherboard...sk_bios?model2Name=TUF-GAMING-X570-PLUS-WI-FI

Yeah. I'm on BIOS 5021. Anyway, the 5000x is still pretty expensive and I'm not even sure if the CPU's causing all of these BSODs. I'm not taking my PC to a repair store, either, because I've had bad experiences with the only one in town. I've sent in laptops I've asked them to repair, but all that they did was just keep them in their store for about a month or two before reformatting Windows and sending the computer back to me. Plus, getting my computer repaired at a store is also pretty expensive.

 

[ConorDuey2000]

I finally got a BSOD that wasn't an IRQL_NOT_LESS_OR_EQUAL BSOD. In fact, it's a BSOD that I think I've never had on my computer, before. It was a KERNEL_THREAD_PRIORITY_FLOOR_VIOLATION BSOD caused by the process name "System". Here is the kernel dump for that BSOD. Also, here is a collection of the latest minidumps Windows created.

 

[ConorDuey2000]

I just got another BSOD that wasn't an IRQL_NOT_LESS_OR_EQUAL BSOD and my computer wasn't idle. I was using my computer normally and I got a DRIVER_OVERRAN_STACK_BUFFER BSOD. I'm certain that this is the first time I've ever gotten such a BSOD. Of course, the process name was "System" so I don't know what caused that BSOD. Here is the kernel dump and here is the minidump.

Anyway, as of writing this, my BSOD situation hasn't gotten any better. I need your help to stop them. Also, I won't accept any suggestions like "Buy a new CPU.", "Buy a new motherboard.", "Take your computer to a repair shop.", etc. because I don't have all the money in the world and I have other good reasons not to use your suggestions to try and stop these BSODs. All that I want you to do is analyze the dumps and see what's causing these BSODs. I'm not spending hundreds of dollars, I'm not reformatting Windows and losing all of the files on my C drive, and I'm definitely not taking my computer to a horrible repair shop that has done nothing but scam me in the past. Keep in mind that they make me pay a king's ransom just to leave it in their store for about a month or two, reformat Windows, and send it back to me. Even when I literally told them not to reformat Windows, they did it, anyway.

Finally, I'm gonna try one more thing that I haven't done. I'm gonna create a restore point and run Driver Verifier. That's gotta help stop these BSODs in at least one way.

 

[ubuysa]

You're asking for help and then ignoring what we're advising and going off on your own.

Have you tried changing the processor power options as I suggested in post #29?

I'm pretty confident that this is a CPU issue (and the power options change may mitigate the issue). Running Driver Verifier won't help. In any case, Driver Verifier needs to be run with specific options to be of any use.

 

[ConorDuey2000]

Have you tried changing the processor power options as I suggested in post #29?

Thanks. Sorry if you thought that I was ignoring you. I completely forgot to read post 29. Anyway, I did what you suggested in that post. My power plan is AMD Ryzen Balanced. The maximum processor state was set to 100% and I changed it to 99%. I've also disabled all Corsair services and restarted my computer after I did so. Again, I'm sorry for having you think I was ignoring you. Having multiple BSODs on a daily basis caused me to lose my mind.

 

[ConorDuey2000]

Thanks. Sorry if you thought that I was ignoring you. I completely forgot to read post 29. Anyway, I did what you suggested in that post. My power plan is AMD Ryzen Balanced. The maximum processor state was set to 100% and I changed it to 99%. I've also disabled all Corsair services and restarted my computer after I did so. Again, I'm sorry for having you think I was ignoring you. Having multiple BSODs on a daily basis caused me to lose my mind.

Bad news. Changing my processor state made it worse. Less than thirty minutes after I did that, my computer got a BSOD. Then, after my computer restarted, it got another BSOD a minute after I logged on. I've now set my power plan to AMD Ryzen High Performance and now I'm gonna see if I stop getting these BSODs. Here is the first minidump, here is the second minidump, and here is a kernel dump.

@ubuysa Do you wanna suggest any other power plan settings I should change?

UPDATE: It seems that changing my power plan to AMD Ryzen High Performance did nothing. I got a BSOD less than an hour after changing my power plan to that. Now, I've changed my power plan to Balanced (Not AMD Ryzen Balanced. Just the regular Balanced) and I've also changed the both minimum and maximum processor states to 99% for that power plan. If I still get a BSOD, I'm gonna need a whole lot more help.

 

[Colif]

Yeah. I'm on BIOS 5021. Anyway, the 5000x is still pretty expensive and I'm not even sure if the CPU's causing all of these BSODs. I'm not taking my PC to a repair store, either, because I've had bad experiences with the only one in town. I've sent in laptops I've asked them to repair, but all that they did was just keep them in their store for about a month or two before reformatting Windows and sending the computer back to me. Plus, getting my computer repaired at a store is also pretty expensive.

If I still get a BSOD, I'm gonna need a whole lot more help.

If problem is the CPU, its never going to get better until you replace it. We can't do anything to fix it from here. No software fixes can fix hardware.

I would look around for the cheapest 3000 or 5000 series CPU you can find and buy it and swap it in just to check if it fixes it... since you not willing to take it to a shop. If PC works with it, you know it was CPU. Then you can either live with one you bought or save towards another 5800x.

 

[ubuysa]

Now those two recent minidumps are subtly different. In both these dumps the fltmgr.sys Windows driver is called, that indicates that one or more filter drivers were involved here, and that may be significant. I think that before spending money on a new CPU we should at least confirm that this isn't a driver issue. To do that I'd like you to enable Driver Verifier...

Driver Verifier subjects selected drivers (typically all third-party drivers) to extra tests and checks every time they are called. These extra checks are designed to uncover drivers that are misbehaving. If any selected driver fails any of the Driver Verifier tests/checks then Driver Verifier will BSOD. The resulting minidump should contain enough information for us to identify the flaky driver. It's thus essential to keep all minidumps created whilst Driver Verifier is enabled.

To enable Driver Verifier do the following:

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...

• Special Pool
• Force IRQL checking
• Pool Tracking
• Deadlock Detection
• Security Checks
• Miscellaneous Checks
• Power framework delay fuzzing
• DDI compliance checking

Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...

• Wdf01000.sys
• ndis.sys
• fltMgr.sys
• Storport.sys

These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running for 48 hours, use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing. The Driver Verifier generated BSODs are these...

• 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
• 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
• 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
• 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
• 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
• 0xE6: DRIVER_VERIFIER_DMA_VIOLATION

If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verifier is enabled or not, open a command prompt and enter the command verifier /query. If drivers are listed then it's enabled, if no drivers are listed then it's not.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).

 

[ConorDuey2000]

To enable Driver Verifier do the following:

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...

• Special Pool
• Force IRQL checking
• Pool Tracking
• Deadlock Detection
• Security Checks
• Miscellaneous Checks
• Power framework delay fuzzing
• DDI compliance checking

Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...

• Wdf01000.sys
• ndis.sys
• fltMgr.sys
• Storport.sys

These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running for 48 hours, use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing. The Driver Verifier generated BSODs are these...

• 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
• 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
• 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
• 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
• 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
• 0xE6: DRIVER_VERIFIER_DMA_VIOLATION

If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verifier is enabled or not, open a command prompt and enter the command verifier /query. If drivers are listed then it's enabled, if no drivers are listed then it's not.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).

I've done exactly what this tutorial said. I created a restore point, first, and then I did the appropriate steps while enabling Driver Verifier. After restarting my computer, as soon as it started up, it got a BSOD and it was boot looping. The BSOD was a "DRIVER_VERIFIER_DETECTED_VIOLATION" BSOD. Luckily, since I created that restore point, I got into the recovery environment and restored to the restore point that I created. Now, the computer doesn't boot loop, anymore, and Driver Verifier is turned off. Here is the minidump of the BSOD that happened while Driver Verifier was on.

 

[ConorDuey2000]

I've done exactly what this tutorial said. I created a restore point, first, and then I did the appropriate steps while enabling Driver Verifier. After restarting my computer, as soon as it started up, it got a BSOD and it was boot looping. The BSOD was a "DRIVER_VERIFIER_DETECTED_VIOLATION" BSOD. Luckily, since I created that restore point, I got into the recovery environment and restored to the restore point that I created. Now, the computer doesn't boot loop, anymore, and Driver Verifier is turned off. Here is the minidump of the BSOD that happened while Driver Verifier was on.

I've analyzed the minidump and it turns out that it was related to "AsusCertService.exe" so I disabled all services relating to Asus. However, I still got a BSOD less than an hour later. I analyzed that BSOD and it said that Google Chrome caused it. Here is the kernel dump and here is the minidump.

 

[ubuysa]

That 0xC4 bugcheck in post #39 is key. I'm guessing you analysed it with BlueScreenView, which is as much use for BSOD analysis as a chocolate teapot. The actual cause of that BSOD was a VMWare driver called vmnetadapter.sys. You can see it here on the call stack leading up to the bugcheck (read this from the bottom up)...

5: kd> k
 # Child-SP          RetAddr               Call Site
00 fffff90d`f430efa8 fffff800`9ac62a7d     nt!KeBugCheckEx
01 fffff90d`f430efb0 fffff800`9ac7d074     nt!CarReportRuleViolationFromNt+0x179
02 fffff90d`f430f060 fffff800`9ac72cc4     nt!ViMiscCheckKeRaiseIrql+0x68
03 fffff90d`f430f0b0 fffff800`9a700601     nt!VfMiscKeAcquireSpinLockRaiseToDpc_Entry+0x24
04 fffff90d`f430f0e0 fffff800`9ac7d338     nt!DifKeAcquireSpinLockRaiseToDpcWrapper+0xb1
05 fffff90d`f430f130 fffff800`2d243164     nt!VerifierKeAcquireSpinLockRaiseToDpc+0x28
06 fffff90d`f430f160 fffff800`2d24259f     ndis!ndisMRawIndicateStatusEx+0xb94
07 fffff90d`f430f290 fffff800`2d239c8a     ndis!ndisMpHookDefaultIndicateStatus+0xf
08 fffff90d`f430f2c0 fffff804`276116b8     ndis!NdisMIndicateStatusEx+0x3a
09 fffff90d`f430f300 fffff90d`f430f370     vmnetadapter+0x16b8
0a fffff90d`f430f308 fffff90d`f430f3a0     0xfffff90d`f430f370
0b fffff90d`f430f310 00000000`00000000     0xfffff90d`f430f3a0

If we examine frame 9, where the vmnetadapter.sys driver is called, we can see the problem...

5: kd> .frame /r 9
09 fffff90d`f430f300 fffff90d`f430f370     vmnetadapter+0x16b8
rax=0000000000000000 rbx=ffffc28ef3bcf000 rcx=00000000000000c4
rdx=0000000000000030 rsi=ffffc28ef2f37a50 rdi=0000000000000002
rip=fffff804276116b8 rsp=fffff90df430f300 rbp=fffff90df430f369
 r8=000000000000000f  r9=0000000000000002 r10=0000fffff8009ac7
r11=ffff70fd22e00000 r12=ffffc28f09fe9080 r13=0000000000000001
r14=fffff8002d2f1198 r15=fffff8002d2cb460
iopl=0         nv up di pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040002
vmnetadapter+0x16b8:
fffff804`276116b8 ?? ???

At the bottom there is the offset into vmnetadapter,sys where the next instruction is to be fetched from (address fffff804`276116b8) but that address is invalid, note the ???.

The offset 0x1b68 is within the module, as we can see here...

5: kd> lmvm vmnetadapter
Browse full module list
start             end                 module name
fffff804`27610000 fffff804`2761b000   vmnetadapter T (no symbols)        
    Loaded symbol image file: vmnetadapter.sys
    Image path: vmnetadapter.sys
    Image name: vmnetadapter.sys
    Browse all global symbols  functions  data  Symbol Reload
  Timestamp:        Thu Mar 11 03:23:31 2021 (60497113)
    CheckSum:         000110C5
    ImageSize:        0000B000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

That means the issue is one for VMWare. We can also see that this driver is old, dating from March 2021. To confirm this VMWare driver as the source of your problems I would uninstall VMWare completely (if temporarily) and confirm that the BSODs stop. I would then look for the current version of VMWare to install.

The main advantage of Driver Verifier is that we know for certain that this driver is misbehaving, so it's important to sort that out before moving on.

 

[ConorDuey2000]

That 0xC4 bugcheck in post #39 is key. I'm guessing you analysed it with BlueScreenView, which is as much use for BSOD analysis as a chocolate teapot. The actual cause of that BSOD was a VMWare driver called vmnetadapter.sys. You can see it here on the call stack leading up to the bugcheck (read this from the bottom up)...

5: kd> k
 # Child-SP          RetAddr               Call Site
00 fffff90d`f430efa8 fffff800`9ac62a7d     nt!KeBugCheckEx
01 fffff90d`f430efb0 fffff800`9ac7d074     nt!CarReportRuleViolationFromNt+0x179
02 fffff90d`f430f060 fffff800`9ac72cc4     nt!ViMiscCheckKeRaiseIrql+0x68
03 fffff90d`f430f0b0 fffff800`9a700601     nt!VfMiscKeAcquireSpinLockRaiseToDpc_Entry+0x24
04 fffff90d`f430f0e0 fffff800`9ac7d338     nt!DifKeAcquireSpinLockRaiseToDpcWrapper+0xb1
05 fffff90d`f430f130 fffff800`2d243164     nt!VerifierKeAcquireSpinLockRaiseToDpc+0x28
06 fffff90d`f430f160 fffff800`2d24259f     ndis!ndisMRawIndicateStatusEx+0xb94
07 fffff90d`f430f290 fffff800`2d239c8a     ndis!ndisMpHookDefaultIndicateStatus+0xf
08 fffff90d`f430f2c0 fffff804`276116b8     ndis!NdisMIndicateStatusEx+0x3a
09 fffff90d`f430f300 fffff90d`f430f370     vmnetadapter+0x16b8
0a fffff90d`f430f308 fffff90d`f430f3a0     0xfffff90d`f430f370
0b fffff90d`f430f310 00000000`00000000     0xfffff90d`f430f3a0

If we examine frame 9, where the vmnetadapter.sys driver is called, we can see the problem...

5: kd> .frame /r 9
09 fffff90d`f430f300 fffff90d`f430f370     vmnetadapter+0x16b8
rax=0000000000000000 rbx=ffffc28ef3bcf000 rcx=00000000000000c4
rdx=0000000000000030 rsi=ffffc28ef2f37a50 rdi=0000000000000002
rip=fffff804276116b8 rsp=fffff90df430f300 rbp=fffff90df430f369
 r8=000000000000000f  r9=0000000000000002 r10=0000fffff8009ac7
r11=ffff70fd22e00000 r12=ffffc28f09fe9080 r13=0000000000000001
r14=fffff8002d2f1198 r15=fffff8002d2cb460
iopl=0         nv up di pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040002
vmnetadapter+0x16b8:
fffff804`276116b8 ?? ???

At the bottom there is the offset into vmnetadapter,sys where the next instruction is to be fetched from (address fffff804`276116b8) but that address is invalid, note the ???.

The offset 0x1b68 is within the module, as we can see here...

5: kd> lmvm vmnetadapter
Browse full module list
start             end                 module name
fffff804`27610000 fffff804`2761b000   vmnetadapter T (no symbols)       
    Loaded symbol image file: vmnetadapter.sys
    Image path: vmnetadapter.sys
    Image name: vmnetadapter.sys
    Browse all global symbols  functions  data  Symbol Reload
  Timestamp:        Thu Mar 11 03:23:31 2021 (60497113)
    CheckSum:         000110C5
    ImageSize:        0000B000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

That means the issue is one for VMWare. We can also see that this driver is old, dating from March 2021. To confirm this VMWare driver as the source of your problems I would uninstall VMWare completely (if temporarily) and confirm that the BSODs stop. I would then look for the current version of VMWare to install.

The main advantage of Driver Verifier is that we know for certain that this driver is misbehaving, so it's important to sort that out before moving on.

Thanks for the help. I didn't use BlueScreenView to analyze the BSODs. I used WinDbg. anyway, I've uninstalled VMWare from my computer. I don't even use it. That's because every time I ran VMWare or WSL on my computer, I'd get a HYPERVISOR_ERROR BSOD. Now, I use QEMU as my main virtual machine program and I run WSL on another computer that I have. Anyway, I hope that uninstalling VMWare stops these BSODs.

 

[ConorDuey2000]

It seems that uninstalling VMware didn't get the BSODs to stop. I was using my computer as normal and I suddenly got another BSOD. I'm not good at analyzing BSODs so I hope that you're able to analyze this BSOD. Here is the kernel dump and here is the minidump.

 

[ubuysa]

That it won't boot into Safe Mode is pretty convincing evidence that this is a hardware problem, and based on everything we've seen it's most likely to be the CPU.

I think it's worth stress testing your CPU. This WILL make your CPU run hot, so before you do anything give the PC a good clean. Clean all the fans (and the blades), ensure that your CPU cooler is functioning properly (what cooler do you have?) and place the PC in a location where it has cool air all around it. Then do the following....

1. Download Prime95 and a CPU temperature monitor (CoreTemp will do).
2. Keep the temperature monitor running all the time you run Prime95. Your CPU will get hot!
3. Run each of the three Prime95 tests (smallFFTs, largeFFTs, and Blend) one after the other for a minimum of 1 hour per test, 2 hours per test would be better.
4. If Prime95 generates error messages, if the system crashes/freezes/BSODs, or if your CPU temp reaches 95°C (Tmax for your CPU), then stop Prime95 and let us know what happened.

Note that a properly cooled and stable CPU should be able to run all Prime95 tests pretty much indefinitely.

FYI: The small FFT test stresses the CPU more than RAM. The large FFT test stresses RAM more than the CPU. The Blend test is a mixture of the two.

 

[ConorDuey2000]

That it won't boot into Safe Mode is pretty convincing evidence that this is a hardware problem, and based on everything we've seen it's most likely to be the CPU.

I think it's worth stress testing your CPU. This WILL make your CPU run hot, so before you do anything give the PC a good clean. Clean all the fans (and the blades), ensure that your CPU cooler is functioning properly (what cooler do you have?) and place the PC in a location where it has cool air all around it. Then do the following....

1. Download Prime95 and a CPU temperature monitor (CoreTemp will do).
2. Keep the temperature monitor running all the time you run Prime95. Your CPU will get hot!
3. Run each of the three Prime95 tests (smallFFTs, largeFFTs, and Blend) one after the other for a minimum of 1 hour per test, 2 hours per test would be better.
4. If Prime95 generates error messages, if the system crashes/freezes/BSODs, or if your CPU temp reaches 95°C (Tmax for your CPU), then stop Prime95 and let us know what happened.

Note that a properly cooled and stable CPU should be able to run all Prime95 tests pretty much indefinitely.

FYI: The small FFT test stresses the CPU more than RAM. The large FFT test stresses RAM more than the CPU. The Blend test is a mixture of the two.

I've thought about running Prime95, but I was worried that it might do permanent damage to my CPU. Will it cause any permanent damage to my CPU?

 

[ConorDuey2000]

In the meantime, I'd like to show you this APC_INDEX_MISMATCH BSOD that I just got while using my computer normally. Nothing special, but it's worth analyzing since this is the first time I got an APC_INDEX_MISMATCH BSOD during since my current BSOD problem started. Here is the kernel dump and here is the minidump.

 

[ubuysa]

I've thought about running Prime95, but I was worried that it might do permanent damage to my CPU. Will it cause any permanent damage to my CPU?

No. It is true that it runs the CPU hard and that it will get hot, but a properly cooled and stable system can run Prime95 indefinitely without causing any damage. The reason you see people claiming that it does damage the CPU is because if you run it for long periods, much longer that I'm suggesting, on a CPU that has insufficient cooling, and which thus overheats, then you will damage the CPU. But that's not the fault of Prime95, it's because the builder installed insufficient CPU cooling.

We ask you to run a temperature monitor for exactly this reason, and you need to watch the CPU temp as you run Prime95 - especially on the smallFFT test. If the CPU temp exceeds 90°C then it's running very hot. If it approaches 95°C, then it's running too hot because that's the maximum safe operating temperature for that CPU. In that case stop Prime95 immediately and tell us what happened.

As long as you monitor temperatures, and give the PC a good clean before starting, you will not damage anything.

There is no point in you posting further dumps, or anything else, until you have run those three Prime95 tests for an hour each - minimum. If any of them generate errors, if the system crashes or BSODs, or if the CPU temp approaches 95°C, then you can be pretty confident your CPU is faulty (or your cooling is inadequate if the temp rises too high, in which case you've already probably cooked the CPU).

 

[ConorDuey2000]

No. It is true that it runs the CPU hard and that it will get hot, but a properly cooled and stable system can run Prime95 indefinitely without causing any damage. The reason you see people claiming that it does damage the CPU is because if you run it for long periods, much longer that I'm suggesting, on a CPU that has insufficient cooling, and which thus overheats, then you will damage the CPU. But that's not the fault of Prime95, it's because the builder installed insufficient CPU cooling.

We ask you to run a temperature monitor for exactly this reason, and you need to watch the CPU temp as you run Prime95 - especially on the smallFFT test. If the CPU temp exceeds 90°C then it's running very hot. If it approaches 95°C, then it's running too hot because that's the maximum safe operating temperature for that CPU. In that case stop Prime95 immediately and tell us what happened.

As long as you monitor temperatures, and give the PC a good clean before starting, you will not damage anything.

There is no point in you posting further dumps, or anything else, until you have run those three Prime95 tests for an hour each - minimum. If any of them generate errors, if the system crashes or BSODs, or if the CPU temp approaches 95°C, then you can be pretty confident your CPU is faulty (or your cooling is inadequate if the temp rises too high, in which case you've already probably cooked the CPU).

At what temperature should I stop Prime95 before an hour has passed so that my CPU won't get cooked? Should it be 90°C or lower? Can I also use Windows as I normally would while Prime95 is running? By the way, I'll stop posting links to my BSOD dumps until I run each of the Prime95 tests.

 

[ubuysa]

As long as the CPU temp is less than 90°C your CPU will be fine.

 

[ConorDuey2000]

Okay.