How to slove these bugcheck code??
From: paullee (paullee_at_iei.com.tw)
Date: 11/03/04
- Next message: Doron Holan [MS]: "Re: How to use 2 USB mice independently and simultaneously?"
- Previous message: Haikun: "Re: HCT12 driver verifier test question of smartcard reader driver"
- Next in thread: Calvin Guan: "Re: How to slove these bugcheck code??"
- Reply: Calvin Guan: "Re: How to slove these bugcheck code??"
- Messages sorted by: [ date ] [ thread ]
Date: 2 Nov 2004 19:44:03 -0800
Hi All
I got these bugcheck code when I develop my own dma driver.
can anyone give me any comment or suggest??
thanks a lot ^^
===================================================first
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 33005158, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f87f1ea7, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: 33005158
CURRENT_IRQL: 2
FAULTING_IP:
usbuhci!UhciProcessDoneAsyncTd+57
f87f1ea7 ?? ???
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD1
LAST_CONTROL_TRANSFER: from 805344b1 to 804f6471
STACK_TEXT:
8053eef8 805344b1 0000000a 33005158 00000002
nt!MiWaitForInPageComplete+0x275
8053ef14 8053ef18 8053ef18 021db1e8 00000000
nt!MmProtectMdlSystemAddress+0x267
00000000 00000000 00000000 00000000 00000000
nt!RtlIpv4StringToAddressExW+0xe1
STACK_COMMAND: .bugcheck ; kb
FOLLOWUP_IP:
usbuhci!UhciProcessDoneAsyncTd+57
f87f1ea7 ?? ???
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: usbuhci!UhciProcessDoneAsyncTd+57
MODULE_NAME: usbuhci
IMAGE_NAME: usbuhci.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3f04cfa0
BUCKET_ID: 0xD1_usbuhci!UhciProcessDoneAsyncTd+57
Followup: MachineOwner
===================================================Second
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: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 80517134, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: 00000004
CURRENT_IRQL: 2
FAULTING_IP:
nt!CcCanIWrite+d3
80517134 8b4804 mov ecx,[eax+0x4]
CUSTOMER_CRASH_COUNT: 4
DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 805344b1 to 804f6471
STACK_TEXT:
f0c82778 805344b1 0000000a 00000004 00000002
nt!MiWaitForInPageComplete+0x275
f0c82794 ffffffff ffffffff ffffffff ffffffff
nt!MmProtectMdlSystemAddress+0x267
ffffffff 00000000 00000000 00000000 00000000 0xffffffff
FOLLOWUP_IP:
nt!CcCanIWrite+d3
80517134 8b4804 mov ecx,[eax+0x4]
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!CcCanIWrite+d3
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 3ea80977
STACK_COMMAND: kb
BUCKET_ID: 0xA_nt!CcCanIWrite+d3
Followup: MachineOwner
---------
===================================================Third
THREAD_STUCK_IN_DEVICE_DRIVER (ea)
The device driver is spinning in an infinite loop, most likely waiting
for
hardware to become idle. This usually indicates problem with the
hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects
a
timeout condition then DbgBreakPoint() will be called instead of
KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to
the
debugger. This way we can identify an offending thread, set
breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return
bugcheck
information in this case. The arguments are already printed out to the
kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning
thread is
interrupted by hardware interrupt and ISR or DPC routine is running at
the time
of the bugcheck (this is because the timeout's work item can be
delivered and
handled on the second CPU and the same time). If this is the case you
will have
to look deeper at the offending thread's stack (e.g. using dds) to
determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: 824fd6a0, Pointer to a stuck thread object. Do .thread then kb
on it to find
the hung location.
Arg2: 82675ce0, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 8266bd48, Pointer to offending driver name.
Arg4: 00000001, Number of times this error occurred. If a debugger is
attached,
this error is not always fatal -- see DESCRIPTION below. On the
blue screen, this will always equal 1.
Debugging Details:
------------------
FAULTING_THREAD: 824fd6a0
DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT
CUSTOMER_CRASH_COUNT: 2
BUGCHECK_STR: 0xEA
LAST_CONTROL_TRANSFER: from 00000000 to bf9f4aff
SYMBOL_ON_RAW_STACK: 1
STACK_TEXT:
04000000 00000000 00000000 00000000 00000000
ati2dvag!_NULL_IMPORT_DESCRIPTOR <PERF> (ati2dvag+0x3daff)
STACK_COMMAND: dds @$csp ; kb
FOLLOWUP_IP:
ati2dvag!MapPageTablesClientCroaked+5a
bf9dabfa ?? ???
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: ati2dvag!MapPageTablesClientCroaked+5a
MODULE_NAME: ati2dvag
IMAGE_NAME: ati2dvag.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 3f39a3c6
BUCKET_ID: 0xEA_IMAGE_ati2dvag.dll_DATE_8_13_2003
Followup: MachineOwner
===================================================four
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain
bad or it
is pointing at freed memory.
Arguments:
Arg1: f000eefb, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 804ec8d5, If non-zero, the instruction address which referenced
the bad memory
address.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
Could not read faulting driver name
READ_ADDRESS: f000eefb
FAULTING_IP:
nt!IoAllocateMdl+c
804ec8d5 ?? ???
MM_INTERNAL_CODE: 0
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x50
LAST_CONTROL_TRANSFER: from 80515658 to 804f6471
STACK_TEXT:
f7c25868 80515658 00000050 f000eefb 00000000
nt!MiWaitForInPageComplete+0x275
f7c258b8 805342b8 00000000 f000eefb 00000000
nt!CcExtendVacbArray+0x430
f7c258d0 f7c258ec 805342b8 00000000 0000002c
nt!MmProtectMdlSystemAddress+0x6e
WARNING: Frame IP not in any known module. Following frames may be
wrong.
e201e700 00000000 00000000 00000000 00000000 0xf7c258ec
FOLLOWUP_IP:
nt!IoAllocateMdl+c
804ec8d5 ?? ???
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!IoAllocateMdl+c
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 3ea80977
STACK_COMMAND: kb
BUCKET_ID: 0x50_nt!IoAllocateMdl+c
Followup: MachineOwner
---------
- Next message: Doron Holan [MS]: "Re: How to use 2 USB mice independently and simultaneously?"
- Previous message: Haikun: "Re: HCT12 driver verifier test question of smartcard reader driver"
- Next in thread: Calvin Guan: "Re: How to slove these bugcheck code??"
- Reply: Calvin Guan: "Re: How to slove these bugcheck code??"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
