Been having trouble with the IRQL_NOT_LESS_OR_EQUAL BSOD for many months now

S

stormflora

Well-known member
Joined
Jun 26, 2019
Posts
54
I found this site through Google after a lot of searching around. Hopefully somebody here will be able to help me out. I'll provide as much information as I can, as well as past details for previous BSODs.

A bit of history. Over the last few months, since around the start of the year, I would constantly get "IRQL_NOT_LESS_OF_EQUAL" at random moments during prolonged gaming sessions (generally an hour or more, but no exact time).

Naturally, whenever I got a BSOD, I would ask around (primarily the Microsoft forums) for help. The BSOD is always the same exact error. Every time someone checked the minidump file, they found out that it had something to do with my video driver. So I tried updating the video driver several times to newer ones that were known to be stable, but to no avail. The consistent BSODs have pretty much caused me to avoid gaming in fear of them. I don't get any BSODs if I don't game.

Recently, about a week or two ago, I got another BSOD after trying to game, and again, I got somebody to look into it. The analyst found that the culprit was ntkrnlmp.exe, "WIN8_DRIVER_FAULT". This actually lightened me up a bit, because for the first time, it wasn't caused by my video driver. Or at least it didn't seem to be. This gave me the impression that I finally managed to update to a video driver that was likely stable.

The analyst told me to try out Driver Verifier, so I did. Ran it for around 39 hours before stopping. Didn't get a single BSOD on all non-Microsoft drivers. This... was actually concerning, because that only increases the ambiguity further. Some other information that is helpful to provide is that I've already done Memtest86 for two passes without any errors, Prime95 for an hour without any issues, and FurMark for an hour without any issues as well. sfc and dism in cmd didn't return any issues.

I updated my BIOS around February/March in an attempt to correct the issue back then, but my motherboard nearly bricked from it and it was just an overall frightening experience. There are new BIOS updates now, but I'd rather not resort to that if I don't have to. I tried updating W10 to Version 1809 a while back, but my computer would experience stuttering every 30 seconds, so I rolled it back to the previous version and it was fixed. I read somewhere that somebody corrected this issue by simply updating Windows, claiming that Windows itself was the culprit, so I'll give it a shot again now.

Anyhow, around 30 minutes ago, I got a BSOD again, same error, but with a different culprit this time: storport.sys. I've included the minidump.

If anyone could give me advice or guide me through with fixing my system and ridding it of this dreaded BSOD, that would be very much appreciated. I just want this issue gone. I'm under the impression that my GPU might be physically dying (because of all the video driver BSODs back then), but I can't be sure. The issue only happens when I'm gaming.
 

Attachments

Code: 
7: kd> .trap ffff808d`5588f550
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=00000000000005fb
rdx=0000000000000004 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8001df90a63 rsp=ffff808d5588f6e0 rbp=0000000000000000
r8=00000000ffffffff  r9=0000000000000000 r10=000045f861dc7606
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up di pl zr na po nc
nt!PpmIdleExecuteTransition+0x653:
fffff800`1df90a63 00a8010f85fa    add     byte ptr [rax-57AF0FFh],ch ds:ffffffff`fa850f01=??

We have an instruction pointer misalignment due to execution occurring during an instruction, specifically an addition instruction during an idle processor transition. This is probably a driver issue causing the misalignment, but without verifier enabled we can't say for sure. Also you noted that you had it enabled for nearly 2 days without any violations.

Two passes of Memtest is not enough. I'd run it for several hours, potentially even overnight.
 
Patrick said:
Code: 
7: kd> .trap ffff808d`5588f550
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=00000000000005fb
rdx=0000000000000004 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8001df90a63 rsp=ffff808d5588f6e0 rbp=0000000000000000
r8=00000000ffffffff  r9=0000000000000000 r10=000045f861dc7606
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up di pl zr na po nc
nt!PpmIdleExecuteTransition+0x653:
fffff800`1df90a63 00a8010f85fa    add     byte ptr [rax-57AF0FFh],ch ds:ffffffff`fa850f01=??

We have an instruction pointer misalignment due to execution occurring during an instruction, specifically an addition instruction during an idle processor transition. This is probably a driver issue causing the misalignment, but without verifier enabled we can't say for sure. Also you noted that you had it enabled for nearly 2 days without any violations.

Two passes of Memtest is not enough. I'd run it for several hours, potentially even overnight.
Click to expand...
Hello Patrick, thank you very much for your support! You definitely seem to know your stuff.

That's a lot of complexity I can't understand, but yes, I ran Driver Verifier for around 39 hours before giving up on it. I even tried a gaming session while it was enabled, for about 5-6 hours, but I didn't get a BSOD. I followed the instructions on I think TenForums, but if you want me to set up different parameters for the test, by all means.

I read on SuperUser that Memtest86 is fine with just a pass of testing because any issues would've been located long before that, so that's why I did two passes just to be sure. In your opinion, how many hours or passes should I do before it's conclusive?

Thank you!
 
Patrick said:
Code: 
7: kd> .trap ffff808d`5588f550
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=00000000000005fb
rdx=0000000000000004 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8001df90a63 rsp=ffff808d5588f6e0 rbp=0000000000000000
r8=00000000ffffffff  r9=0000000000000000 r10=000045f861dc7606
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up di pl zr na po nc
nt!PpmIdleExecuteTransition+0x653:
fffff800`1df90a63 00a8010f85fa    add     byte ptr [rax-57AF0FFh],ch ds:ffffffff`fa850f01=??

We have an instruction pointer misalignment due to execution occurring during an instruction, specifically an addition instruction during an idle processor transition. This is probably a driver issue causing the misalignment, but without verifier enabled we can't say for sure. Also you noted that you had it enabled for nearly 2 days without any violations.

Two passes of Memtest is not enough. I'd run it for several hours, potentially even overnight.
Click to expand...
This is nothing. Look at the second dump where the frame of the trap indicates the function ... KiPageFault
That makes me wonder. The failure occurred due to failure?
Code: 
TRAP_FRAME:  ffff94062e187870 -- (.trap 0xffff94062e187870)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000048
rdx=0000000000002c80 rsi=0000000000000000 rdi=0000000000000000
rip=fffff806408663dc rsp=ffff94062e187a00 rbp=ffff94062e187a80
 r8=00000000401b4fc0  r9=0000000000000000 r10=0000000000000000
r11=0000000000000088 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up di pl zr na po nc
nt!KiPageFault+0x59c:
fffff806`408663dc 488b4db8        mov     rcx,qword ptr [rbp-48h] ss:ffff9406`2e187a38=0000000000000001
Resetting default scope
 
MrPepka said:
This is nothing. Look at the second dump where the frame of the trap indicates the function ... KiPageFault
That makes me wonder. The failure occurred due to failure?
Click to expand...
Hi, I'm not really sure what that means, but do you want me to try to get another BSOD with Driver Verifier constantly enabled, to further diagnose the issue?
If so, what settings for Driver Verifier would you like me to enable?
 
Driver Verifier let you work on standard settings, I do not see the need to enable these additional ones
 
These are the recommended options. Most often, however, it is recommended to create the same standard settings at which the driver should not be supposed to crash a blue screen
 
MrPepka said:
These are the recommended options. Most often, however, it is recommended to create the same standard settings at which the driver should not be supposed to crash a blue screen
Click to expand...
Oh, so should I be doing "Create standard settings" instead? Or is that no longer really necessary in my case, since I've already done a 39-hour test?
 
Last edited:
You can do that:
1. Run Driver Verifier
2. Select "Create custom settings (for code developers)"
3. Select all standard settings and two additional settings (Force pending I/O requests and IRP logging)
4. Select "Select driver names from a list"
5. Select all drivers except Microsoft drivers
6. Reboot computer
 
MrPepka said:
You can do that:
1. Run Driver Verifier
2. Select "Create custom settings (for code developers)"
3. Select all standard settings and two additional settings (Force pending I/O requests and IRP logging)
4. Select "Select driver names from a list"
5. Select all drivers except Microsoft drivers
6. Reboot computer
Click to expand...
Okay, I will do that now, and just leave Driver Verifier persistently running nonstop until the next BSOD occurs. Should I do this first, or should I do the Memtest86 tonight as Patrick instructed first?

Also I read before that the various "dump_***.sys" drivers are considered Microsoft's, but don't have Provider information stated. Do you want me to select those drivers as well? These are the ones visible for me:
  • dump_dumpfve.sys
  • dump_dumpstorport.sys
  • dump_stornvme.sys
 
MrPepka said:
These are so-called backup copies of drivers. There is no need to mark them
Click to expand...
Okay then. I will re-enable Driver Verifier now with your settings and see how things turn out. I'll leave it enabled indefinitely, and retry Memtest86 tonight. I will be back with the results tomorrow, or if I get a BSOD before then. Thank you
 
Patrick said:
We have an instruction pointer misalignment due to execution occurring during an instruction, specifically an addition instruction during an idle processor transition. This is probably a driver issue causing the misalignment, but without verifier enabled we can't say for sure. Also you noted that you had it enabled for nearly 2 days without any violations.

Two passes of Memtest is not enough. I'd run it for several hours, potentially even overnight.
Click to expand...
Hello Patrick, it's me again. As you instructed, I ran Memtest86 again overnight. I left it to run on default settings, and I let it go to its full completion of four passes, which took just over 11 hours and 20 minutes. Not a single error.

On a side note, some other things I did in the meanwhile was update Windows 10 to Build 1903 and also making sure to update it as far as possible, and I also re-enabled Driver Verifier with MrPepka's settings in the meanwhile (although that is causing my PC to be noticeably sluggish).

What would you say are the next steps? Should I attempt to use my computer (particularly, game) until a BSOD occurs and gets hooked by Driver Verifier, or...? I'd rather not keep Driver Verifier enabled for too long, since my PC is somewhat lagging.

Thank you
 
Try disable Driver Verifier and enable kernel debugger (Run msconfig, select "Boot" page, select option "Advanced options", and check option "Debug". Accept changes and reboot computer.)
 
MrPepka said:
Try disable Driver Verifier and enable kernel debugger (Run msconfig, select "Boot" page, select option "Advanced options", and check option "Debug". Accept changes and reboot computer.)
Click to expand...
What exactly does that do? Does it provide detailed BSODs similar to Driver Verifier, but without the lag?

Also, when I click "Debug", it auto-selects a setting called 'Debug port' that's set to 1394 by default, and an unselected 'Channel' option. Should I leave those as-is?
 
With the kernel debugger enabled, the stack appears to be more detailed. As for the settings, just leave this field "Debug", leave the rest
 
MrPepka said:
With the kernel debugger enabled, the stack appears to be more detailed. As for the settings, just leave this field "Debug", leave the rest
Click to expand...
Sorry, I don't understand. I mean like this is what shows by default:

d0e97c3a875a632bacd522b4f914d8e6.png


Also, is it safe to use? Some Google searches are claiming that it's unsafe. Can I use my computer normally while it's enabled?
 
The computer will not blow you up, although it is a good idea to make a system restore point before doing so
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top