No clue what's wrong, no stack, no module info

WINDBG
1

Hi,
I am new to dump analysis. I have got to debug a situation where the system
crashed( due to uplugging of a usb dongle).
!analyze -v didn't give much useful info.

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

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 801dc000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

*************************************************************************
PEB is paged out (Peb.Ldr = 7ffdf00c). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffdf00c). Type ".hh dbgerr001" for details

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to
set symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: 82a3e000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4b88cacf

BUGCHECK_STR: 0x7f_8

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 00000000 to 82a8362c

STACK_TEXT:
00000000 00000000 00000000 00000000 00000000 nt!Kei386EoiHelper+0x17d4

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!Kei386EoiHelper+17d4
82a8362c ebee jmp nt!Kei386EoiHelper+0x17c4 (82a8361c)

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!Kei386EoiHelper+17d4

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntkrpamp.exe

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

0: kd> k
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be
wrong.
00000000 00000000 nt!Kei386EoiHelper+0x17d4

Please suggest how to start debugging it.

-Madhusudhana

2

it gave the answer by saying
*WRONG_SYMBOLS*

Whats the symbol server path you have used

send the output of
.sympath

On Mon, Apr 26, 2010 at 8:57 AM, Madhusudan Narayan <
xxxxx@gmail.com> wrote:

Hi,
I am new to dump analysis. I have got to debug a situation where the system
crashed( due to uplugging of a usb dongle).
!analyze -v didn’t give much useful info.

0: kd> !analyze -v

*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*

*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 801dc000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

*************************************************************************
PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details
PEB is paged out (Peb.Ldr = 7ffdf00c). Type “.hh dbgerr001” for details

ADDITIONAL_DEBUG_TEXT:
Use ‘!findthebuild’ command to search for the target build information.
If the build information is available, run ‘!findthebuild -s ; .reload’ to
set symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: 82a3e000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4b88cacf

BUGCHECK_STR: 0x7f_8

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 00000000 to 82a8362c

STACK_TEXT:
00000000 00000000 00000000 00000000 00000000 nt!Kei386EoiHelper+0x17d4

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!Kei386EoiHelper+17d4
82a8362c ebee jmp nt!Kei386EoiHelper+0x17c4 (82a8361c)

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!Kei386EoiHelper+17d4

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntkrpamp.exe

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

0: kd> k
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be
wrong.
00000000 00000000 nt!Kei386EoiHelper+0x17d4

Please suggest how to start debugging it.

-Madhusudhana

— WINDBG is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–
You are never given a dream without also being given the power to make it
true.

3

Madhusudan Narayan wrote:

I am new to dump analysis. I have got to debug a situation where the
system crashed( due to uplugging of a usb dongle).
!analyze -v didn’t give much useful info.

Does this dongle involve a driver that you have written, or are you an
IT specialist trying to chase down a generic crash?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.