Frozen system

NTDEV
1

I need some help. For about one week I’m dealing with a problem, that
manifest itself as a “frozen system”. The “frozen system” doesn’t respond on
any external event (mouse, keyboard, network, …). Since I run the system
in debug mode, I’m able to break-in with WinDbg. To reproduce the problem I
load the system with disk I/O (file/directory creation). Each time I hit
this “frozen system” problem, I find only 2 threads in RUNNING state (system
has 2 CPUs), with the call stack as below in in this e-mail. All other
threads are in WAIT state. These 2 threads are also always in the context of
SERVICES.EXE process.
The description of system is: W2K-SP2 (running with enabled debug), 2xCPUs,
512MB RAM, with standard HW (network, CD-ROM, disk).

Is the call stack below descriptive enough to explain the “frozen” state?
Both CPUs in acquiring spin lock and the IRQL high enough to mask other
IRQs?

Thank you in advance for any feedback.
Primoz

THREAD 811b9640 Cid e4.288 Teb: 7ffde000 Win32Thread: 00000000
RUNNING
IRP List:
81cd7a48: (0006,0094) Flags: 00000030 Mdl: 00000000
Not impersonating
Owning Process ae131d78
WaitTime (seconds) 465339
Context Switch Count 272
UserTime 0:00:00.0000
KernelTime 0:18:07.0359
Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
Stack Init f780d000 Current f780cbe8 Base f780d000 Limit f780a000
Call 0
Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
f780cb18 bfeb6516 00000000 00000000 8042d1ce
nt!KefAcquireSpinLockAtDpcLevel+0x8
f780cb3c bfeb95c0 00000000 00000000 81ada0e8
NDIS!ndisMapOpenByName+0x5e
f780cbc0 bfeb93d0 81ada0d8 81ada0e0 81ada15c
NDIS!ndisHandleProtocolReconfigNotification+0x69
f780cbdc bfeb9354 81cd7ab8 81cd7a48 00000000
NDIS!ndisHandleUModePnPOp+0x6d
f780cbf8 bfeb918c a59aff20 81cd7a48 f780cc34
NDIS!ndisHandlePnPRequest+0x13a
f780cc0c 8041d915 a59aff20 81cd7a48 81cd7a48
NDIS!ndisDispatchRequest+0x56
f780cc20 804b0512 81ada1cf 00000000 81cd7a48 nt!IopfCallDriver+0x35
f780cc34 804b1333 a59aff20 81cd7a48 a950df90
nt!IopSynchronousServiceTail+0x60
f780cd00 804a921e 000009a8 00000000 00000000
nt!IopXxxControlFile+0x5ab
f780cd34 80465679 000009a8 00000000 00000000
nt!NtDeviceIoControlFile+0x28
f780cd34 77f830a5 000009a8 00000000 00000000 nt!KiSystemService+0xc9
01f0faec 77e96fa1 000009a8 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xb
01f0fb50 77366478 000009a8 00170008 0008bbe8
KERNEL32!CreateProcessW+0x41
01f0fb90 773662bb 00000001 00000003 01f0fe4c
dhcpcsvc!NdisHandlePnPEvent+0x1c5
01f0fe60 773661f3 000e4c20 00000000 00000077
dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
01f0fe78 7736595e 000e4a20 0188a8c0 000e4a20
dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
01f0fe94 77364f04 000e4a20 01f0ff48 00000000
dhcpcsvc!DhcpSetAllStackParameters+0x94
01f0fec8 77363c8c 3d3685a0 01f0ff48 0188a8c0
dhcpcsvc!SetDhcpConfigurationForNIC+0x244
01f0ff2c 773638e8 00000004 01f0ff48 00000000
dhcpcsvc!RenewLease+0x1e1
01f0ffa0 77363865 000e4a20 00000000 77d49f00
dhcpcsvc!ReRenewParameters+0x58
01f0ffb4 77e96523 000ee1b8 77d49f00 77f82207
dhcpcsvc!DhcpRenewThread+0x4d
01f0ffec 00000000 7736381e 000ee1b8 00000000
KERNEL32!MakeLocHashNode+0x66

THREAD 811a7a20 Cid e4.440 Teb: 7ffd5000 Win32Thread: 00000000
RUNNING
IRP List:
81cb8b08: (0006,0094) Flags: 00000030 Mdl: 00000000
Not impersonating
Owning Process ae131d78
WaitTime (seconds) 465339
Context Switch Count 238
UserTime 0:00:00.0000
KernelTime 0:18:07.0343
Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
Stack Init f79df000 Current f79dec44 Base f79df000 Limit f79dc000
Call 0
Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
f79dea84 80469526 00000001 80448c02 000000d1
nt!RtlpBreakWithStatusInstruction
f79dea84 8006543c 00000001 80448c02 000000d1
nt!KeUpdateSystemTime+0x14e
f79deb08 bfeb7883 81a06132 bd839f30 bfebc0e7
hal!KfAcquireSpinLock+0x2c
f79deb14 bfebc0e7 8158fd08 00000000 00000000
NDIS!ndisReferenceRef+0xc
f79deb40 bfeb9577 00000000 8158fd08 00000000
NDIS!ndisReferenceProtocolByName+0xce
f79debc0 bfeb93d0 8158fcf8 8158fd00 8158fd7c
NDIS!ndisHandleProtocolReconfigNotification+0x20
f79debdc bfeb9354 81cb8b78 81cb8b08 00000000
NDIS!ndisHandleUModePnPOp+0x6d
f79debf8 bfeb918c a59aff20 81cb8b08 f79dec34
NDIS!ndisHandlePnPRequest+0x13a
f79dec0c 8041d915 a59aff20 81cb8b08 81cb8b08
NDIS!ndisDispatchRequest+0x56
f79dec20 804b0512 8158fdef 00000000 81cb8b08 nt!IopfCallDriver+0x35
f79dec34 804b1333 a59aff20 81cb8b08 8175a808
nt!IopSynchronousServiceTail+0x60
f79ded00 804a921e 000009b8 00000000 00000000
nt!IopXxxControlFile+0x5ab
f79ded34 80465679 000009b8 00000000 00000000
nt!NtDeviceIoControlFile+0x28
f79ded34 77f830a5 000009b8 00000000 00000000 nt!KiSystemService+0xc9
01f4faec 77e96fa1 000009b8 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xb
01f4fb50 77366478 000009b8 00170008 0008b900
KERNEL32!CreateProcessW+0x41
01f4fb90 773662bb 00000001 00000003 01f4fe4c
dhcpcsvc!NdisHandlePnPEvent+0x1c5
01f4fe60 773661f3 000e7000 00000000 00000077
dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
01f4fe78 7736595e 000e6e00 01a4a8c0 000e6e00
dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
01f4fe94 77364f04 000e6e00 01f4ff48 00000000
dhcpcsvc!DhcpSetAllStackParameters+0x94
01f4fec8 77363c8c 3d36859e 01f4ff48 01a4a8c0
dhcpcsvc!SetDhcpConfigurationForNIC+0x244
01f4ff2c 773638e8 00000005 01f4ff48 00000000
dhcpcsvc!RenewLease+0x1e1
01f4ffa0 77363865 000e6e00 00000000 77d49f00
dhcpcsvc!ReRenewParameters+0x58
01f4ffb4 77e96523 000d9510 77d49f00 77f82207
dhcpcsvc!DhcpRenewThread+0x4d
01f4ffec 00000000 7736381e 000d9510 00000000
KERNEL32!MakeLocHashNode+0x66

2

Primoz,

You couldn’t have GIVEN a better example of a live-locked system.

What has happened is that CPU 0 owns some lock (say spin lock “A”) and CPU 1
owns a different lock (say spin lock “B”). CPU 0 is spinning to acquire
spin lock “B” and CPU 1 is spinning to acquire spin lock “A”. They will
never succeed.

Unfortunately, KfAcquireSpinLock passes the spin lock address in a register,
so there’s no way (from the stack trace) to figure out what the two spin
locks are (although from the systems you should be able to figure out what
these spin locks are, since they will be in the ECX register on entry to
KfAcquireSpinLock.)

Deadlocks are resolved by adhering to a locking hierarchy (to prevent any
cycles in lock acquisition). WHAT that hierarchy is in this case, I cannot
say. Are the functions ndisMapOpenByName and ndisReferenceRef yours? If
so, you need to examine the locking they are performing very carefully,
because it is these two functions that seem to be implicated in this.

Another possibility to consider is that this involves only a SINGLE spin
lock, but that a reacquisition of that spin lock occurs in the code.

Finally, you might wish to try using a checked kernel and hal combination
because the checked kernel/hal actually have additional logic validation for
the use of spin locks.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http: http://www.osr.com

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: Primoz Beltram [mailto:xxxxx@hermes.si]
Sent: Thursday, July 18, 2002 9:53 AM
To: NT Developers Interest List
Subject: [ntdev] Frozen system

I need some help. For about one week I’m dealing with a problem, that
manifest itself as a “frozen system”. The “frozen system” doesn’t respond on
any external event (mouse, keyboard, network, …). Since I run the system
in debug mode, I’m able to break-in with WinDbg. To reproduce the problem I
load the system with disk I/O (file/directory creation). Each time I hit
this “frozen system” problem, I find only 2 threads in RUNNING state (system
has 2 CPUs), with the call stack as below in in this e-mail. All other
threads are in WAIT state. These 2 threads are also always in the context of
SERVICES.EXE process.

The description of system is: W2K-SP2 (running with enabled debug), 2xCPUs,
512MB RAM, with standard HW (network, CD-ROM, disk).

Is the call stack below descriptive enough to explain the “frozen” state?
Both CPUs in acquiring spin lock and the IRQL high enough to mask other
IRQs?

Thank you in advance for any feedback.
Primoz

THREAD 811b9640 Cid e4.288 Teb: 7ffde000 Win32Thread: 00000000
RUNNING
IRP List:
81cd7a48: (0006,0094) Flags: 00000030 Mdl: 00000000
Not impersonating
Owning Process ae131d78
WaitTime (seconds) 465339
Context Switch Count 272
UserTime 0:00:00.0000
KernelTime 0:18:07.0359
Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
Stack Init f780d000 Current f780cbe8 Base f780d000 Limit f780a000
Call 0
Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
f780cb18 bfeb6516 00000000 00000000 8042d1ce
nt!KefAcquireSpinLockAtDpcLevel+0x8
f780cb3c bfeb95c0 00000000 00000000 81ada0e8
NDIS!ndisMapOpenByName+0x5e
f780cbc0 bfeb93d0 81ada0d8 81ada0e0 81ada15c
NDIS!ndisHandleProtocolReconfigNotification+0x69
f780cbdc bfeb9354 81cd7ab8 81cd7a48 00000000
NDIS!ndisHandleUModePnPOp+0x6d
f780cbf8 bfeb918c a59aff20 81cd7a48 f780cc34
NDIS!ndisHandlePnPRequest+0x13a
f780cc0c 8041d915 a59aff20 81cd7a48 81cd7a48
NDIS!ndisDispatchRequest+0x56
f780cc20 804b0512 81ada1cf 00000000 81cd7a48 nt!IopfCallDriver+0x35
f780cc34 804b1333 a59aff20 81cd7a48 a950df90
nt!IopSynchronousServiceTail+0x60
f780cd00 804a921e 000009a8 00000000 00000000
nt!IopXxxControlFile+0x5ab
f780cd34 80465679 000009a8 00000000 00000000
nt!NtDeviceIoControlFile+0x28
f780cd34 77f830a5 000009a8 00000000 00000000 nt!KiSystemService+0xc9

01f0faec 77e96fa1 000009a8 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xb
01f0fb50 77366478 000009a8 00170008 0008bbe8
KERNEL32!CreateProcessW+0x41
01f0fb90 773662bb 00000001 00000003 01f0fe4c
dhcpcsvc!NdisHandlePnPEvent+0x1c5
01f0fe60 773661f3 000e4c20 00000000 00000077
dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
01f0fe78 7736595e 000e4a20 0188a8c0 000e4a20
dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
01f0fe94 77364f04 000e4a20 01f0ff48 00000000
dhcpcsvc!DhcpSetAllStackParameters+0x94
01f0fec8 77363c8c 3d3685a0 01f0ff48 0188a8c0
dhcpcsvc!SetDhcpConfigurationForNIC+0x244
01f0ff2c 773638e8 00000004 01f0ff48 00000000
dhcpcsvc!RenewLease+0x1e1
01f0ffa0 77363865 000e4a20 00000000 77d49f00
dhcpcsvc!ReRenewParameters+0x58
01f0ffb4 77e96523 000ee1b8 77d49f00 77f82207
dhcpcsvc!DhcpRenewThread+0x4d
01f0ffec 00000000 7736381e 000ee1b8 00000000
KERNEL32!MakeLocHashNode+0x66

THREAD 811a7a20 Cid e4.440 Teb: 7ffd5000 Win32Thread: 00000000
RUNNING
IRP List:
81cb8b08: (0006,0094) Flags: 00000030 Mdl: 00000000
Not impersonating
Owning Process ae131d78
WaitTime (seconds) 465339
Context Switch Count 238
UserTime 0:00:00.0000
KernelTime 0:18:07.0343
Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
Stack Init f79df000 Current f79dec44 Base f79df000 Limit f79dc000
Call 0
Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
f79dea84 80469526 00000001 80448c02 000000d1
nt!RtlpBreakWithStatusInstruction
f79dea84 8006543c 00000001 80448c02 000000d1
nt!KeUpdateSystemTime+0x14e
f79deb08 bfeb7883 81a06132 bd839f30 bfebc0e7
hal!KfAcquireSpinLock+0x2c
f79deb14 bfebc0e7 8158fd08 00000000 00000000
NDIS!ndisReferenceRef+0xc
f79deb40 bfeb9577 00000000 8158fd08 00000000
NDIS!ndisReferenceProtocolByName+0xce
f79debc0 bfeb93d0 8158fcf8 8158fd00 8158fd7c
NDIS!ndisHandleProtocolReconfigNotification+0x20
f79debdc bfeb9354 81cb8b78 81cb8b08 00000000
NDIS!ndisHandleUModePnPOp+0x6d
f79debf8 bfeb918c a59aff20 81cb8b08 f79dec34
NDIS!ndisHandlePnPRequest+0x13a
f79dec0c 8041d915 a59aff20 81cb8b08 81cb8b08
NDIS!ndisDispatchRequest+0x56
f79dec20 804b0512 8158fdef 00000000 81cb8b08 nt!IopfCallDriver+0x35
f79dec34 804b1333 a59aff20 81cb8b08 8175a808
nt!IopSynchronousServiceTail+0x60
f79ded00 804a921e 000009b8 00000000 00000000
nt!IopXxxControlFile+0x5ab
f79ded34 80465679 000009b8 00000000 00000000
nt!NtDeviceIoControlFile+0x28
f79ded34 77f830a5 000009b8 00000000 00000000 nt!KiSystemService+0xc9

01f4faec 77e96fa1 000009b8 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xb
01f4fb50 77366478 000009b8 00170008 0008b900
KERNEL32!CreateProcessW+0x41
01f4fb90 773662bb 00000001 00000003 01f4fe4c
dhcpcsvc!NdisHandlePnPEvent+0x1c5
01f4fe60 773661f3 000e7000 00000000 00000077
dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
01f4fe78 7736595e 000e6e00 01a4a8c0 000e6e00
dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
01f4fe94 77364f04 000e6e00 01f4ff48 00000000
dhcpcsvc!DhcpSetAllStackParameters+0x94
01f4fec8 77363c8c 3d36859e 01f4ff48 01a4a8c0
dhcpcsvc!SetDhcpConfigurationForNIC+0x244
01f4ff2c 773638e8 00000005 01f4ff48 00000000
dhcpcsvc!RenewLease+0x1e1
01f4ffa0 77363865 000e6e00 00000000 77d49f00
dhcpcsvc!ReRenewParameters+0x58
01f4ffb4 77e96523 000d9510 77d49f00 77f82207
dhcpcsvc!DhcpRenewThread+0x4d
01f4ffec 00000000 7736381e 000d9510 00000000
KERNEL32!MakeLocHashNode+0x66

—
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%</http:>

3

Tony,
Thank you for a quick replay and information.
None of NDIS!* functions are 3rd party (mine or some others), but came on
the system with regular MSDN W2K installation CD-ROM, W2K-SP2 or W2K-SRP1.

What kind of information could I get from ECX register value?
I can “.thread 811b9640” and find its value.
Primoz

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Thursday, July 18, 2002 4:10 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Frozen system

Primoz,

You couldn’t have GIVEN a better example of a live-locked system.

What has happened is that CPU 0 owns some lock (say spin lock “A”) and CPU 1
owns a different lock (say spin lock “B”). CPU 0 is spinning to acquire
spin lock “B” and CPU 1 is spinning to acquire spin lock “A”. They will
never succeed.

Unfortunately, KfAcquireSpinLock passes the spin lock address in a register,
so there’s no way (from the stack trace) to figure out what the two spin
locks are (although from the systems you should be able to figure out what
these spin locks are, since they will be in the ECX register on entry to
KfAcquireSpinLock.)

Deadlocks are resolved by adhering to a locking hierarchy (to prevent any
cycles in lock acquisition). WHAT that hierarchy is in this case, I cannot
say. Are the functions ndisMapOpenByName and ndisReferenceRef yours? If
so, you need to examine the locking they are performing very carefully,
because it is these two functions that seem to be implicated in this.

Another possibility to consider is that this involves only a SINGLE spin
lock, but that a reacquisition of that spin lock occurs in the code.

Finally, you might wish to try using a checked kernel and hal combination
because the checked kernel/hal actually have additional logic validation for
the use of spin locks.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http: http://www.osr.com

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: Primoz Beltram [mailto:xxxxx@hermes.si]
Sent: Thursday, July 18, 2002 9:53 AM
To: NT Developers Interest List
Subject: [ntdev] Frozen system

I need some help. For about one week I’m dealing with a problem, that
manifest itself as a “frozen system”. The “frozen system” doesn’t respond on
any external event (mouse, keyboard, network, …). Since I run the system
in debug mode, I’m able to break-in with WinDbg. To reproduce the problem I
load the system with disk I/O (file/directory creation). Each time I hit
this “frozen system” problem, I find only 2 threads in RUNNING state (system
has 2 CPUs), with the call stack as below in in this e-mail. All other
threads are in WAIT state. These 2 threads are also always in the context of
SERVICES.EXE process.

The description of system is: W2K-SP2 (running with enabled debug), 2xCPUs,
512MB RAM, with standard HW (network, CD-ROM, disk).

Is the call stack below descriptive enough to explain the “frozen” state?
Both CPUs in acquiring spin lock and the IRQL high enough to mask other
IRQs?

Thank you in advance for any feedback.
Primoz

THREAD 811b9640 Cid e4.288 Teb: 7ffde000 Win32Thread: 00000000
RUNNING
IRP List:
81cd7a48: (0006,0094) Flags: 00000030 Mdl: 00000000
Not impersonating
Owning Process ae131d78
WaitTime (seconds) 465339
Context Switch Count 272
UserTime 0:00:00.0000
KernelTime 0:18:07.0359
Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
Stack Init f780d000 Current f780cbe8 Base f780d000 Limit f780a000
Call 0
Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
f780cb18 bfeb6516 00000000 00000000 8042d1ce
nt!KefAcquireSpinLockAtDpcLevel+0x8
f780cb3c bfeb95c0 00000000 00000000 81ada0e8
NDIS!ndisMapOpenByName+0x5e
f780cbc0 bfeb93d0 81ada0d8 81ada0e0 81ada15c
NDIS!ndisHandleProtocolReconfigNotification+0x69
f780cbdc bfeb9354 81cd7ab8 81cd7a48 00000000
NDIS!ndisHandleUModePnPOp+0x6d
f780cbf8 bfeb918c a59aff20 81cd7a48 f780cc34
NDIS!ndisHandlePnPRequest+0x13a
f780cc0c 8041d915 a59aff20 81cd7a48 81cd7a48
NDIS!ndisDispatchRequest+0x56
f780cc20 804b0512 81ada1cf 00000000 81cd7a48 nt!IopfCallDriver+0x35
f780cc34 804b1333 a59aff20 81cd7a48 a950df90
nt!IopSynchronousServiceTail+0x60
f780cd00 804a921e 000009a8 00000000 00000000
nt!IopXxxControlFile+0x5ab
f780cd34 80465679 000009a8 00000000 00000000
nt!NtDeviceIoControlFile+0x28
f780cd34 77f830a5 000009a8 00000000 00000000 nt!KiSystemService+0xc9

01f0faec 77e96fa1 000009a8 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xb
01f0fb50 77366478 000009a8 00170008 0008bbe8
KERNEL32!CreateProcessW+0x41
01f0fb90 773662bb 00000001 00000003 01f0fe4c
dhcpcsvc!NdisHandlePnPEvent+0x1c5
01f0fe60 773661f3 000e4c20 00000000 00000077
dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
01f0fe78 7736595e 000e4a20 0188a8c0 000e4a20
dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
01f0fe94 77364f04 000e4a20 01f0ff48 00000000
dhcpcsvc!DhcpSetAllStackParameters+0x94
01f0fec8 77363c8c 3d3685a0 01f0ff48 0188a8c0
dhcpcsvc!SetDhcpConfigurationForNIC+0x244
01f0ff2c 773638e8 00000004 01f0ff48 00000000
dhcpcsvc!RenewLease+0x1e1
01f0ffa0 77363865 000e4a20 00000000 77d49f00
dhcpcsvc!ReRenewParameters+0x58
01f0ffb4 77e96523 000ee1b8 77d49f00 77f82207
dhcpcsvc!DhcpRenewThread+0x4d
01f0ffec 00000000 7736381e 000ee1b8 00000000
KERNEL32!MakeLocHashNode+0x66

THREAD 811a7a20 Cid e4.440 Teb: 7ffd5000 Win32Thread: 00000000
RUNNING
IRP List:
81cb8b08: (0006,0094) Flags: 00000030 Mdl: 00000000
Not impersonating
Owning Process ae131d78
WaitTime (seconds) 465339
Context Switch Count 238
UserTime 0:00:00.0000
KernelTime 0:18:07.0343
Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
Stack Init f79df000 Current f79dec44 Base f79df000 Limit f79dc000
Call 0
Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
f79dea84 80469526 00000001 80448c02 000000d1
nt!RtlpBreakWithStatusInstruction
f79dea84 8006543c 00000001 80448c02 000000d1
nt!KeUpdateSystemTime+0x14e
f79deb08 bfeb7883 81a06132 bd839f30 bfebc0e7
hal!KfAcquireSpinLock+0x2c
f79deb14 bfebc0e7 8158fd08 00000000 00000000
NDIS!ndisReferenceRef+0xc
f79deb40 bfeb9577 00000000 8158fd08 00000000
NDIS!ndisReferenceProtocolByName+0xce
f79debc0 bfeb93d0 8158fcf8 8158fd00 8158fd7c
NDIS!ndisHandleProtocolReconfigNotification+0x20
f79debdc bfeb9354 81cb8b78 81cb8b08 00000000
NDIS!ndisHandleUModePnPOp+0x6d
f79debf8 bfeb918c a59aff20 81cb8b08 f79dec34
NDIS!ndisHandlePnPRequest+0x13a
f79dec0c 8041d915 a59aff20 81cb8b08 81cb8b08
NDIS!ndisDispatchRequest+0x56
f79dec20 804b0512 8158fdef 00000000 81cb8b08 nt!IopfCallDriver+0x35
f79dec34 804b1333 a59aff20 81cb8b08 8175a808
nt!IopSynchronousServiceTail+0x60
f79ded00 804a921e 000009b8 00000000 00000000
nt!IopXxxControlFile+0x5ab
f79ded34 80465679 000009b8 00000000 00000000
nt!NtDeviceIoControlFile+0x28
f79ded34 77f830a5 000009b8 00000000 00000000 nt!KiSystemService+0xc9

01f4faec 77e96fa1 000009b8 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xb
01f4fb50 77366478 000009b8 00170008 0008b900
KERNEL32!CreateProcessW+0x41
01f4fb90 773662bb 00000001 00000003 01f4fe4c
dhcpcsvc!NdisHandlePnPEvent+0x1c5
01f4fe60 773661f3 000e7000 00000000 00000077
dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
01f4fe78 7736595e 000e6e00 01a4a8c0 000e6e00
dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
01f4fe94 77364f04 000e6e00 01f4ff48 00000000
dhcpcsvc!DhcpSetAllStackParameters+0x94
01f4fec8 77363c8c 3d36859e 01f4ff48 01a4a8c0
dhcpcsvc!SetDhcpConfigurationForNIC+0x244
01f4ff2c 773638e8 00000005 01f4ff48 00000000
dhcpcsvc!RenewLease+0x1e1
01f4ffa0 77363865 000e6e00 00000000 77d49f00
dhcpcsvc!ReRenewParameters+0x58
01f4ffb4 77e96523 000d9510 77d49f00 77f82207
dhcpcsvc!DhcpRenewThread+0x4d
01f4ffec 00000000 7736381e 000d9510 00000000
KERNEL32!MakeLocHashNode+0x66

—
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@hermes.si To
unsubscribe send a blank email to %%email.unsub%%</http:>

4

Primoz,

All fast calls (like KfAcquireSpinLock - the “f” means “fastcall”) pass the
first parameter in the ECX register. Here is the full declaration (from
ntddk.h):

_DECL_HAL_KE_IMPORT
KIRQL
FASTCALL
KfAcquireSpinLock (
IN PKSPIN_LOCK SpinLock
);

So, one parameter. On entry to this function, ECX contains the spin lock.
Since you have two routines here, you will either see the SAME value in each
CPUs ECX register (again, on entry to the function - the ECX register could
be re-used later in the code, which means you’ll have to look through the
disassembly of the calling function to figure out where the ECX value came
from) or a DIFFERENT value.

If you can get a dump of this system, I’d love to have it - it would be a
tremendous example in my debug lab (a livelock dump!)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: Primoz Beltram [mailto:xxxxx@hermes.si]
Sent: Thursday, July 18, 2002 10:29 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Frozen system

Tony,
Thank you for a quick replay and information.
None of NDIS!* functions are 3rd party (mine or some others), but came on
the system with regular MSDN W2K installation CD-ROM, W2K-SP2 or W2K-SRP1.

What kind of information could I get from ECX register value?
I can “.thread 811b9640” and find its value.
Primoz

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Thursday, July 18, 2002 4:10 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Frozen system

Primoz,

You couldn’t have GIVEN a better example of a live-locked system.

What has happened is that CPU 0 owns some lock (say spin lock “A”) and CPU 1
owns a different lock (say spin lock “B”). CPU 0 is spinning to acquire
spin lock “B” and CPU 1 is spinning to acquire spin lock “A”. They will
never succeed.

Unfortunately, KfAcquireSpinLock passes the spin lock address in a register,
so there’s no way (from the stack trace) to figure out what the two spin
locks are (although from the systems you should be able to figure out what
these spin locks are, since they will be in the ECX register on entry to
KfAcquireSpinLock.)

Deadlocks are resolved by adhering to a locking hierarchy (to prevent any
cycles in lock acquisition). WHAT that hierarchy is in this case, I cannot
say. Are the functions ndisMapOpenByName and ndisReferenceRef yours? If
so, you need to examine the locking they are performing very carefully,
because it is these two functions that seem to be implicated in this.

Another possibility to consider is that this involves only a SINGLE spin
lock, but that a reacquisition of that spin lock occurs in the code.

Finally, you might wish to try using a checked kernel and hal combination
because the checked kernel/hal actually have additional logic validation for
the use of spin locks.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http: http://www.osr.com

Hope to see you at the next OSR file systems class in San Jose, CA September
16, 2002!

-----Original Message-----
From: Primoz Beltram [mailto:xxxxx@hermes.si]
Sent: Thursday, July 18, 2002 9:53 AM
To: NT Developers Interest List
Subject: [ntdev] Frozen system

I need some help. For about one week I’m dealing with a problem, that
manifest itself as a “frozen system”. The “frozen system” doesn’t respond on
any external event (mouse, keyboard, network, …). Since I run the system
in debug mode, I’m able to break-in with WinDbg. To reproduce the problem I
load the system with disk I/O (file/directory creation). Each time I hit
this “frozen system” problem, I find only 2 threads in RUNNING state (system
has 2 CPUs), with the call stack as below in in this e-mail. All other
threads are in WAIT state. These 2 threads are also always in the context of
SERVICES.EXE process.

The description of system is: W2K-SP2 (running with enabled debug), 2xCPUs,
512MB RAM, with standard HW (network, CD-ROM, disk).

Is the call stack below descriptive enough to explain the “frozen” state?
Both CPUs in acquiring spin lock and the IRQL high enough to mask other
IRQs?

Thank you in advance for any feedback.
Primoz

THREAD 811b9640 Cid e4.288 Teb: 7ffde000 Win32Thread: 00000000
RUNNING
IRP List:
81cd7a48: (0006,0094) Flags: 00000030 Mdl: 00000000
Not impersonating
Owning Process ae131d78
WaitTime (seconds) 465339
Context Switch Count 272
UserTime 0:00:00.0000
KernelTime 0:18:07.0359
Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
Stack Init f780d000 Current f780cbe8 Base f780d000 Limit f780a000
Call 0
Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
f780cb18 bfeb6516 00000000 00000000 8042d1ce
nt!KefAcquireSpinLockAtDpcLevel+0x8
f780cb3c bfeb95c0 00000000 00000000 81ada0e8
NDIS!ndisMapOpenByName+0x5e
f780cbc0 bfeb93d0 81ada0d8 81ada0e0 81ada15c
NDIS!ndisHandleProtocolReconfigNotification+0x69
f780cbdc bfeb9354 81cd7ab8 81cd7a48 00000000
NDIS!ndisHandleUModePnPOp+0x6d
f780cbf8 bfeb918c a59aff20 81cd7a48 f780cc34
NDIS!ndisHandlePnPRequest+0x13a
f780cc0c 8041d915 a59aff20 81cd7a48 81cd7a48
NDIS!ndisDispatchRequest+0x56
f780cc20 804b0512 81ada1cf 00000000 81cd7a48 nt!IopfCallDriver+0x35
f780cc34 804b1333 a59aff20 81cd7a48 a950df90
nt!IopSynchronousServiceTail+0x60
f780cd00 804a921e 000009a8 00000000 00000000
nt!IopXxxControlFile+0x5ab
f780cd34 80465679 000009a8 00000000 00000000
nt!NtDeviceIoControlFile+0x28
f780cd34 77f830a5 000009a8 00000000 00000000 nt!KiSystemService+0xc9

01f0faec 77e96fa1 000009a8 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xb
01f0fb50 77366478 000009a8 00170008 0008bbe8
KERNEL32!CreateProcessW+0x41
01f0fb90 773662bb 00000001 00000003 01f0fe4c
dhcpcsvc!NdisHandlePnPEvent+0x1c5
01f0fe60 773661f3 000e4c20 00000000 00000077
dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
01f0fe78 7736595e 000e4a20 0188a8c0 000e4a20
dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
01f0fe94 77364f04 000e4a20 01f0ff48 00000000
dhcpcsvc!DhcpSetAllStackParameters+0x94
01f0fec8 77363c8c 3d3685a0 01f0ff48 0188a8c0
dhcpcsvc!SetDhcpConfigurationForNIC+0x244
01f0ff2c 773638e8 00000004 01f0ff48 00000000
dhcpcsvc!RenewLease+0x1e1
01f0ffa0 77363865 000e4a20 00000000 77d49f00
dhcpcsvc!ReRenewParameters+0x58
01f0ffb4 77e96523 000ee1b8 77d49f00 77f82207
dhcpcsvc!DhcpRenewThread+0x4d
01f0ffec 00000000 7736381e 000ee1b8 00000000
KERNEL32!MakeLocHashNode+0x66

THREAD 811a7a20 Cid e4.440 Teb: 7ffd5000 Win32Thread: 00000000
RUNNING
IRP List:
81cb8b08: (0006,0094) Flags: 00000030 Mdl: 00000000
Not impersonating
Owning Process ae131d78
WaitTime (seconds) 465339
Context Switch Count 238
UserTime 0:00:00.0000
KernelTime 0:18:07.0343
Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
Stack Init f79df000 Current f79dec44 Base f79df000 Limit f79dc000
Call 0
Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
f79dea84 80469526 00000001 80448c02 000000d1
nt!RtlpBreakWithStatusInstruction
f79dea84 8006543c 00000001 80448c02 000000d1
nt!KeUpdateSystemTime+0x14e
f79deb08 bfeb7883 81a06132 bd839f30 bfebc0e7
hal!KfAcquireSpinLock+0x2c
f79deb14 bfebc0e7 8158fd08 00000000 00000000
NDIS!ndisReferenceRef+0xc
f79deb40 bfeb9577 00000000 8158fd08 00000000
NDIS!ndisReferenceProtocolByName+0xce
f79debc0 bfeb93d0 8158fcf8 8158fd00 8158fd7c
NDIS!ndisHandleProtocolReconfigNotification+0x20
f79debdc bfeb9354 81cb8b78 81cb8b08 00000000
NDIS!ndisHandleUModePnPOp+0x6d
f79debf8 bfeb918c a59aff20 81cb8b08 f79dec34
NDIS!ndisHandlePnPRequest+0x13a
f79dec0c 8041d915 a59aff20 81cb8b08 81cb8b08
NDIS!ndisDispatchRequest+0x56
f79dec20 804b0512 8158fdef 00000000 81cb8b08 nt!IopfCallDriver+0x35
f79dec34 804b1333 a59aff20 81cb8b08 8175a808
nt!IopSynchronousServiceTail+0x60
f79ded00 804a921e 000009b8 00000000 00000000
nt!IopXxxControlFile+0x5ab
f79ded34 80465679 000009b8 00000000 00000000
nt!NtDeviceIoControlFile+0x28
f79ded34 77f830a5 000009b8 00000000 00000000 nt!KiSystemService+0xc9

01f4faec 77e96fa1 000009b8 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xb
01f4fb50 77366478 000009b8 00170008 0008b900
KERNEL32!CreateProcessW+0x41
01f4fb90 773662bb 00000001 00000003 01f4fe4c
dhcpcsvc!NdisHandlePnPEvent+0x1c5
01f4fe60 773661f3 000e7000 00000000 00000077
dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
01f4fe78 7736595e 000e6e00 01a4a8c0 000e6e00
dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
01f4fe94 77364f04 000e6e00 01f4ff48 00000000
dhcpcsvc!DhcpSetAllStackParameters+0x94
01f4fec8 77363c8c 3d36859e 01f4ff48 01a4a8c0
dhcpcsvc!SetDhcpConfigurationForNIC+0x244
01f4ff2c 773638e8 00000005 01f4ff48 00000000
dhcpcsvc!RenewLease+0x1e1
01f4ffa0 77363865 000e6e00 00000000 77d49f00
dhcpcsvc!ReRenewParameters+0x58
01f4ffb4 77e96523 000d9510 77d49f00 77f82207
dhcpcsvc!DhcpRenewThread+0x4d
01f4ffec 00000000 7736381e 000d9510 00000000
KERNEL32!MakeLocHashNode+0x66

—
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@hermes.si To
unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%</http:>

5

There are 2 distinct spinlocks involved , one is the NDIS global lock, which
is aquired here assuming DPC level , and his thread THREAD 811b9640 spins
for it , the other is a local spin lock, on which thread THREAD 811a7a20
spins.

The normal lock hierarchy is

local spin lock is aquired and , IRQL raise to dispatch
global NDIS lock is aquired , at dispatch

I cant see yet what can lead to your situation. Do you interefere in any
kind with NDIS PNP requests ?

Dan

----- Original Message -----
From: “Tony Mason”
To: “NT Developers Interest List”
Sent: Thursday, July 18, 2002 5:40 PM
Subject: [ntdev] RE: Frozen system

> Primoz,
>
> All fast calls (like KfAcquireSpinLock - the “f” means “fastcall”) pass
the
> first parameter in the ECX register. Here is the full declaration (from
> ntddk.h):
>
> _DECL_HAL_KE_IMPORT
> KIRQL
> FASTCALL
> KfAcquireSpinLock (
> IN PKSPIN_LOCK SpinLock
> );
>
>
> So, one parameter. On entry to this function, ECX contains the spin lock.
> Since you have two routines here, you will either see the SAME value in
each
> CPUs ECX register (again, on entry to the function - the ECX register
could
> be re-used later in the code, which means you’ll have to look through the
> disassembly of the calling function to figure out where the ECX value came
> from) or a DIFFERENT value.
>
> If you can get a dump of this system, I’d love to have it - it would be a
> tremendous example in my debug lab (a livelock dump!)
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: Primoz Beltram [mailto:xxxxx@hermes.si]
> Sent: Thursday, July 18, 2002 10:29 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Frozen system
>
> Tony,
> Thank you for a quick replay and information.
> None of NDIS!* functions are 3rd party (mine or some others), but came on
> the system with regular MSDN W2K installation CD-ROM, W2K-SP2 or W2K-SRP1.
>
> What kind of information could I get from ECX register value?
> I can “.thread 811b9640” and find its value.
> Primoz
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: Thursday, July 18, 2002 4:10 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Frozen system
>
>
> Primoz,
>
>
>
> You couldn’t have GIVEN a better example of a live-locked system.
>
>
>
> What has happened is that CPU 0 owns some lock (say spin lock “A”) and CPU
1
> owns a different lock (say spin lock “B”). CPU 0 is spinning to acquire
> spin lock “B” and CPU 1 is spinning to acquire spin lock “A”. They will
> never succeed.
>
>
>
> Unfortunately, KfAcquireSpinLock passes the spin lock address in a
register,
> so there’s no way (from the stack trace) to figure out what the two spin
> locks are (although from the systems you should be able to figure out what
> these spin locks are, since they will be in the ECX register on entry to
> KfAcquireSpinLock.)
>
>
>
> Deadlocks are resolved by adhering to a locking hierarchy (to prevent any
> cycles in lock acquisition). WHAT that hierarchy is in this case, I
cannot
> say. Are the functions ndisMapOpenByName and ndisReferenceRef yours? If
> so, you need to examine the locking they are performing very carefully,
> because it is these two functions that seem to be implicated in this.
>
>
>
> Another possibility to consider is that this involves only a SINGLE spin
> lock, but that a reacquisition of that spin lock occurs in the code.
>
>
>
> Finally, you might wish to try using a checked kernel and hal combination
> because the checked kernel/hal actually have additional logic validation
for
> the use of spin locks.
>
>
>
> Regards,
>
>
>
> Tony
>
>
>
> Tony Mason
>
> Consulting Partner
>
> OSR Open Systems Resources, Inc.
>
> http: http://www.osr.com
>
>
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: Primoz Beltram [mailto:xxxxx@hermes.si]
> Sent: Thursday, July 18, 2002 9:53 AM
> To: NT Developers Interest List
> Subject: [ntdev] Frozen system
>
>
>
> I need some help. For about one week I’m dealing with a problem, that
> manifest itself as a “frozen system”. The “frozen system” doesn’t respond
on
> any external event (mouse, keyboard, network, …). Since I run the system
> in debug mode, I’m able to break-in with WinDbg. To reproduce the problem
I
> load the system with disk I/O (file/directory creation). Each time I hit
> this “frozen system” problem, I find only 2 threads in RUNNING state
(system
> has 2 CPUs), with the call stack as below in in this e-mail. All other
> threads are in WAIT state. These 2 threads are also always in the context
of
> SERVICES.EXE process.
>
> The description of system is: W2K-SP2 (running with enabled debug),
2xCPUs,
> 512MB RAM, with standard HW (network, CD-ROM, disk).
>
> Is the call stack below descriptive enough to explain the “frozen” state?
> Both CPUs in acquiring spin lock and the IRQL high enough to mask other
> IRQs?
>
> Thank you in advance for any feedback.
> Primoz
>
>
>
> THREAD 811b9640 Cid e4.288 Teb: 7ffde000 Win32Thread: 00000000
> RUNNING
> IRP List:
> 81cd7a48: (0006,0094) Flags: 00000030 Mdl: 00000000
> Not impersonating
> Owning Process ae131d78
> WaitTime (seconds) 465339
> Context Switch Count 272
> UserTime 0:00:00.0000
> KernelTime 0:18:07.0359
> Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
> Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
> Stack Init f780d000 Current f780cbe8 Base f780d000 Limit f780a000
> Call 0
> Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount 0
>
> ChildEBP RetAddr Args to Child
> f780cb18 bfeb6516 00000000 00000000 8042d1ce
> nt!KefAcquireSpinLockAtDpcLevel+0x8
> f780cb3c bfeb95c0 00000000 00000000 81ada0e8
> NDIS!ndisMapOpenByName+0x5e
> f780cbc0 bfeb93d0 81ada0d8 81ada0e0 81ada15c
> NDIS!ndisHandleProtocolReconfigNotification+0x69
> f780cbdc bfeb9354 81cd7ab8 81cd7a48 00000000
> NDIS!ndisHandleUModePnPOp+0x6d
> f780cbf8 bfeb918c a59aff20 81cd7a48 f780cc34
> NDIS!ndisHandlePnPRequest+0x13a
> f780cc0c 8041d915 a59aff20 81cd7a48 81cd7a48
> NDIS!ndisDispatchRequest+0x56
> f780cc20 804b0512 81ada1cf 00000000 81cd7a48
nt!IopfCallDriver+0x35
> f780cc34 804b1333 a59aff20 81cd7a48 a950df90
> nt!IopSynchronousServiceTail+0x60
> f780cd00 804a921e 000009a8 00000000 00000000
> nt!IopXxxControlFile+0x5ab
> f780cd34 80465679 000009a8 00000000 00000000
> nt!NtDeviceIoControlFile+0x28
> f780cd34 77f830a5 000009a8 00000000 00000000
nt!KiSystemService+0xc9
>
> 01f0faec 77e96fa1 000009a8 00000000 00000000
> ntdll!ZwDeviceIoControlFile+0xb
> 01f0fb50 77366478 000009a8 00170008 0008bbe8
> KERNEL32!CreateProcessW+0x41
> 01f0fb90 773662bb 00000001 00000003 01f0fe4c
> dhcpcsvc!NdisHandlePnPEvent+0x1c5
> 01f0fe60 773661f3 000e4c20 00000000 00000077
> dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
> 01f0fe78 7736595e 000e4a20 0188a8c0 000e4a20
> dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
> 01f0fe94 77364f04 000e4a20 01f0ff48 00000000
> dhcpcsvc!DhcpSetAllStackParameters+0x94
> 01f0fec8 77363c8c 3d3685a0 01f0ff48 0188a8c0
> dhcpcsvc!SetDhcpConfigurationForNIC+0x244
> 01f0ff2c 773638e8 00000004 01f0ff48 00000000
> dhcpcsvc!RenewLease+0x1e1
> 01f0ffa0 77363865 000e4a20 00000000 77d49f00
> dhcpcsvc!ReRenewParameters+0x58
> 01f0ffb4 77e96523 000ee1b8 77d49f00 77f82207
> dhcpcsvc!DhcpRenewThread+0x4d
> 01f0ffec 00000000 7736381e 000ee1b8 00000000
> KERNEL32!MakeLocHashNode+0x66
>
> THREAD 811a7a20 Cid e4.440 Teb: 7ffd5000 Win32Thread: 00000000
> RUNNING
> IRP List:
> 81cb8b08: (0006,0094) Flags: 00000030 Mdl: 00000000
> Not impersonating
> Owning Process ae131d78
> WaitTime (seconds) 465339
> Context Switch Count 238
> UserTime 0:00:00.0000
> KernelTime 0:18:07.0343
> Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
> Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
> Stack Init f79df000 Current f79dec44 Base f79df000 Limit f79dc000
> Call 0
> Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount 0
>
> ChildEBP RetAddr Args to Child
> f79dea84 80469526 00000001 80448c02 000000d1
> nt!RtlpBreakWithStatusInstruction
> f79dea84 8006543c 00000001 80448c02 000000d1
> nt!KeUpdateSystemTime+0x14e
> f79deb08 bfeb7883 81a06132 bd839f30 bfebc0e7
> hal!KfAcquireSpinLock+0x2c
> f79deb14 bfebc0e7 8158fd08 00000000 00000000
> NDIS!ndisReferenceRef+0xc
> f79deb40 bfeb9577 00000000 8158fd08 00000000
> NDIS!ndisReferenceProtocolByName+0xce
> f79debc0 bfeb93d0 8158fcf8 8158fd00 8158fd7c
> NDIS!ndisHandleProtocolReconfigNotification+0x20
> f79debdc bfeb9354 81cb8b78 81cb8b08 00000000
> NDIS!ndisHandleUModePnPOp+0x6d
> f79debf8 bfeb918c a59aff20 81cb8b08 f79dec34
> NDIS!ndisHandlePnPRequest+0x13a
> f79dec0c 8041d915 a59aff20 81cb8b08 81cb8b08
> NDIS!ndisDispatchRequest+0x56
> f79dec20 804b0512 8158fdef 00000000 81cb8b08
nt!IopfCallDriver+0x35
> f79dec34 804b1333 a59aff20 81cb8b08 8175a808
> nt!IopSynchronousServiceTail+0x60
> f79ded00 804a921e 000009b8 00000000 00000000
> nt!IopXxxControlFile+0x5ab
> f79ded34 80465679 000009b8 00000000 00000000
> nt!NtDeviceIoControlFile+0x28
> f79ded34 77f830a5 000009b8 00000000 00000000
nt!KiSystemService+0xc9
>
> 01f4faec 77e96fa1 000009b8 00000000 00000000
> ntdll!ZwDeviceIoControlFile+0xb
> 01f4fb50 77366478 000009b8 00170008 0008b900
> KERNEL32!CreateProcessW+0x41
> 01f4fb90 773662bb 00000001 00000003 01f4fe4c
> dhcpcsvc!NdisHandlePnPEvent+0x1c5
> 01f4fe60 773661f3 000e7000 00000000 00000077
> dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
> 01f4fe78 7736595e 000e6e00 01a4a8c0 000e6e00
> dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
> 01f4fe94 77364f04 000e6e00 01f4ff48 00000000
> dhcpcsvc!DhcpSetAllStackParameters+0x94
> 01f4fec8 77363c8c 3d36859e 01f4ff48 01a4a8c0
> dhcpcsvc!SetDhcpConfigurationForNIC+0x244
> 01f4ff2c 773638e8 00000005 01f4ff48 00000000
> dhcpcsvc!RenewLease+0x1e1
> 01f4ffa0 77363865 000e6e00 00000000 77d49f00
> dhcpcsvc!ReRenewParameters+0x58
> 01f4ffb4 77e96523 000d9510 77d49f00 77f82207
> dhcpcsvc!DhcpRenewThread+0x4d
> 01f4ffec 00000000 7736381e 000d9510 00000000
> KERNEL32!MakeLocHashNode+0x66
>
> —
> You are currently subscribed to ntdev as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hermes.si To
> unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
></http:>

6

Primoz,

I discussed this with the NDIS team here at Microsoft and learned that
this is an issue that was fixed in XP. For this to happen, you have to
have multiple code paths handling PnP IoCtls for NDIS that we thought
could only be generated from UI. It appears that dhcpsvc is somehow
triggering PnP IoCtls as well.

Bryan S. Burgin
xxxxx@microsoft.com

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Thursday, July 18, 2002 9:16 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Frozen system

There are 2 distinct spinlocks involved , one is the NDIS global lock,
which
is aquired here assuming DPC level , and his thread THREAD 811b9640
spins
for it , the other is a local spin lock, on which thread THREAD
811a7a20
spins.

The normal lock hierarchy is

local spin lock is aquired and , IRQL raise to dispatch
global NDIS lock is aquired , at dispatch

I cant see yet what can lead to your situation. Do you interefere in any
kind with NDIS PNP requests ?

Dan

----- Original Message -----
From: “Tony Mason”
To: “NT Developers Interest List”
Sent: Thursday, July 18, 2002 5:40 PM
Subject: [ntdev] RE: Frozen system

> Primoz,
>
> All fast calls (like KfAcquireSpinLock - the “f” means “fastcall”)
pass
the
> first parameter in the ECX register. Here is the full declaration
(from
> ntddk.h):
>
> _DECL_HAL_KE_IMPORT
> KIRQL
> FASTCALL
> KfAcquireSpinLock (
> IN PKSPIN_LOCK SpinLock
> );
>
>
> So, one parameter. On entry to this function, ECX contains the spin
lock.
> Since you have two routines here, you will either see the SAME value
in
each
> CPUs ECX register (again, on entry to the function - the ECX register
could
> be re-used later in the code, which means you’ll have to look through
the
> disassembly of the calling function to figure out where the ECX value
came
> from) or a DIFFERENT value.
>
> If you can get a dump of this system, I’d love to have it - it would
be a
> tremendous example in my debug lab (a livelock dump!)
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: Primoz Beltram [mailto:xxxxx@hermes.si]
> Sent: Thursday, July 18, 2002 10:29 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Frozen system
>
> Tony,
> Thank you for a quick replay and information.
> None of NDIS!* functions are 3rd party (mine or some others), but came
on
> the system with regular MSDN W2K installation CD-ROM, W2K-SP2 or
W2K-SRP1.
>
> What kind of information could I get from ECX register value?
> I can “.thread 811b9640” and find its value.
> Primoz
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: Thursday, July 18, 2002 4:10 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Frozen system
>
>
> Primoz,
>
>
>
> You couldn’t have GIVEN a better example of a live-locked system.
>
>
>
> What has happened is that CPU 0 owns some lock (say spin lock “A”) and
CPU
1
> owns a different lock (say spin lock “B”). CPU 0 is spinning to
acquire
> spin lock “B” and CPU 1 is spinning to acquire spin lock “A”. They
will
> never succeed.
>
>
>
> Unfortunately, KfAcquireSpinLock passes the spin lock address in a
register,
> so there’s no way (from the stack trace) to figure out what the two
spin
> locks are (although from the systems you should be able to figure out
what
> these spin locks are, since they will be in the ECX register on entry
to
> KfAcquireSpinLock.)
>
>
>
> Deadlocks are resolved by adhering to a locking hierarchy (to prevent
any
> cycles in lock acquisition). WHAT that hierarchy is in this case, I
cannot
> say. Are the functions ndisMapOpenByName and ndisReferenceRef yours?
If
> so, you need to examine the locking they are performing very
carefully,
> because it is these two functions that seem to be implicated in this.
>
>
>
> Another possibility to consider is that this involves only a SINGLE
spin
> lock, but that a reacquisition of that spin lock occurs in the code.
>
>
>
> Finally, you might wish to try using a checked kernel and hal
combination
> because the checked kernel/hal actually have additional logic
validation
for
> the use of spin locks.
>
>
>
> Regards,
>
>
>
> Tony
>
>
>
> Tony Mason
>
> Consulting Partner
>
> OSR Open Systems Resources, Inc.
>
> http: http://www.osr.com
>
>
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: Primoz Beltram [mailto:xxxxx@hermes.si]
> Sent: Thursday, July 18, 2002 9:53 AM
> To: NT Developers Interest List
> Subject: [ntdev] Frozen system
>
>
>
> I need some help. For about one week I’m dealing with a problem, that
> manifest itself as a “frozen system”. The “frozen system” doesn’t
respond
on
> any external event (mouse, keyboard, network, …). Since I run the
system
> in debug mode, I’m able to break-in with WinDbg. To reproduce the
problem
I
> load the system with disk I/O (file/directory creation). Each time I
hit
> this “frozen system” problem, I find only 2 threads in RUNNING state
(system
> has 2 CPUs), with the call stack as below in in this e-mail. All other
> threads are in WAIT state. These 2 threads are also always in the
context
of
> SERVICES.EXE process.
>
> The description of system is: W2K-SP2 (running with enabled debug),
2xCPUs,
> 512MB RAM, with standard HW (network, CD-ROM, disk).
>
> Is the call stack below descriptive enough to explain the “frozen”
state?
> Both CPUs in acquiring spin lock and the IRQL high enough to mask
other
> IRQs?
>
> Thank you in advance for any feedback.
> Primoz
>
>
>
> THREAD 811b9640 Cid e4.288 Teb: 7ffde000 Win32Thread:
00000000
> RUNNING
> IRP List:
> 81cd7a48: (0006,0094) Flags: 00000030 Mdl: 00000000
> Not impersonating
> Owning Process ae131d78
> WaitTime (seconds) 465339
> Context Switch Count 272
> UserTime 0:00:00.0000
> KernelTime 0:18:07.0359
> Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
> Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
> Stack Init f780d000 Current f780cbe8 Base f780d000 Limit
f780a000
> Call 0
> Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount
0
>
> ChildEBP RetAddr Args to Child
> f780cb18 bfeb6516 00000000 00000000 8042d1ce
> nt!KefAcquireSpinLockAtDpcLevel+0x8
> f780cb3c bfeb95c0 00000000 00000000 81ada0e8
> NDIS!ndisMapOpenByName+0x5e
> f780cbc0 bfeb93d0 81ada0d8 81ada0e0 81ada15c
> NDIS!ndisHandleProtocolReconfigNotification+0x69
> f780cbdc bfeb9354 81cd7ab8 81cd7a48 00000000
> NDIS!ndisHandleUModePnPOp+0x6d
> f780cbf8 bfeb918c a59aff20 81cd7a48 f780cc34
> NDIS!ndisHandlePnPRequest+0x13a
> f780cc0c 8041d915 a59aff20 81cd7a48 81cd7a48
> NDIS!ndisDispatchRequest+0x56
> f780cc20 804b0512 81ada1cf 00000000 81cd7a48
nt!IopfCallDriver+0x35
> f780cc34 804b1333 a59aff20 81cd7a48 a950df90
> nt!IopSynchronousServiceTail+0x60
> f780cd00 804a921e 000009a8 00000000 00000000
> nt!IopXxxControlFile+0x5ab
> f780cd34 80465679 000009a8 00000000 00000000
> nt!NtDeviceIoControlFile+0x28
> f780cd34 77f830a5 000009a8 00000000 00000000
nt!KiSystemService+0xc9
>
> 01f0faec 77e96fa1 000009a8 00000000 00000000
> ntdll!ZwDeviceIoControlFile+0xb
> 01f0fb50 77366478 000009a8 00170008 0008bbe8
> KERNEL32!CreateProcessW+0x41
> 01f0fb90 773662bb 00000001 00000003 01f0fe4c
> dhcpcsvc!NdisHandlePnPEvent+0x1c5
> 01f0fe60 773661f3 000e4c20 00000000 00000077
> dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
> 01f0fe78 7736595e 000e4a20 0188a8c0 000e4a20
> dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
> 01f0fe94 77364f04 000e4a20 01f0ff48 00000000
> dhcpcsvc!DhcpSetAllStackParameters+0x94
> 01f0fec8 77363c8c 3d3685a0 01f0ff48 0188a8c0
> dhcpcsvc!SetDhcpConfigurationForNIC+0x244
> 01f0ff2c 773638e8 00000004 01f0ff48 00000000
> dhcpcsvc!RenewLease+0x1e1
> 01f0ffa0 77363865 000e4a20 00000000 77d49f00
> dhcpcsvc!ReRenewParameters+0x58
> 01f0ffb4 77e96523 000ee1b8 77d49f00 77f82207
> dhcpcsvc!DhcpRenewThread+0x4d
> 01f0ffec 00000000 7736381e 000ee1b8 00000000
> KERNEL32!MakeLocHashNode+0x66
>
> THREAD 811a7a20 Cid e4.440 Teb: 7ffd5000 Win32Thread:
00000000
> RUNNING
> IRP List:
> 81cb8b08: (0006,0094) Flags: 00000030 Mdl: 00000000
> Not impersonating
> Owning Process ae131d78
> WaitTime (seconds) 465339
> Context Switch Count 238
> UserTime 0:00:00.0000
> KernelTime 0:18:07.0343
> Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
> Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
> Stack Init f79df000 Current f79dec44 Base f79df000 Limit
f79dc000
> Call 0
> Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount
0
>
> ChildEBP RetAddr Args to Child
> f79dea84 80469526 00000001 80448c02 000000d1
> nt!RtlpBreakWithStatusInstruction
> f79dea84 8006543c 00000001 80448c02 000000d1
> nt!KeUpdateSystemTime+0x14e
> f79deb08 bfeb7883 81a06132 bd839f30 bfebc0e7
> hal!KfAcquireSpinLock+0x2c
> f79deb14 bfebc0e7 8158fd08 00000000 00000000
> NDIS!ndisReferenceRef+0xc
> f79deb40 bfeb9577 00000000 8158fd08 00000000
> NDIS!ndisReferenceProtocolByName+0xce
> f79debc0 bfeb93d0 8158fcf8 8158fd00 8158fd7c
> NDIS!ndisHandleProtocolReconfigNotification+0x20
> f79debdc bfeb9354 81cb8b78 81cb8b08 00000000
> NDIS!ndisHandleUModePnPOp+0x6d
> f79debf8 bfeb918c a59aff20 81cb8b08 f79dec34
> NDIS!ndisHandlePnPRequest+0x13a
> f79dec0c 8041d915 a59aff20 81cb8b08 81cb8b08
> NDIS!ndisDispatchRequest+0x56
> f79dec20 804b0512 8158fdef 00000000 81cb8b08
nt!IopfCallDriver+0x35
> f79dec34 804b1333 a59aff20 81cb8b08 8175a808
> nt!IopSynchronousServiceTail+0x60
> f79ded00 804a921e 000009b8 00000000 00000000
> nt!IopXxxControlFile+0x5ab
> f79ded34 80465679 000009b8 00000000 00000000
> nt!NtDeviceIoControlFile+0x28
> f79ded34 77f830a5 000009b8 00000000 00000000
nt!KiSystemService+0xc9
>
> 01f4faec 77e96fa1 000009b8 00000000 00000000
> ntdll!ZwDeviceIoControlFile+0xb
> 01f4fb50 77366478 000009b8 00170008 0008b900
> KERNEL32!CreateProcessW+0x41
> 01f4fb90 773662bb 00000001 00000003 01f4fe4c
> dhcpcsvc!NdisHandlePnPEvent+0x1c5
> 01f4fe60 773661f3 000e7000 00000000 00000077
> dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
> 01f4fe78 7736595e 000e6e00 01a4a8c0 000e6e00
> dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
> 01f4fe94 77364f04 000e6e00 01f4ff48 00000000
> dhcpcsvc!DhcpSetAllStackParameters+0x94
> 01f4fec8 77363c8c 3d36859e 01f4ff48 01a4a8c0
> dhcpcsvc!SetDhcpConfigurationForNIC+0x244
> 01f4ff2c 773638e8 00000005 01f4ff48 00000000
> dhcpcsvc!RenewLease+0x1e1
> 01f4ffa0 77363865 000e6e00 00000000 77d49f00
> dhcpcsvc!ReRenewParameters+0x58
> 01f4ffb4 77e96523 000d9510 77d49f00 77f82207
> dhcpcsvc!DhcpRenewThread+0x4d
> 01f4ffec 00000000 7736381e 000d9510 00000000
> KERNEL32!MakeLocHashNode+0x66
>
> —
> You are currently subscribed to ntdev as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hermes.si To
> unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

—
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to %%email.unsub%%</http:>

7

Thank you for reply. I don’t “touch” NDIS. I can reproduce the hang quite
often (4-times in last week), if I put the system under heavy disk I/O load.
WBR Primoz

-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Thursday, July 18, 2002 6:16 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Frozen system

There are 2 distinct spinlocks involved , one is the NDIS global lock, which
is aquired here assuming DPC level , and his thread THREAD 811b9640 spins
for it , the other is a local spin lock, on which thread THREAD 811a7a20
spins.

The normal lock hierarchy is

local spin lock is aquired and , IRQL raise to dispatch
global NDIS lock is aquired , at dispatch

I cant see yet what can lead to your situation. Do you interefere in any
kind with NDIS PNP requests ?

Dan

----- Original Message -----
From: “Tony Mason”
To: “NT Developers Interest List”
Sent: Thursday, July 18, 2002 5:40 PM
Subject: [ntdev] RE: Frozen system

> Primoz,
>
> All fast calls (like KfAcquireSpinLock - the “f” means “fastcall”)
> pass
the
> first parameter in the ECX register. Here is the full declaration
> (from
> ntddk.h):
>
> _DECL_HAL_KE_IMPORT
> KIRQL
> FASTCALL
> KfAcquireSpinLock (
> IN PKSPIN_LOCK SpinLock
> );
>
>
> So, one parameter. On entry to this function, ECX contains the spin
> lock. Since you have two routines here, you will either see the SAME
> value in
each
> CPUs ECX register (again, on entry to the function - the ECX register
could
> be re-used later in the code, which means you’ll have to look through
> the disassembly of the calling function to figure out where the ECX
> value came
> from) or a DIFFERENT value.
>
> If you can get a dump of this system, I’d love to have it - it would
> be a tremendous example in my debug lab (a livelock dump!)
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: Primoz Beltram [mailto:xxxxx@hermes.si]
> Sent: Thursday, July 18, 2002 10:29 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Frozen system
>
> Tony,
> Thank you for a quick replay and information.
> None of NDIS!* functions are 3rd party (mine or some others), but came
> on the system with regular MSDN W2K installation CD-ROM, W2K-SP2 or
> W2K-SRP1.
>
> What kind of information could I get from ECX register value? I can
> “.thread 811b9640” and find its value. Primoz
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: Thursday, July 18, 2002 4:10 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Frozen system
>
>
> Primoz,
>
>
>
> You couldn’t have GIVEN a better example of a live-locked system.
>
>
>
> What has happened is that CPU 0 owns some lock (say spin lock “A”) and
> CPU
1
> owns a different lock (say spin lock “B”). CPU 0 is spinning to
> acquire spin lock “B” and CPU 1 is spinning to acquire spin lock “A”.
> They will never succeed.
>
>
>
> Unfortunately, KfAcquireSpinLock passes the spin lock address in a
register,
> so there’s no way (from the stack trace) to figure out what the two
> spin locks are (although from the systems you should be able to figure
> out what these spin locks are, since they will be in the ECX register
> on entry to
> KfAcquireSpinLock.)
>
>
>
> Deadlocks are resolved by adhering to a locking hierarchy (to prevent
> any cycles in lock acquisition). WHAT that hierarchy is in this case,
> I
cannot
> say. Are the functions ndisMapOpenByName and ndisReferenceRef yours?
> If so, you need to examine the locking they are performing very
> carefully, because it is these two functions that seem to be
> implicated in this.
>
>
>
> Another possibility to consider is that this involves only a SINGLE
> spin lock, but that a reacquisition of that spin lock occurs in the
> code.
>
>
>
> Finally, you might wish to try using a checked kernel and hal
> combination because the checked kernel/hal actually have additional
> logic validation
for
> the use of spin locks.
>
>
>
> Regards,
>
>
>
> Tony
>
>
>
> Tony Mason
>
> Consulting Partner
>
> OSR Open Systems Resources, Inc.
>
> http: http://www.osr.com
>
>
>
> Hope to see you at the next OSR file systems class in San Jose, CA
September
> 16, 2002!
>
> -----Original Message-----
> From: Primoz Beltram [mailto:xxxxx@hermes.si]
> Sent: Thursday, July 18, 2002 9:53 AM
> To: NT Developers Interest List
> Subject: [ntdev] Frozen system
>
>
>
> I need some help. For about one week I’m dealing with a problem, that
> manifest itself as a “frozen system”. The “frozen system” doesn’t
> respond
on
> any external event (mouse, keyboard, network, …). Since I run the
> system in debug mode, I’m able to break-in with WinDbg. To reproduce
> the problem
I
> load the system with disk I/O (file/directory creation). Each time I
> hit this “frozen system” problem, I find only 2 threads in RUNNING
> state
(system
> has 2 CPUs), with the call stack as below in in this e-mail. All other
> threads are in WAIT state. These 2 threads are also always in the
> context
of
> SERVICES.EXE process.
>
> The description of system is: W2K-SP2 (running with enabled debug),
2xCPUs,
> 512MB RAM, with standard HW (network, CD-ROM, disk).
>
> Is the call stack below descriptive enough to explain the “frozen”
> state? Both CPUs in acquiring spin lock and the IRQL high enough to
> mask other IRQs?
>
> Thank you in advance for any feedback.
> Primoz
>
>
>
> THREAD 811b9640 Cid e4.288 Teb: 7ffde000 Win32Thread:
> 00000000 RUNNING
> IRP List:
> 81cd7a48: (0006,0094) Flags: 00000030 Mdl: 00000000
> Not impersonating
> Owning Process ae131d78
> WaitTime (seconds) 465339
> Context Switch Count 272
> UserTime 0:00:00.0000
> KernelTime 0:18:07.0359
> Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
> Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
> Stack Init f780d000 Current f780cbe8 Base f780d000 Limit
> f780a000 Call 0
> Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount
> 0
>
> ChildEBP RetAddr Args to Child
> f780cb18 bfeb6516 00000000 00000000 8042d1ce
> nt!KefAcquireSpinLockAtDpcLevel+0x8
> f780cb3c bfeb95c0 00000000 00000000 81ada0e8
> NDIS!ndisMapOpenByName+0x5e
> f780cbc0 bfeb93d0 81ada0d8 81ada0e0 81ada15c
> NDIS!ndisHandleProtocolReconfigNotification+0x69
> f780cbdc bfeb9354 81cd7ab8 81cd7a48 00000000
> NDIS!ndisHandleUModePnPOp+0x6d
> f780cbf8 bfeb918c a59aff20 81cd7a48 f780cc34
> NDIS!ndisHandlePnPRequest+0x13a
> f780cc0c 8041d915 a59aff20 81cd7a48 81cd7a48
> NDIS!ndisDispatchRequest+0x56
> f780cc20 804b0512 81ada1cf 00000000 81cd7a48
nt!IopfCallDriver+0x35
> f780cc34 804b1333 a59aff20 81cd7a48 a950df90
> nt!IopSynchronousServiceTail+0x60
> f780cd00 804a921e 000009a8 00000000 00000000
> nt!IopXxxControlFile+0x5ab
> f780cd34 80465679 000009a8 00000000 00000000
> nt!NtDeviceIoControlFile+0x28
> f780cd34 77f830a5 000009a8 00000000 00000000
nt!KiSystemService+0xc9
>
> 01f0faec 77e96fa1 000009a8 00000000 00000000
> ntdll!ZwDeviceIoControlFile+0xb
> 01f0fb50 77366478 000009a8 00170008 0008bbe8
> KERNEL32!CreateProcessW+0x41
> 01f0fb90 773662bb 00000001 00000003 01f0fe4c
> dhcpcsvc!NdisHandlePnPEvent+0x1c5
> 01f0fe60 773661f3 000e4c20 00000000 00000077
> dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
> 01f0fe78 7736595e 000e4a20 0188a8c0 000e4a20
> dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
> 01f0fe94 77364f04 000e4a20 01f0ff48 00000000
> dhcpcsvc!DhcpSetAllStackParameters+0x94
> 01f0fec8 77363c8c 3d3685a0 01f0ff48 0188a8c0
> dhcpcsvc!SetDhcpConfigurationForNIC+0x244
> 01f0ff2c 773638e8 00000004 01f0ff48 00000000
> dhcpcsvc!RenewLease+0x1e1
> 01f0ffa0 77363865 000e4a20 00000000 77d49f00
> dhcpcsvc!ReRenewParameters+0x58
> 01f0ffb4 77e96523 000ee1b8 77d49f00 77f82207
> dhcpcsvc!DhcpRenewThread+0x4d
> 01f0ffec 00000000 7736381e 000ee1b8 00000000
> KERNEL32!MakeLocHashNode+0x66
>
> THREAD 811a7a20 Cid e4.440 Teb: 7ffd5000 Win32Thread:
> 00000000 RUNNING
> IRP List:
> 81cb8b08: (0006,0094) Flags: 00000030 Mdl: 00000000
> Not impersonating
> Owning Process ae131d78
> WaitTime (seconds) 465339
> Context Switch Count 238
> UserTime 0:00:00.0000
> KernelTime 0:18:07.0343
> Start Address KERNEL32!GetLocaleFileInfo (0x77e964cb)
> Win32 Start Address dhcpcsvc!DhcpRenewThread (0x7736381e)
> Stack Init f79df000 Current f79dec44 Base f79df000 Limit
> f79dc000 Call 0
> Priority 10 BasePriority 9 PriorityDecrement 0 DecrementCount
> 0
>
> ChildEBP RetAddr Args to Child
> f79dea84 80469526 00000001 80448c02 000000d1
> nt!RtlpBreakWithStatusInstruction
> f79dea84 8006543c 00000001 80448c02 000000d1
> nt!KeUpdateSystemTime+0x14e
> f79deb08 bfeb7883 81a06132 bd839f30 bfebc0e7
> hal!KfAcquireSpinLock+0x2c
> f79deb14 bfebc0e7 8158fd08 00000000 00000000
> NDIS!ndisReferenceRef+0xc
> f79deb40 bfeb9577 00000000 8158fd08 00000000
> NDIS!ndisReferenceProtocolByName+0xce
> f79debc0 bfeb93d0 8158fcf8 8158fd00 8158fd7c
> NDIS!ndisHandleProtocolReconfigNotification+0x20
> f79debdc bfeb9354 81cb8b78 81cb8b08 00000000
> NDIS!ndisHandleUModePnPOp+0x6d
> f79debf8 bfeb918c a59aff20 81cb8b08 f79dec34
> NDIS!ndisHandlePnPRequest+0x13a
> f79dec0c 8041d915 a59aff20 81cb8b08 81cb8b08
> NDIS!ndisDispatchRequest+0x56
> f79dec20 804b0512 8158fdef 00000000 81cb8b08
nt!IopfCallDriver+0x35
> f79dec34 804b1333 a59aff20 81cb8b08 8175a808
> nt!IopSynchronousServiceTail+0x60
> f79ded00 804a921e 000009b8 00000000 00000000
> nt!IopXxxControlFile+0x5ab
> f79ded34 80465679 000009b8 00000000 00000000
> nt!NtDeviceIoControlFile+0x28
> f79ded34 77f830a5 000009b8 00000000 00000000
nt!KiSystemService+0xc9
>
> 01f4faec 77e96fa1 000009b8 00000000 00000000
> ntdll!ZwDeviceIoControlFile+0xb
> 01f4fb50 77366478 000009b8 00170008 0008b900
> KERNEL32!CreateProcessW+0x41
> 01f4fb90 773662bb 00000001 00000003 01f4fe4c
> dhcpcsvc!NdisHandlePnPEvent+0x1c5
> 01f4fe60 773661f3 000e7000 00000000 00000077
> dhcpcsvc!TcpIpNotifyRouterDiscoveryOption+0x9c
> 01f4fe78 7736595e 000e6e00 01a4a8c0 000e6e00
> dhcpcsvc!DhcpSetRouterDiscoverOption+0x28
> 01f4fe94 77364f04 000e6e00 01f4ff48 00000000
> dhcpcsvc!DhcpSetAllStackParameters+0x94
> 01f4fec8 77363c8c 3d36859e 01f4ff48 01a4a8c0
> dhcpcsvc!SetDhcpConfigurationForNIC+0x244
> 01f4ff2c 773638e8 00000005 01f4ff48 00000000
> dhcpcsvc!RenewLease+0x1e1
> 01f4ffa0 77363865 000e6e00 00000000 77d49f00
> dhcpcsvc!ReRenewParameters+0x58
> 01f4ffb4 77e96523 000d9510 77d49f00 77f82207
> dhcpcsvc!DhcpRenewThread+0x4d
> 01f4ffec 00000000 7736381e 000d9510 00000000
> KERNEL32!MakeLocHashNode+0x66
>
> —
> You are currently subscribed to ntdev as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hermes.si To
> unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro To
> unsubscribe send a blank email to %%email.unsub%%
>

—
You are currently subscribed to ntdev as: xxxxx@hermes.si To
unsubscribe send a blank email to %%email.unsub%%</http:>