RE: debugging a hung system

How about “!pool” on the address. Perhaps the tag will give you a hint
as to what this represents (or perhaps not).

Another approach is to unassemble the code prior to the KeWait call and
see if you can find a work item (or comparable hand-off code). From
that you might be able to find the hand-off logic.

Oh, here’s another question for you: what do you see in the work queues
(!exqueues)?

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 Hakim
Sent: Wednesday, November 03, 2004 4:53 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] debugging a hung system

I got this (the address chnaged since I made a reboot in the meantime)

kd> dt -r KEVENT 8192f5a4

+0x000 Header :

+0x000 Type : 0 ‘’

+0x001 Absolute : 0 ‘’

+0x002 Size : 0x4 ‘’

+0x003 Inserted : 0 ‘’

+0x004 SignalState : 0

+0x008 WaitListHead : [0xff9aaad0 - 0xff9aaad0]

+0x000 Flink : 0xff9aaad0 [0x8192f5ac - 0x8192f5ac]

+0x004 Blink : 0xff9aaad0 [0x8192f5ac - 0x8192f5ac]

How to poke around WaitListHead or how to go further?

Thanks,

Hakim

“Tony Mason” wrote in message news:xxxxx@windbg…
Their driver is waiting for something to happen before it proceeds. You
need to track the event in this case (818f53fc) and see if you can find
out what it is waiting for. You may find that it has created a
work-item and is waiting. Also, check to ensure there are no APCs
pending for this thread.

You are right - a simple wait would not cause the mouse/keyboard hang.
However, if they then didn’t allow any ADDITIONAL I/O to go to the
mouse/keyboard until this event were completed, you’d see exactly what
you are seeing.

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 Hakim
Sent: Wednesday, November 03, 2004 4:03 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] debugging a hung system

I already did !stacks and found their driver is blocked on a KeWait by
using
!thread but why a KeWait will make keyboard and mouse non-responsive?

Here is the output by !stacks related to their driver:

260.000290 ff9c0380 0000857 Blocked Theirdrv+0x2225

kd> !thread ff9c0380

THREAD ff9c0380 Cid 0260.0290 Teb: 7ffd8000 Win32Thread: e19f46f8
WAIT:
(Suspended) KernelMode Non-Alertable

818f53fc NotificationEvent

IRP List:

829baf00: (0006,0100) Flags: 40000030 Mdl: 00000000

82684eb8: (0006,0148) Flags: 40000884 Mdl: 00000000

82696f20: (0006,00dc) Flags: 40000970 Mdl: 00000000

Not impersonating

DeviceMap e10069d0

Owning Process 81935020

Wait Start TickCount 38841 Elapsed Ticks: 2135

Context Switch Count 9549 LargeStack

UserTime 00:00:00.0000

KernelTime 00:00:01.0822

Start Address 0x75b6b0f7

Stack Init fc6bb000 Current fc6ba414 Base fc6bb000 Limit fc6b8000 Call 0

Priority 15 BasePriority 13 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child

fc6ba42c 804dc6a6 ff9c03f0 ff9c0380 804dc6f2 nt!KiSwapContext+0x2e (FPO:

[EBP 0xfc6ba460] [0,0,4])

fc6ba438 804dc6f2 818f5388 818f540c 00000000 nt!KiSwapThread+0x46 (FPO:
[0,0,0])

fc6ba460 fa1f8225 00000000 00000005 00000000
nt!KeWaitForSingleObject+0x1c2

WARNING: Stack unwind information not available. Following frames may be

wrong.

fc6ba498 fa1f8d6b 818f53fc 00000004 fa1f7ae8 Theirdrv+0x2225

fc6ba4cc fa1f7d08 fa1f7ae8 0000000a 818f5388 Theirdrv+0x2d6b

ff7d05b0 ff7d04f8 ff7d8868 00000000 00000000 Theirdrv+0x1d08

ff7d8868 00000001 81a3b188 ff7d89d0 ff7d04f8 0xff7d04f8

Thanks,

Hakim

“Tony Mason” wrote in message news:xxxxx@windbg…
Start with the “!stacks” command. That will provide you with a list of
threads on the system (depending upon the version, it is either more or
less choosy about the threads it picks). From that list of threads, it
is a matter of figuring out what each one is waiting for - eventually
you will (if it is a deadlock) find some thread (or threads) that are
waiting for something that doesn’t happen but should happen.

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 Hakim
Sent: Wednesday, November 03, 2004 3:32 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] debugging a hung system

>
What is the initiating thread doing? What are the other threads on the
system doing?
>
I have got this when I tried to install their application that installs
an
upperfilter driver (theirs) on us and send IRP from the filter driver to
our
driver. I have no idea about what the filter driver is doing. Everytime
I
try to install their application I get the system hung meaning keyboad
and
mouse not responding and I don’t get a chance to activate driver
verifier on
their driver.
I have got the following stack:

8055084c 804e38a2 00000001 fff0bd02 00000030
nt!RtlpBreakWithStatusInstruction

8055084c 806f372a 00000001 fff0bd02 00000030 t!KeUpdateSystemTime+0x165

805508d0 804dc0d7 00000000 0000000e 00000000 hal!HalProcessorIdle+0x2

So, it’s not a ISR lock.

I also see that their driver is waiting on a KeWait but that should not
make
mouse and keyboard non-responsive.

It could be lock not releasing but !locks does not show any such hints.
Also, driver verifier will catch it even though it is not activated for
their driver.

Thanks,

Hakim

“Tony Mason” wrote in message news:xxxxx@windbg…
‘Success Error Cancel’ refers to the conditions under which the
cancellation routine is called.

This is definitely a strange IRP stack. The IRP in question looks like
it is in the process of being sent TO your driver (you are not the
current stack location, so it hasn’t been sent yet). If this were in
the completion state then your stack location would either be current or
it would be scrubbed. I suppose this might be queued somewhere waiting
to be sent to your device.

What is the initiating thread doing? What are the other threads on the
system doing? Why do you believe the system is hung? Deadlock analysis
generally requires finding the threads that are blocked but should not
be. If this IRP is involved, the question becomes “what is waiting for
this IRP to complete? Why is THAT event not occurring?”

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 Hakim
Sent: Wednesday, November 03, 2004 1:35 PM
To: Kernel Debugging Interest List
Subject: [windbg] debugging a hung system

Hello,

Im trying to debug a hung system and the suspect is a driver from user
that
uses our board, I find this irp suspicoius,

kd> !irp 823f6eb8 1

Irp is active with 6 stacks 5 is current (= 0x823f6fb8)

No Mdl Thread 818d3be0: Irp stack trace.

Flags = 40000884

ThreadListEntry.Flink = 818d3df0

ThreadListEntry.Blink = 81f22f10

IoStatus.Status = 00000000

IoStatus.Information = 00000000

RequestorMode = 00000000

Cancel = 00

CancelIrql = 0

ApcEnvironment = 00

UserIosb = fc6da6cc

UserEvent = 00000000

Overlay.AsynchronousParameters.UserApcRoutine = 00000000

Overlay.AsynchronousParameters.UserApcContext = 00000000

Overlay.AllocationSize = 00000000 - 00000000

CancelRoutine = 00000000

UserBuffer = 00000000

&Tail.Overlay.DeviceQueueEntry = 823f6ef8

Tail.Overlay.Thread = 818d3be0

Tail.Overlay.AuxiliaryBuffer = 00000000

Tail.Overlay.ListEntry.Flink = 00000000

Tail.Overlay.ListEntry.Blink = 00000000

Tail.Overlay.CurrentStackLocation = 823f6fb8

Tail.Overlay.OriginalFileObject = 81a19718

Tail.Apc = 00000000

Tail.CompletionKey = 00000000

cmd flg cl Device File Completion-Context

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[0, 0] 0 10 8191b330 00000000 fab7ed2d-fc6da4fc

\Driver\ourdrv theirdrv

Args: 00000000 00000000 00000000 00000000

>[0, 0] 0 e0 ff9c3400 81a19718 fc78336e-fc6da584 Success Error
Cancel

\Driver\theirdrv theirclass!theirSyncComplete

Args: fc6da660 03000000 00020000 00000000

[0, 0] 0 0 818fc488 81a19718 00000000-00000000

\Driver\Mouclass

Args: fc6da660 03000000 00020000 00000000

What does this ‘Success Error Cancel’ means? It seems it is not
pending.
Everytime I break I find this irp, is it stuck here? If so what could be
the
reason. I need

to tell the user about their driver of where the problem lies.

Thanks,

Hakim


You are currently subscribed to windbg as: xxxxx@osr.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


You are currently subscribed to windbg as: xxxxx@osr.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