You are running in the idle thread (hence CID 0.0, not to mention the “Image” as being “Idle”) so this is either an interrupt or a DPC. A double fault would show up as an unexpected trap - AND the double fault stack address is the TOP of the stack (stacks grow down) so “address of double fault + offset” doesn’t have anything to do with the double fault stack - it was just the closest address the debugger could find. My guess is that the debugger can’t find the HAL symbols, or the symbols of one of the boot drivers.
In fact, when I look at this crash it suggests to me you’ve overrun the buffer - the faulting address is on a page boundary. To debug this *I* would do a “kv”, set the trap from this ".trap
" and then look at the register contents at that point. But just from what you provided, the faulting address (ff9c8000) is clearly a page boundary. The specific call frame for memset (the exact type of function that overruns pages):
80550ef0 804db915 ffb16930 806f2df8 0004ec81 nt!memset+0x41 (FPO: [3,0,0])
Memset takes three arguments: destination address, fill, and length. The FPO seems to confirm this (# args = 3, no locals, no preserved registers). The first value (ffb16930) doesn't fit well with the faulting address (ff9c8000) which makes me a bit uncomfortable. The second parameter (806f2df8) is an odd fill value, but who am I to criticize? The third parameter (4ec81) seems to be a tad bit on the large size (~320k) but within the realm of possibility.
So sit down and figure out where this address came from. Check to see if the page before it is valid ("!pte ff9c7fff" will do the trick). If it is, figure out why you are going beyond the end of the buffer - like figure out where the buffer came from in the first place.
Odds are, you'll need to resolve your symbol problem first.
So, right now, what you've got there is a bit of a mess. It almost certainly is caused by a page overrun (the "starting address on a page boundary from a function that performs operations on a range of addresses" is a dead giveaway) but from this I couldn't tell you why.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Xu Ge
Sent: Friday, May 27, 2005 2:28 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] BugCheck : IRQL_NOT_LESS_OR_EQUAL
here is the command's output:
it seems the stack not overflowed,
so how can i do?
kd> !thread
THREAD 80559c20 Cid 0000.0000 Teb: 00000000 Win32Thread: 00000000 RUNNING
on processor 0
Not impersonating
Owning Process 80559e80 Image: Idle
Wait Start TickCount 0 Ticks: 323074 (0:00:53:55.392)
Context Switch Count 294571
UserTime 00:00:00.0000
KernelTime 00:48:35.0031
Start Address 0x00000000
Stack Init 80551480 Current 805511cc Base 80551480 Limit 8054e480 Call 0
Priority 16 BasePriority 0 PriorityDecrement 0 DecrementCount 0
ChildEBP RetAddr Args to Child
80550e08 804db0f6 badb0d00 00000001 00000017 nt!KiTrap0E+0x233 (FPO: [0,0]
TrapFrame @ 80550e08)
80550ef0 804db915 ffb16930 806f2df8 0004ec81 nt!memset+0x41 (FPO: [3,0,0])
80550ef0 ff28168c ffb16930 806f2df8 0004ec81 nt!KiInterruptDispatch+0x3d
(FPO: [0,2] TrapFrame @ 80550f0c)
WARNING: Frame IP not in any known module. Following frames may be wrong.
80550f7c 80550f90 f8cc1b4f ff7c1004 ff7c1000 0xff28168c
f91b30ad 8a040000 8b0f74d8 57570c46 5074c083 nt!KiDoubleFaultStack+0x2b10
012886f6 00000000 00000000 00000000 00000000 0x8a040000
kd> kb 100
ChildEBP RetAddr Args to Child
80550e08 804db0f6 badb0d00 00000001 00000017 nt!KiTrap0E+0x233
80550ef0 804db915 ffb16930 806f2df8 0004ec81 nt!memset+0x41
80550ef0 ff28168c ffb16930 806f2df8 0004ec81 nt!KiInterruptDispatch+0x3d
WARNING: Frame IP not in any known module. Following frames may be wrong.
80550f7c 80550f90 f8cc1b4f ff7c1004 ff7c1000 0xff28168c
f91b30ad 8a040000 8b0f74d8 57570c46 5074c083 nt!KiDoubleFaultStack+0x2b10
012886f6 00000000 00000000 00000000 00000000 0x8a040000
"Zhang, Raymond" д????Ϣ????:xxxxx@windbg...
Try to get control with kernel debugger and check whether it was stack
overflow. Refer help from WinDbg.
[From WinDbg help]
Double Fault is when an exception occurs while trying to call the handler
for a prior exception. Normally, the two exceptions can be handled serially.
However, there are several exceptions that cannot be handled serially, and
in this situation the processor signals a double fault. There are two common
causes of a double fault:
A kernel stack overflow. This occurs when a guard page is hit, and then the
kernel tries to push a trap frame. Since there is no stack left, a stack
overflow results, causing the double fault. If you suspect this has
occurred, use !thread to determine the stack limits, and then use kb
(Display Stack Backtrace) with a large parameter (for example, kb 100) to
display the full stack.
A hardware problem.
Best Regards
Raymond Zhang
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Xu Ge
Sent: 2005??5??27?? 12:55
To: Kernel Debugging Interest List
Subject: [windbg] BugCheck : IRQL_NOT_LESS_OR_EQUAL
Hi all,
We are having a machine (xp, sp2) crash with IRQL_NOT_LESS_OR_EQUAL.
I have been trying to analyze memory dump for couple of hours and can't
pin-point who caused it.
Any hint will be greatly appreciated.
=========================================================================
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: ff9c8000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 804db0f6, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: ff9c8000 Nonpaged pool expansion
CURRENT_IRQL: 2
FAULTING_IP:
nt!memset+41
804db0f6 f3ab rep stosd
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 804db915 to 804db0f6
STACK_TEXT:
80550ef0 804db915 ffb16930 806f2df8 0004ec81 nt!memset+0x41
80550ef0 ff28168c ffb16930 806f2df8 0004ec81 nt!KiInterruptDispatch+0x3d
WARNING: Frame IP not in any known module. Following frames may be wrong.
80550f7c 80550f90 f8cc1b4f ff7c1004 ff7c1000 0xff28168c
f91b30ad 8a040000 8b0f74d8 57570c46 5074c083 nt!KiDoubleFaultStack+0x2b10
012886f6 00000000 00000000 00000000 00000000 0x8a040000
FOLLOWUP_IP:
nt!KiTrap0E+233
804e287f f7457000000200 test dword ptr [ebp+0x70],0x20000
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!KiTrap0E+233
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 42250ff9
STACK_COMMAND: .trap ffffffff80550e08 ; kb
FAILURE_BUCKET_ID: 0xA_W_nt!KiTrap0E+233
BUCKET_ID: 0xA_W_nt!KiTrap0E+233
Followup: MachineOwner
---------
kd> kb
ChildEBP RetAddr Args to Child
80550e08 804db0f6 badb0d00 00000001 00000017 nt!KiTrap0E+0x233
80550ef0 804db915 ffb16930 806f2df8 0004ec81 nt!memset+0x41
80550ef0 ff28168c ffb16930 806f2df8 0004ec81 nt!KiInterruptDispatch+0x3d
WARNING: Frame IP not in any known module. Following frames may be wrong.
80550f7c 80550f90 f8cc1b4f ff7c1004 ff7c1000 0xff28168c
f91b30ad 8a040000 8b0f74d8 57570c46 5074c083 nt!KiDoubleFaultStack+0x2b10
012886f6 00000000 00000000 00000000 00000000 0x8a040000
---
You are currently subscribed to windbg as: xxxxx@intel.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
---
You are currently subscribed to windbg as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com