Re: mini dump
- From: "NETCRAMMER" <netcrammer@xxxxxxxxx>
- Date: Mon, 29 Aug 2005 20:21:53 -0400
|
some more info: !analyze -v
WHAT DRIVERS SHOULD I USE THEN??
CONFUSED.
TIA!!
******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea) 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: 859f6020, Pointer to a stuck thread object. Do ..thread then kb on it to find the hung location. Arg2: 8661f900, Pointer to a DEFERRED_WATCHDOG object. Arg3: f7a17cb4, Pointer to offending driver name. Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes). Debugging Details: ------------------ ATI Rev3 buffer FAULTING_THREAD: 859f6020 DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT CUSTOMER_CRASH_COUNT: 2 BUGCHECK_STR: 0xEA LAST_CONTROL_TRANSFER: from 806d6dad to 80540a7f STACK_TEXT: afa22fd4 806d6dad badb0d00 00000808 e4000000 nt!RtlIpv6StringToAddressW+0x1bc afa23060 bf059d37 afa23080 00000000 e1e00000 hal!RegNames+0x29 afa23094 bf07360c e1b33080 e1e00000 e1e001c0 ati2cqag!MSF::initialise+0x77 afa2309c e1e00000 e1e001c0 022231fa 00000000 ati2cqag!aPM4_Microcode_R400+0x3744 WARNING: Frame IP not in any known module. Following frames may be wrong. afa230a0 e1e001c0 022231fa 00000000 00000000 0xe1e00000 afa230a4 022231fa 00000000 00000000 00000000 0xe1e001c0 afa230a8 00000000 00000000 00000000 00000000 0x22231fa
STACK_COMMAND: .thread ffffffff859f6020 ; kb FOLLOWUP_IP: ati2cqag!MSF::initialise+77 bf059d37 ?? ??? SYMBOL_STACK_INDEX: 2 FOLLOWUP_NAME: MachineOwner SYMBOL_NAME: ati2cqag!MSF::initialise+77 MODULE_NAME: ati2cqag IMAGE_NAME: ati2cqag.dll DEBUG_FLR_IMAGE_TIMESTAMP: 42f1772f FAILURE_BUCKET_ID: 0xEA_IMAGE_ati2cqag.dll_DATE_8_3_2005 BUCKET_ID: 0xEA_IMAGE_ati2cqag.dll_DATE_8_3_2005 Followup: MachineOwner ---------
|
- References:
- mini dump
- From: NETCRAMMER
- mini dump
- Prev by Date: Re: xp doesn't recognize blank cd
- Next by Date: Re: Monitor shutdown and freezes on PC
- Previous by thread: mini dump
- Next by thread: Standard Modem not listed
- Index(es):
Relevant Pages
|
