Question "IRQL Not Less or Equal" BSOD ?

[illyaska]

Hello, these past few months i have been upset about a lot of BSOD, I tried everything, i red every forums about the same BSOD that i have.
So i came here to (i hope) stop these bsod definitely.

Motherboard: Asus Prime B450M-A
CPU: AMD Ryzen 5-3600
RAM: CORSAIR - Vengeance RGB Pro 32GB (16GBx2) DDR4 3200MHz
SSD1: KINGSTON SA400 240gb
HDD2: SeagaTe 1000gb
GPU: Nvidia RTX 2060 6GB
OS: Windows 11

My dumpfiles :
https://www.mediafire.com/file/rn8r8jfgqtuu5mc/crash.rar/file

I hope someone help me, i think it's a hardware problem but i wanna be sure

 

[Satan-IR]

Welcome to the forums!

Please also include the PSU brad/model and age. Some Ryzen boards are a bit fussy with RAM and ecpecially with some Corsair models. We will try to find the casuse of the problem possibly.

I'm afraid these are not actual dump files.

On Thu 14/03/2024 05:55:59 your computer crashed or a problem was reported
crash dump file: C:\Windows\Minidumps\031424-7250-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x4177F0)
Bugcheck code: 0xA (0xFFFFF80100005920, 0x2, 0x1, 0xFFFFF8015CE333EA)
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 abo...ows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.

These are brief description of what the dumps show. You have to upload those files with the suffix .dmp in the folder/address mentioned in the texts/reports: C:\Windows\Minidumps\

Upload those *.dmp files, post links here and we can have a look at them.

 

[illyaska]

Here is my full setup ( the ram are not the same cuz i already have an issue with the olds one) :

https://imgur.com/a/mXnbZBg

View: https://imgur.com/a/mXnbZBg


And my minidumps :
https://www.mediafire.com/file/v2n2z79ekbktlw8/minidumps.rar/file

Thank you for your answer sir !

 

[Satan-IR]

No problem, glad to help.

( the ram are not the same cuz i already have an issue with the olds one)

What exactly do you mean by this? You had problem with other RAM and you changed them with the ones you have now?

You aren't mixing old/new RAM by any chance? Or RAM that didn't come as a kit/pack? Are you running a DOCP? Which I think is what Asu call the RAM overclocking in their boards?

Have you updated the chipset and all other board drivers to the lates verions provided on the Asus website for your board?

Have you tried to reset BIOS to defaults or CMOS?

Have you tried running the SFC /scannow command from an elevated Command Prompt? That is type CMD in Windows search, when CMD shows up right click on it as click 'Run as administrator'. Then type SFC /scannow. This will fix system files if they are corrupted for some reason.

Do you have any anti-virus program installed or are you using Windows Defender that comes with Windows?

Low quality PSUs that can not provide system with enough clean power also cause BSODs and shutdowns etc. That Corsair CV 550 is a low quality unit. How old is the PSU? RTX 2060 is not very highly demanding power-hungry card but I personally wouldn't run that and a Ryzen 5 with that PSU.

 

[illyaska]

No problem, glad to help.


What exactly do you mean by this? You had problem with other RAM and you changed them with the ones you have now?

You aren't mixing old/new RAM by any chance? Or RAM that didn't come as a kit/pack? Are you running a DOCP? Which I think is what Asu call the RAM overclocking in their boards?

Have you updated the chipset and all other board drivers to the lates verions provided on the Asus website for your board?

Have you tried to reset BIOS to defaults or CMOS?

Have you tried running the SFC /scannow command from an elevated Command Prompt? That is type CMD in Windows search, when CMD shows up right click on it as click 'Run as administrator'. Then type SFC /scannow. This will fix system files if they are corrupted for some reason.

Do you have any anti-virus program installed or are you using Windows Defender that comes with Windows?

Low quality PSUs that can not provide system with enough clean power also cause BSODs and shutdowns etc. That Corsair CV 550 is a low quality unit. How old is the PSU? RTX 2060 is not very highly demanding power-hungry card but I personally wouldn't run that and a Ryzen 5 with that PSU.

-Idk, one day i started my pc didn't want to start bcz of 1 ram wasn't working. So i bought the corsair's RAM.

-No mixing, yes i'm running the default DOCP. Should I desactivate it ?

-I updated everything, just have the amd bus doesn't want to be updated idk why.

-No i never tried, Should i do it ?

-Yes i already tried to run a sfc /scannow a long time ago, i can do it again.

-Yes i'm using windows defender.

-I bought this pc in July 2020, so everything except the RAMs have the same age, i didn't know, i thought it was the best for my budget.

I wanted to say that i had to desactivate hyper-v in the bios, idk why it always crashes with HYPERVISOR_ERROR since windows 11 (6-7 months).

 

[Satan-IR]

-Idk, one day i started my pc didn't want to start bcz of 1 ram wasn't working. So i bought the corsair's RAM.

I see, so the two RAM sticks came as a kit/pack, right?

-No mixing, yes i'm running the default DOCP. Should I desactivate it ?

No Mmixing is good. Yes you can check and see if deactivating the DOCP would stop the BSODs.

-I updated everything, just have the amd bus doesn't want to be updated idk why.

AMD Bus? You mean the chipset driver? What do you mean it doesn't want to be updated? You downloaded the latest version driver from Asus website, right? And when you want to run it to setup/update you get an error?

-No i never tried, Should i do it ?

If you mean resetting the BIOS to defaults yes, even resetting the CMOS won't hurt. Although any changes you've made such as the DOCP profile you activated would be reset. You need to apply them again later if you want.

I would reset CMOS. Then put one of the RAM sticks where mothrboard manual specifies for single RAM operation (A2 - second slot from CPU) and boot system and go into BIOS. See if it's recognized, save BIOS. Turn off put second RAM stick in the proper slot (B2 - fourth slot from CPU) and reboot again.

Yes i already tried to run a sfc /scannow a long time ago, i can do it again.

This won't hurt either. You can also run the DISM and repair the Windows image if necessary. You can see how here.

-I bought this pc in July 2020, so everything except the RAMs have the same age, i didn't know, i thought it was the best for my budget.

Yes it's not that old but those were not really good PSUs. Low quality PSUs that can not provide clean power can cause issues. Although in your case I think it's less likely to be the PSU.

I wanted to say that i had to desactivate hyper-v in the bios, idk why it always crashes with HYPERVISOR_ERROR since windows 11 (6-7 months).

Yes one of the dumps I checked randomly pointed to the hyper-v too. But deactivating it did not stop the BSODs, or did it? Do they happen less often or with longet interval?

Another thing you can do is check event viewer and see if Event Viewer in Windows shows anything in partilucar especialyl when the BSODs happen.

 

[illyaska]

I see, so the two RAM sticks came as a kit/pack, right?


No Mmixing is good. Yes you can check and see if deactivating the DOCP would stop the BSODs.


AMD Bus? You mean the chipset driver? What do you mean it doesn't want to be updated? You downloaded the latest version driver from Asus website, right? And when you want to run it to setup/update you get an error?


If you mean resetting the BIOS to defaults yes, even resetting the CMOS won't hurt. Although any changes you've made such as the DOCP profile you activated would be reset. You need to apply them again later if you want.

I would reset CMOS. Then put one of the RAM sticks where mothrboard manual specifies for single RAM operation (A2 - second slot from CPU) and boot system and go into BIOS. See if it's recognized, save BIOS. Turn off put second RAM stick in the proper slot (B2 - fourth slot from CPU) and reboot again.



This won't hurt either. You can also run the DISM and repair the Windows image if necessary. You can see how here.


Yes it's not that old but those were not really good PSUs. Low quality PSUs that can not provide clean power can cause issues. Although in your case I think it's less likely to be the PSU.



Yes one of the dumps I checked randomly pointed to the hyper-v too. But deactivating it did not stop the BSODs, or did it? Do they happen less often or with longet interval?

Another thing you can do is check event viewer and see if Event Viewer in Windows shows anything in partilucar especialyl when the BSODs happen.

-Yes it came as a pack.

-I activated DOCP because i thought it'll resolve the BSOD, so i think nothing will change, i will do it tho.

-Yes this one : "amd_chipset_software_6.01.25.342". It says updated succesfully but when i'm looking for any update, the AMD Bus still appears.

-Ok when i'll be back home, i'll try everything u told me and i'll tell you if the bsod still appears.

-I'll try DISM too.

-Ok but anyway i was going to buy a new pc next year, i'll not make the same mistake, thank you.

-Same, i have like 4-5 bsod per day, since 1-2 months. Before it was 1 bsod per day.

-I already tried something similar it was Driver verifier, and it told me that if i remember it was "logi_surrond.sys" something like that, but after i remove it all, nothing changed. I'll try "Event viewer" like you said.

So I think i'll start with the hardware check, then the dism, etc ...

Thank you again for helping me, you don't know how i'm tired abt these bsod i tried everything.

 

[ubuysa]

Hyper-V and the Windows hypervisor are two different animals. Windows internally uses virtual machines controlled by the Windows hypervisor, this is a separate entity from Hyper-V which allow the user to run virtual machines. The 0x20001 BSOD was reporting a Windows hypervisor problem, not a Hyper-V problem.

These dumps are very varied and my take on this is that a hardware problem is more likely than a driver problem. I'm in full agreement with @Satan-IR that a poor PSU could easily be the root cause here. I also fully agree regarding their points regarding RAM. I'm not at all sure whether that cooler is good enough either.

If you've already enabled Driver Verifier once then it might be wise to enable it again, but this time with the right set of options...
To enable Driver Verifier properly please 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.

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 Verfier 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).

Driver Verifier will then highlight any flaky third-party drivers you may have installed. If you've not had a Driver Verifier triggered BSOD (0xC1, 0xC4, 0xC6, 0xC9, 0xD6, 0xE6) after 48 hours then it's most unlikely to be a driver problem.

 

[Satan-IR]

-Yes it came as a pack.

-I activated DOCP because i thought it'll resolve the BSOD, so i think nothing will change, i will do it tho.

-Yes this one : "amd_chipset_software_6.01.25.342". It says updated succesfully but when i'm looking for any update, the AMD Bus still appears.

-Ok when i'll be back home, i'll try everything u told me and i'll tell you if the bsod still appears.

-I'll try DISM too.

-Ok but anyway i was going to buy a new pc next year, i'll not make the same mistake, thank you.

-Same, i have like 4-5 bsod per day, since 1-2 months. Before it was 1 bsod per day.

-I already tried something similar it was Driver verifier, and it told me that if i remember it was "logi_surrond.sys" something like that, but after i remove it all, nothing changed. I'll try "Event viewer" like you said.

So I think i'll start with the hardware check, then the dism, etc ...

Thank you again for helping me, you don't know how i'm tired abt these bsod i tried everything.

Well we weren't aware that you had tried Driver Verifier before and it showed some driver (related to a Logitech device perhaps? Headset or something like that?) as problematic.

I too went through the dumps and the 5 dump files show 4 different kinds of errors/problems which I too think can point to a hardware issue.

Hyper-V and the Windows hypervisor are two different animals. Windows internally uses virtual machines controlled by the Windows hypervisor, this is a separate entity from Hyper-V which allow the user to run virtual machines. The 0x20001 BSOD was reporting a Windows hypervisor problem, not a Hyper-V problem.

Ubuysa is right about this. One of the dumps point to a Windows Hyper Visor.

Again, a variety of different BSODs makes a hardware issue not very unlikely. I suggest you follow what @ubuysa posted step by step so we can verify if there's a problematic driver involved or not. I want to emphasize the part about the Windows/System image or making a Restore Point too. If you don't do that there's possibility of the BSOD loop.

 

[illyaska]

Hyper-V and the Windows hypervisor are two different animals. Windows internally uses virtual machines controlled by the Windows hypervisor, this is a separate entity from Hyper-V which allow the user to run virtual machines. The 0x20001 BSOD was reporting a Windows hypervisor problem, not a Hyper-V problem.

These dumps are very varied and my take on this is that a hardware problem is more likely than a driver problem. I'm in full agreement with @Satan-IR that a poor PSU could easily be the root cause here. I also fully agree regarding their points regarding RAM. I'm not at all sure whether that cooler is good enough either.

If you've already enabled Driver Verifier once then it might be wise to enable it again, but this time with the right set of options...
To enable Driver Verifier properly please 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.

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 Verfier 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).

Driver Verifier will then highlight any flaky third-party drivers you may have installed. If you've not had a Driver Verifier triggered BSOD (0xC1, 0xC4, 0xC6, 0xC9, 0xD6, 0xE6) after 48 hours then it's most unlikely to be a driver problem.

Okay i followed all of your instructions, now i will wait until tuesday.
If driver verifier isn't detecting anything. Should it be a hardware problem ?
And also, when i'm playing games i had never crash

 

[illyaska]

Well we weren't aware that you had tried Driver Verifier before and it showed some driver (related to a Logitech device perhaps? Headset or something like that?) as problematic.

I too went through the dumps and the 5 dump files show 4 different kinds of errors/problems which I too think can point to a hardware issue.


Ubuysa is right about this. One of the dumps point to a Windows Hyper Visor.

Again, a variety of different BSODs makes a hardware issue not very unlikely. I suggest you follow what @ubuysa posted step by step so we can verify if there's a problematic driver involved or not. I want to emphasize the part about the Windows/System image or making a Restore Point too. If you don't do that there's possibility of the BSOD loop.

I did the clear CMOS, but honestly i think it's probably my cpu that got thermal issue because of the ventirad.
But i want to be sure, i don't wanna spend any money for nothing.

 

[ubuysa]

If driver verifier isn't detecting anything. Should it be a hardware problem ?

If Driver Verifier doesn't fail any third-party drivers then it most likely is a hardware problem. But let's wait and see first.

 

[illyaska]

Ok, here are the 2 crash from driver verifier that came this night
https://www.mediafire.com/file/pi3wq37lh4514o4/minidump.rar/file

 

[ubuysa]

Both dumps are the same and both are Driver Verifier triggered. They highlight a flaky driver called rsKernelEngine.sys...

0: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffffd0b`db5cce08 fffff806`292db3c1     nt!KeBugCheckEx
01 fffffd0b`db5cce10 fffff806`292f5d81     nt!VerifierBugCheckIfAppropriate+0x14d
02 fffffd0b`db5cceb0 fffff806`292df0a0     nt!ExAllocatePoolSanityChecks+0x115
03 fffffd0b`db5ccef0 fffff806`28de5163     nt!VfHandlePoolAlloc+0x100
04 fffffd0b`db5ccf90 fffff806`292ce0b2     nt!DifExAllocatePoolWithTagWrapper+0x123
05 fffffd0b`db5cd060 fffff809`b0167394     nt!VerifierExAllocatePoolWithTag+0xf2
06 fffffd0b`db5cd0c0 00000000`00000000     rsKernelEngine+0x7394

It's the first driver called in the push-down stack above (which you read from the bottom up)

It was failed by Driver Verifier for making a zero byte memory pool allocation, but if you look at that ksKernelEngine+0x7394 call...

0: kd> .frame /r 6
06 fffffd0b`db5cd0c0 00000000`00000000     rsKernelEngine+0x7394
rax=0000000000000000 rbx=0000000000000000 rcx=00000000000000c4
rdx=0000000000000000 rsi=ffffe30b89975cb8 rdi=fffffd0bdb5cd180
rip=fffff809b0167394 rsp=fffffd0bdb5cd0c0 rbp=ffff8008a58d5210
 r8=0000000000000000  r9=0000000000000000 r10=fffffd0bdb5cce40
r11=0000000000000000 r12=ffff8008bc0fec78 r13=ffff8008a71ccec8
r14=00000000c0000034 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040282
rsKernelEngine+0x7394:
fffff809`b0167394 ??              ???

You can see that there is no instruction at all at offset 0x7394 into the ksKernelEngine function. We can check that the offset is in range for the driver...

0: kd> lmvm rsKernelEngine
Browse full module list
start             end                 module name
fffff809`b0160000 fffff809`b016b000   rsKernelEngine T (no symbols)       
    Loaded symbol image file: rsKernelEngine.sys
    Image path: rsKernelEngine.sys
    Image name: rsKernelEngine.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Mar 25 16:45:54 2021 (605CA222)
    CheckSum:         00010E41
    ImageSize:        0000B000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

And it is in range; the start address is 0xfffff809`b0160000, so 0x7394 bytes further in is address 0xfffff809`b0167394 (which is the address we are pointing at above), and the rsKernelEngine.sys driver end address is 0xfffff809`b016b000. The fault here then lies within the rsKernelEngine.sys driver, or with whatever called the rsKernelEngine.sys driver.

We can also see from the above that the driver is old, dating from March 2021. This version of the driver may not even be fully Windows 11 compatible.

As far as I can tell, the rsKernelEngine.sys driver is a component of the Reason antivirus products by Reason Software Corporation. Either uninstall this antivirus product (which I would recommend) or contact the vendor for an update.

 

[illyaska]

Both dumps are the same and both are Driver Verifier triggered. They highlight a flaky driver called rsKernelEngine.sys...

0: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffffd0b`db5cce08 fffff806`292db3c1     nt!KeBugCheckEx
01 fffffd0b`db5cce10 fffff806`292f5d81     nt!VerifierBugCheckIfAppropriate+0x14d
02 fffffd0b`db5cceb0 fffff806`292df0a0     nt!ExAllocatePoolSanityChecks+0x115
03 fffffd0b`db5ccef0 fffff806`28de5163     nt!VfHandlePoolAlloc+0x100
04 fffffd0b`db5ccf90 fffff806`292ce0b2     nt!DifExAllocatePoolWithTagWrapper+0x123
05 fffffd0b`db5cd060 fffff809`b0167394     nt!VerifierExAllocatePoolWithTag+0xf2
06 fffffd0b`db5cd0c0 00000000`00000000     rsKernelEngine+0x7394

It's the first driver called in the push-down stack above (which you read from the bottom up)

It was failed by Driver Verifier for making a zero byte memory pool allocation, but if you look at that ksKernelEngine+0x7394 call...

0: kd> .frame /r 6
06 fffffd0b`db5cd0c0 00000000`00000000     rsKernelEngine+0x7394
rax=0000000000000000 rbx=0000000000000000 rcx=00000000000000c4
rdx=0000000000000000 rsi=ffffe30b89975cb8 rdi=fffffd0bdb5cd180
rip=fffff809b0167394 rsp=fffffd0bdb5cd0c0 rbp=ffff8008a58d5210
 r8=0000000000000000  r9=0000000000000000 r10=fffffd0bdb5cce40
r11=0000000000000000 r12=ffff8008bc0fec78 r13=ffff8008a71ccec8
r14=00000000c0000034 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040282
rsKernelEngine+0x7394:
fffff809`b0167394 ??              ???

You can see that there is no instruction at all at offset 0x7394 into the ksKernelEngine function. We can check that the offset is in range for the driver...

0: kd> lmvm rsKernelEngine
Browse full module list
start             end                 module name
fffff809`b0160000 fffff809`b016b000   rsKernelEngine T (no symbols)      
    Loaded symbol image file: rsKernelEngine.sys
    Image path: rsKernelEngine.sys
    Image name: rsKernelEngine.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Mar 25 16:45:54 2021 (605CA222)
    CheckSum:         00010E41
    ImageSize:        0000B000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

And it is in range; the start address is 0xfffff809`b0160000, so 0x7394 bytes further in is address 0xfffff809`b0167394 (which is the address we are pointing at above), and the rsKernelEngine.sys driver end address is 0xfffff809`b016b000. The fault here then lies within the rsKernelEngine.sys driver, or with whatever called the rsKernelEngine.sys driver.

We can also see from the above that the driver is old, dating from March 2021. This version of the driver may not even be fully Windows 11 compatible.

As far as I can tell, the rsKernelEngine.sys driver is a component of the Reason antivirus products by Reason Software Corporation. Either uninstall this antivirus product (which I would recommend) or contact the vendor for an update.

Ok I just uninstalled it.
I was seeing someone saying that the Ryzen 5 3600 may have a core problem, so he put down one of his faulty core and thebsod stopped.
Is it my case, because i already have the "amdppm.sys - DRIVER_IRQL_NOT_LESS_OR_EQUAL" ?

 

[ubuysa]

Are you saying that you're still having BSODs after uninstalling the Reason antivirus?

If so, enable Driver Verifier again and see whether it flags other flaky drivers.

Be careful what you read on the Internet. A lot of what you read is just misinformation and ignorance, and what applies to one user doesn't necessarily translate to other users using the same hardware. The only real truth is what we find on your PC.

 

[illyaska]

Are you saying that you're still having BSODs after uninstalling the Reason antivirus?

If so, enable Driver Verifier again and see whether it flags other flaky drivers.

Be careful what you read on the Internet. A lot of what you read is just misinformation and ignorance, and what applies to one user doesn't necessarily translate to other users using the same hardware. The only real truth is what we find on your PC.

Yes, i just got one right now i send you the link :
https://www.mediafire.com/file/4h64eo1az4zs0aa/minidumps%282%29.rar/file
Ok, I understand it's logic.
I wanted to say that these past few days i have easily 5-6 sometimes 7 bsod per day.

 

[Satan-IR]

Ok, here are the 2 crash from driver verifier that came this night
https://www.mediafire.com/file/pi3wq37lh4514o4/minidump.rar/file

Checked the dumps caused by DV they point to a driver called rsKernelEngine. A quick search shows it's part of a 'Reason' amti-virus application/suite? I'd uninstall that and see if BSODs stop.

EDIT: Posted before reading following posts. I see it was already covered and you have BSODs even after uninstalling the Reason app. I'd still run verifier as @ubuysa mentioned and see if anything else pops up.

 

[Satan-IR]

Yes, i just got one right now i send you the link :
https://www.mediafire.com/file/4h64eo1az4zs0aa/minidumps%282%29.rar/file
Ok, I understand it's logic.
I wanted to say that these past few days i have easily 5-6 sometimes 7 bsod per day.

Checked the two latest dumps briefly. The second one points to a lghub_system_t executive. Is that an application for a Logitech hardware?

Do you have anything by Logitech with a software installed? If yes it might be causing issues. Is there any update to it by the vendor?

 

[ubuysa]

Can you please upload the latest dumps?

The driver is a Logitech driver and could well be the problem. I have little confidence in Logitech drivers, IMO they make good hardware and bad drivers. I've see the Logitech Hub driver causing issues before...

 

[illyaska]

Checked the two latest dumps briefly. The second one points to a lghub_system_t executive. Is that an application for a Logitech hardware?

Do you have anything by Logitech with a software installed? If yes it might be causing issues. Is there any update to it by the vendor?

Yes, I have a mouse and a headset from them.
But I already tried one day to remove it all, but the BSODs were still there.

 

[illyaska]

Can you please upload the latest dumps?

The driver is a Logitech driver and could well be the problem. I have little confidence in Logitech drivers, IMO they make good hardware and bad drivers. I've see the Logitech Hub driver causing issues before...

Of course : https://www.mediafire.com/file/mpgj8ennrsqz4cb/md.rar/file
No Driver_verifier bSODs has happened, only irql BSODs.

 

[illyaska]

I fixed it, it was RAM i put just one and at the b1 spot.

 

[ubuysa]

Thanks for letting us know.