IRQL Not Less Or Equal

Soldato
Joined
23 Jul 2007
Posts
2,823
Location
Worcester
Hey,
My system has been running fine the past week or two, and then i decided to install 2 hard drives over from my old pc, as i needed some space. I've put them into the hotswap bays of my Corsair 800D, and everything was going ok until i keep getting an IRQL Not Less or Equal error!
Now i'm not sure if it's related or not, but this is the only way i've modified the system and then the crashes appeared, so i'm going to assume it has something to do with the drives!
From a quick google, IRQL seems to suggest that it's driver related (IRL is apparently hardware?), so this makes me assume the drivers that windows chose to install for the hard drives is somehow killing my system. I've only had the crashes while gaming, but then i've only been gaming today so i cannot tell if it happens during idle etc.

I'm just wondering if anyone has any suggestions? Could it be something else i'm missing?

Thanks,
Matt
 
Put simply an IRL is an Interrupt Request Level, and Windows has a complicated array of levels that interrupts can work on. When something craps out, you get a blue screen.

What motherboard have you got, and have you tried updating your chipset drivers?
 
I'm on:

Intel Core i7 950 3.06GHz (Bloomfield) (Socket LGA1366) - Retail
Asus P6X58D-E Intel X58 (Socket 1366) DDR3 Motherboard
Patriot Viper 6GB (3x2GB) DDR3 PC3-12800C8 1600MHz Low Latency Triple Channel (PVT36G1600LLK)

And i think i've updated the drivers, but will try again now! I'm also downloading the windows debugging tools which look awesome, and should tell me exactly what is going on looking at:
http://forums.pcper.com/showthread.php?t=447620&highlight=mini+dump

i'll let you know how i get on!
 
If you've only had the system a couple of weeks, it might not be the hard disks that are causing it... when my last system kept blue-screening with that error, it turned out to be a faulty memory module. Worked out which one by trying each alone in turn, and RMA'd it.

FWIW, my problem only surfaced while I was gaming too.
 
Yea, i suppose it likely is a coincidence that i changed the system today! Waiting for a symbols package to download then i can inspect the dumpfiles, i'll carry on trying to find the problem, perhaps some gaming (hopefully), and then i'll run a memtest overnight!
 
here's what i got from the debug, can anyone make any sense from it?

i can see that there was a memory fault, but then it also says vista driver fault (im on win7, but obviously win7 is built up from vista)

Code:
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16617.amd64fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0xfffff800`02c0a000 PsLoadedModuleList = 0xfffff800`02e47e50
Debug session time: Fri Oct 22 16:30:13.716 2010 (UTC + 1:00)
System Uptime: 0 days 0:25:34.653
Loading Kernel Symbols
...............................................................
................................................................
.............................
Loading User Symbols

Loading unloaded module list
....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {0, d, 0, fffff80002c84291}

Probably caused by : ntkrnlmp.exe ( nt!KiTimerWaitTest+171 )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000000, memory referenced
Arg2: 000000000000000d, IRQL
Arg3: 0000000000000000, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002c84291, address which referenced memory

Debugging Details:
------------------


READ_ADDRESS:  0000000000000000 

CURRENT_IRQL:  d

FAULTING_IP: 
nt!KiTimerWaitTest+171
fffff800`02c84291 488b6d00        mov     rbp,qword ptr [rbp]

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  System

TRAP_FRAME:  fffff8800311b940 -- (.trap 0xfffff8800311b940)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000008 rbx=0000000000000000 rcx=0000000000000011
rdx=0000000000005020 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002c84291 rsp=fffff8800311bad0 rbp=0000000000000000
 r8=0000000000016306  r9=0000000000000000 r10=0000000000000f42
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe cy
nt!KiTimerWaitTest+0x171:
fffff800`02c84291 488b6d00        mov     rbp,qword ptr [rbp] ss:0018:00000000`00000000=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002c79ca9 to fffff80002c7a740

STACK_TEXT:  
fffff880`0311b7f8 fffff800`02c79ca9 : 00000000`0000000a 00000000`00000000 00000000`0000000d 00000000`00000000 : nt!KeBugCheckEx
fffff880`0311b800 fffff800`02c78920 : fffff880`009ec180 fffff880`009ec180 fffffa80`07dbe200 fffffa80`07dfa200 : nt!KiBugCheckDispatch+0x69
fffff880`0311b940 fffff800`02c84291 : fffff980`2aec0000 00000000`000006f8 00000000`00002710 fffffa80`07dfa200 : nt!KiPageFault+0x260
fffff880`0311bad0 00000000`00000000 : 00000001`627ae0e5 00000000`00000f42 00000000`00000000 00000000`00005020 : nt!KiTimerWaitTest+0x171


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!KiTimerWaitTest+171
fffff800`02c84291 488b6d00        mov     rbp,qword ptr [rbp]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  nt!KiTimerWaitTest+171

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4c1c44a9

FAILURE_BUCKET_ID:  X64_0xA_nt!KiTimerWaitTest+171

BUCKET_ID:  X64_0xA_nt!KiTimerWaitTest+171

Followup: MachineOwner
---------

1: kd> .trap 0xfffff8800311b940
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000008 rbx=0000000000000000 rcx=0000000000000011
rdx=0000000000005020 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002c84291 rsp=fffff8800311bad0 rbp=0000000000000000
 r8=0000000000016306  r9=0000000000000000 r10=0000000000000f42
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe cy
nt!KiTimerWaitTest+0x171:
fffff800`02c84291 488b6d00        mov     rbp,qword ptr [rbp] ss:0018:00000000`00000000=????????????????
 
How often does it blue screen, if its every 3-4 weeks it could take a while to track down.
If it's every few hours it will be much faster.
Run diagnostics on the drives, and see if they are ok.
Even if thats ok, try removing one drive and running til you identify the problem drive
 
Just tried it without the drives, and it still does it now!
Seems to be every hour or so when i was playing a game, so i'll definitely do a memtest tonight!
Can't really make out much from that debug, unfortunately the example in the thread i linked to was a much nicer debug log i'd of liked, saying exactly what it was, where as mine is far from it lol.

the only thing i can't seem to figure out is why it's only just started now, after having to install drivers for the harddrives. if it was down to the memory surely it would have done it when i was playing games before or putting the pc under load? it doesn't quite make sense!
 
Last edited:
Back
Top Bottom