IRQL_NOT_LESS_OR_EQUAL ("Blue Screen of Death" issue) - Windows 8.1 x64

domejandro

New member
Joined
Mar 8, 2015
Posts
1
Hello, my name is Alejandro.


Lately I have been having issues with my computer in which the screen turns blue and shows the error message "IRQL_NOT_LESS_OR_EQUAL", effectively restarting my computer.


I have no technical ability, and am painfully unaware as of how I would begin to fix this.


I of course searched on Google for various fixes, but I either was unable to understand how to follow the instructions, and/or the fixes would not work. Below is a copy paste of information that I believe the Posting Instructions ask for, but if I missed anything major, please correct me.


Operating System: Windows 8.1 64-bit (6.3, Build 9600) (9600.winblue_r7.150109-2022)
Language: English (Regional Setting: English)
BIOS: P1.90
Processor: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (8 CPUs), ~3.6GHz
Card name: NVIDIA GeForce GTX 750


The system is about four months old, and I have yet to re-install the Operating System as I am hoping that is unnecessary.


View attachment 11075


Thank you!
 
re: IRQL_NOT_LESS_OR_EQUAL ("Blue Screen of Death" issue) - Windows 8.1 x64

Code:
3: kd> .bugcheck
Bugcheck code 000000D1
Arguments 00000000`000000b8 00000000`00000002 00000000`00000000 fffff801`e62df70a

Code:
3: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffd000`b6bea248 fffff802`d576c4e9 : 00000000`0000000a 00000000`000000b8 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
ffffd000`b6bea250 fffff802`d576ad3a : 00000000`00000000 ffffe001`53a928a0 00000000`c0000000 fffff802`d570c181 : nt!KiBugCheckDispatch+0x69
ffffd000`b6bea390 fffff801`e62df70a : 00000000`ffffffff ffffd000`b6bea5b1 ffffe001`52ee7b60 fffff801`e8ec7d10 : nt!KiPageFault+0x23a (TrapFrame @ ffffd000`b6bea390)
ffffd000`b6bea520 fffff801`e62ec364 : ffffe001`53a92a40 ffffe001`00000000 ffffd000`b6bea7d0 ffffd000`b6bea681 : Wdf01000!FxRequest::CompleteInternal+0x4a
ffffd000`b6bea5e0 fffff801`e8ecaf16 : ffffe001`53a92a40 ffffd000`b6be0000 00000000`00000004 ffffe001`53a928a0 : Wdf01000!imp_WdfRequestComplete+0x8c
ffffd000`b6bea650 fffff801`e8ecbe8c : ffffe001`53a92a40 00000000`00000001 ffffe001`53a92ac0 ffffd000`b6bea7d0 : USBXHCI!Bulk_Transfer_CompleteCancelable+0x15a
ffffd000`b6bea6b0 fffff801`e8eb902b : 00000000`00000780 ffffe001`527a5930 00000000`00000000 00000000`00000001 : USBXHCI!Bulk_ProcessTransferEventWithED1+0x3a8
ffffd000`b6bea760 fffff801`e6377c81 : 00000000`00000002 00000000`00000002 00001ffe`ad85a8b8 00000000`00400a02 : USBXHCI!Interrupter_WdfEvtInterruptDpc+0x427
ffffd000`b6bea860 fffff802`d56c4d50 : ffffd000`b6bc2f00 ffffd000`b6beab20 ffffe001`527a5740 ffffd000`b6bc55c0 : Wdf01000!FxInterrupt::DpcHandler+0xc1
ffffd000`b6bea890 fffff802`d56c4007 : ffffe001`55f2e080 ffffd000`b6beab50 ffffd000`b6bc0180 00000000`00000001 : nt!KiExecuteAllDpcs+0x1b0
ffffd000`b6bea9e0 fffff802`d57644ea : ffffd000`b6bc0180 ffffd000`b6bc0180 ffffd000`b6bcc3c0 ffffe001`50f85080 : nt!KiRetireDpcList+0xd7
ffffd000`b6beac60 00000000`00000000 : ffffd000`b6beb000 ffffd000`b6be5000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a

So processor #3 is coming out of idle, ultimately to retire/execute DPCs. We do so via an interrupt that goes through the Kernel-Mode Driver Framework and the USB XHCI driver. We go off the rails completing the request.

Code:
3: kd> .trap ffffd000`b6bea390
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff801e62df70a rsp=ffffd000b6bea520 rbp=0000000000000000
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000038
r11=ffffd000b6bea5d0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
Wdf01000!FxRequest::CompleteInternal+0x4a:
fffff801`e62df70a 488b91b8000000  mov     rdx,qword ptr [rcx+0B8h] ds:00000000`000000b8=????????????????

There's a lot of null registers due to being volatile, so we can't check their contents as they're trashed across calls. FWIW though, it was setting rdx to the value stored at address rcx+0B8.

I suspect Norton is behind this, so please enable verifier so I can see:

Driver Verifier:

What is Driver Verifier?

Driver Verifier monitors Windows kernel-mode drivers, graphics drivers, and even 3rd party drivers to detect illegal function calls or actions that might corrupt the system. Driver Verifier can subject the Windows drivers to a variety of stresses and tests to find improper behavior.

Essentially, if there's a 3rd party driver believed to be causing the issues at hand, enabling Driver Verifier will help us see which specific driver is causing the problem.

Before enabling Driver Verifier, it is recommended to create a System Restore Point:

Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8/8.1 - Restore Point - Create in Windows 8

How to enable Driver Verifier:

Start > type "verifier" without the quotes > Select the following options -

1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (only on Windows 7 & 8/8.1)
- DDI compliance checking (only on Windows 8/8.1)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.

Important information regarding Driver Verifier:

- Perhaps the most important which I will now clarify as this has been misunderstood often, enabling Driver Verifier by itself is not! a solution, but instead a diagnostic utility. It will tell us if a driver is causing your issues, but again it will not outright solve your issues.

- If Driver Verifier finds a violation, the system will BSOD. To expand on this a bit more for the interested, specifically what Driver Verifier actually does is it looks for any driver making illegal function calls, causing memory leaks, etc. When and/if this happens, system corruption occurs if allowed to continue. When Driver Verifier is enabled per my instructions above, it is monitoring all 3rd party drivers (as we have it set that way) and when it catches a driver attempting to do this, it will quickly flag that driver as being a troublemaker, and bring down the system safely before any corruption can occur.

- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will detect it in violation almost straight away, and as stated above, that will cause / force a BSOD.

If this happens, do not panic, do the following:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > Search > type "cmd" without the quotes.

- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.

- Restart and boot into normal Windows.

If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > type "system restore" without the quotes.

- Choose the restore point you created earlier.

-- Note that Safe Mode for Windows 8/8.1 is a bit different, and you may need to try different methods: 5 Ways to Boot into Safe Mode in Windows 8 & Windows 8.1

How long should I keep Driver Verifier enabled for?

I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier. I will usually say whether or not I'd like for you to keep it enabled any longer.

My system BSOD'd with Driver Verifier enabled, where can I find the crash dumps?

- If you have the system set to generate Small Memory Dumps, they will be located in %systemroot%\Minidump.

- If you have the system set to generate Kernel Memory Dumps, it will be located in %systemroot% and labeled MEMORY.DMP.

Any other questions can most likely be answered by this article:

Using Driver Verifier to identify issues with Windows drivers for advanced users
 

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

Back
Top