nt!CmpRegistryLock In definate Lock Contention

NTDEV
1

Hi All;
I have run into the following situation.

  1. At some stage of my code i REQUEUE the Work Items on the Workqueue.
    (i.ei cannot process them now).
  2. To start the workq functionality i need to Write some Registry value, i
    use nt!RtlWriteRegistry which gets into a non-alertable kernel mode sleep
    and is NEVER woken up.

(PASSIVE)
f8087840 804dc6a6 818ce898 818ce828 804dc6f2 nt!KiSwapContext+0x2e
f808784c 804dc6f2 00000000 80557860 818ce828 nt!KiSwapThread+0x46
f8087874 8051793b 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1c2
f80878b0 804e4e2e 00000200 e1d967a0 f808792c nt!ExpWaitForResource+0xd2
f80878c0 80578c30 80557860 00000001 8057540f nt!ExAcquireResourceExclusiveLi
te+0x6f
f80878cc 8057540f e1d55cd0 00000000 00000004
nt!CmpLockRegistryExclusive+0x18
f808792c 8057561b e1d967a0 f8087984 00000004 nt!CmSetValueKey+0x72
f80879c0 804df06b 800004fc f8087a74 00000000 nt!NtSetValueKey+0x228
f80879c0 804de239 800004fc f8087a74 00000000 nt!KiFastCallEntry+0xf8
f8087a50 805b4c8a 800004fc f8087a74 00000000 nt!ZwSetValueKey+0x11
f8087a7c f9a6bebd 40000000 800004fc f9a6bcf8 nt!RtlWriteRegistryValue+0x40

  1. Is there some relation between me REQUEING the workitems again and again
    and the lock contention.

Below is lock analysis for the give lock. why are not the given two threads
releasing the lock.

Thanks and Regards
Faraz Ahmed. aa

kd> !locks -v 0x80557860

Resource @ nt!CmpRegistryLock (0x80557860) Shared 2 owning threads
Contention Count = 54
NumberOfExclusiveWaiters = 7
Threads: 81bca640-01<*>

THREAD 81bca640 Cid 0004.0034 Teb: 00000000 Win32Thread: 00000000
WAIT: (Executive) KernelMode Non-Alertable
f9e9a73c NotificationEvent
IRP List:
81baadd8: (0006,0094) Flags: 00000000 Mdl: 00000000
Not impersonating
DeviceMap e1006008
Owning Process 81bcc830 Image: System
Wait Start TickCount 9972 Ticks: 156 (0:00:00: 02.437)
Context Switch Count 1698
UserTime 00:00:00.0000
KernelTime 00:00:02.0812
Start Address nt!ExpWorkerThread (0x804e4729)
Stack Init f9e9b000 Current f9e9a4cc Base f9e9b000 Limit f9e98000 Call
0
Priority 14 BasePriority 12 PriorityDecrement 2 DecrementCount 16
ChildEBP RetAddr
f9e9a4e4 804dc6a6 nt!KiSwapContext+0x2e (FPO: [EBP 0xf9e9a518] [0,0,4])
f9e9a4f0 804dc6f2 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f9e9a518 f9890ea8 nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
f9e9a538 f9890db6 Ntfs!NtfsWaitSync+0x1c (FPO: [Non-Fpo])
f9e9a700 f98936fe Ntfs!NtfsNonCachedIo+0x30e (FPO: [Non-Fpo])
f9e9a7e0 f9892fbf Ntfs!NtfsCommonRead+0xbdd (FPO: [Non-Fpo])
f9e9a990 804e3d77 Ntfs!NtfsFsdRead+0x22d (FPO: [Non-Fpo])
f9e9a9a0 f9934459 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f9e9a9a8 804e3d77 sr!SrPassThrough+0x31 (FPO: [Non-Fpo])
f9e9a9b8 804fb168 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f9e9a9cc 804fb18f nt!IopPageReadInternal+0xf4 (FPO: [Non-Fpo])
f9e9a9ec 804fadf4 nt!IoPageRead+0x1b (FPO: [Non-Fpo])
f9e9aa60 804ec48a nt!MiDispatchFault+0x274 (FPO: [Non-Fpo])
f9e9aab0 804f842b nt!MmAccessFault+0x5bc (FPO: [Non-Fpo])
f9e9aaf0 804f0d5a nt!MmCheckCachedPageState+0x461 (FPO: [Non-Fpo])
f9e9ab38 804f0f3f nt!CcMapAndRead+0x94 (FPO: [Non-Fpo])
f9e9abcc 8057a780 nt!CcPinFileData+0x24a (FPO: [Non-Fpo])
f9e9ac40 8059a780 nt!CcPinRead+0xc4 (FPO: [Non-Fpo])
f9e9aca0 80596d24 nt!CmpFileWriteThroughCache+0x52 (FPO: [Non-Fpo])
f9e9ad28 80599b8b nt!HvpDoWriteHive+0x2b3 (FPO: [Non-Fpo])
f9e9ad40 80599f1e nt!HvSyncHive+0x88 (FPO: [Non-Fpo])
f9e9ad5c 80599e78 nt!CmpDoFlushAll+0x6c (FPO: [Non-Fpo])
f9e9ad74 804e47fe nt!CmpLazyFlushWorker+0x51 (FPO: [Non-Fpo])
f9e9adac 8057dfed nt!ExpWorkerThread+0x100 (FPO: [Non-Fpo])
f9e9addc 804fa477 nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

81acb5f8-01<*>

THREAD 81acb5f8 Cid 0734.0748 Teb: 7ffdd000 Win32Thread: 00000000
WAIT: (Executive) KernelMode Non-Alertable
8055794c SynchronizationEvent
Not impersonating
DeviceMap e1006008
Owning Process 8198d458 Image: wuauclt.exe
Wait Start TickCount 8047 Ticks: 2081 (0:00:00:32.515)
Context Switch Count 5
UserTime 00:00:00.0000
KernelTime 00:00:00.0046
Start Address 0x7c810867
Win32 Start Address 0x0040bad5
Stack Init f790a000 Current f7909b40 Base f790a000 Limit f7907000 Call
0
Priority 15 BasePriority 8 PriorityDecrement 7 DecrementCount 16
ChildEBP RetAddr
f7909b58 804dc6a6 nt!KiSwapContext+0x2e (FPO: [EBP 0xf7909b8c] [0,0,4])
f7909b64 804dc6f2 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f7909b8c 804db7ee nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
f7909ba8 80593cbd nt!ExAcquireFastMutexUnsafe+0x19 (FPO: [0,0,0])
f7909bc0 80593d4e nt!CmPrefetchHivePages+0x1c (FPO: [Non-Fpo])
f7909c48 8058e971 nt!CcPfPrefetchSections+0x2cc (FPO: [Non-Fpo])
f7909c88 8058e7ed nt!CcPfPrefetchScenario+0x7b (FPO: [Non-Fpo])
f7909d04 80589368 nt!CcPfBeginAppLaunch+0x158 (FPO: [Non-Fpo])
f7909d50 804fa477 nt!PspUserThreadStartup+0xeb (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

Threads Waiting On Exclusive Access:
81885770 818ce828 819d39c8 817ceda8
817c34d0 819edbe0 81a63020

1 total locks, 1 locks currently held

2

Offhand I’d say your worker thread is trying to acquire the lock for the
registry that is held by the originating thread that is waiting for your
worker thread to complete the registry writing task it is trying to
perform, and that is never going to work. It is not lock contention it
is deadlock by design.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Faraz Ahmed
Sent: Tuesday, March 14, 2006 2:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] nt!CmpRegistryLock In definate Lock Contention

Hi All;
I have run into the following situation.

  1. At some stage of my code i REQUEUE the Work Items on the Workqueue.
    (i.e i cannot process them now).
  2. To start the workq functionality i need to Write some Registry value,
    i use nt!RtlWriteRegistry which gets into a non-alertable kernel mode
    sleep and is NEVER woken up.

(PASSIVE)
f8087840 804dc6a6 818ce898 818ce828 804dc6f2 nt!KiSwapContext+0x2e
f808784c 804dc6f2 00000000 80557860 818ce828 nt!KiSwapThread+0x46
f8087874 8051793b 00000000 00000000 00000000
nt!KeWaitForSingleObject+0x1c2
f80878b0 804e4e2e 00000200 e1d967a0 f808792c nt!ExpWaitForResource+0xd2
f80878c0 80578c30 80557860 00000001 8057540f
nt!ExAcquireResourceExclusiveLi

te+0x6f
f80878cc 8057540f e1d55cd0 00000000 00000004
nt!CmpLockRegistryExclusive+0x18
f808792c 8057561b e1d967a0 f8087984 00000004 nt!CmSetValueKey+0x72
f80879c0 804df06b 800004fc f8087a74 00000000 nt!NtSetValueKey+0x228
f80879c0 804de239 800004fc f8087a74 00000000 nt!KiFastCallEntry+0xf8
f8087a50 805b4c8a 800004fc f8087a74 00000000 nt!ZwSetValueKey+0x11
f8087a7c f9a6bebd 40000000 800004fc f9a6bcf8
nt!RtlWriteRegistryValue+0x40

  1. Is there some relation between me REQUEING the workitems again and
    again and the lock contention.

Below is lock analysis for the give lock. why are not the given two
threads releasing the lock.

Thanks and Regards
Faraz Ahmed. aa

kd> !locks -v 0x80557860

Resource @ nt!CmpRegistryLock (0x80557860) Shared 2 owning threads
Contention Count = 54
NumberOfExclusiveWaiters = 7
Threads: 81bca640-01<*>

THREAD 81bca640 Cid 0004.0034 Teb: 00000000 Win32Thread: 00000000
WAIT: (Executive) KernelMode Non-Alertable
f9e9a73c NotificationEvent
IRP List:
81baadd8: (0006,0094) Flags: 00000000 Mdl: 00000000
Not impersonating
DeviceMap e1006008
Owning Process 81bcc830 Image: System
Wait Start TickCount 9972 Ticks: 156 (0:00:00:
02.437)
Context Switch Count 1698
UserTime 00:00:00.0000
KernelTime 00:00:02.0812
Start Address nt!ExpWorkerThread (0x804e4729)
Stack Init f9e9b000 Current f9e9a4cc Base f9e9b000 Limit f9e98000
Call 0
Priority 14 BasePriority 12 PriorityDecrement 2 DecrementCount 16
ChildEBP RetAddr
f9e9a4e4 804dc6a6 nt!KiSwapContext+0x2e (FPO: [EBP 0xf9e9a518]
[0,0,4])
f9e9a4f0 804dc6f2 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f9e9a518 f9890ea8 nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
f9e9a538 f9890db6 Ntfs!NtfsWaitSync+0x1c (FPO: [Non-Fpo])
f9e9a700 f98936fe Ntfs!NtfsNonCachedIo+0x30e (FPO: [Non-Fpo])
f9e9a7e0 f9892fbf Ntfs!NtfsCommonRead+0xbdd (FPO: [Non-Fpo])
f9e9a990 804e3d77 Ntfs!NtfsFsdRead+0x22d (FPO: [Non-Fpo])
f9e9a9a0 f9934459 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f9e9a9a8 804e3d77 sr!SrPassThrough+0x31 (FPO: [Non-Fpo])
f9e9a9b8 804fb168 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f9e9a9cc 804fb18f nt!IopPageReadInternal+0xf4 (FPO: [Non-Fpo])
f9e9a9ec 804fadf4 nt!IoPageRead+0x1b (FPO: [Non-Fpo])
f9e9aa60 804ec48a nt!MiDispatchFault+0x274 (FPO: [Non-Fpo])
f9e9aab0 804f842b nt!MmAccessFault+0x5bc (FPO: [Non-Fpo])
f9e9aaf0 804f0d5a nt!MmCheckCachedPageState+0x461 (FPO: [Non-Fpo])
f9e9ab38 804f0f3f nt!CcMapAndRead+0x94 (FPO: [Non-Fpo])
f9e9abcc 8057a780 nt!CcPinFileData+0x24a (FPO: [Non-Fpo])
f9e9ac40 8059a780 nt!CcPinRead+0xc4 (FPO: [Non-Fpo])
f9e9aca0 80596d24 nt!CmpFileWriteThroughCache+0x52 (FPO: [Non-Fpo])
f9e9ad28 80599b8b nt!HvpDoWriteHive+0x2b3 (FPO: [Non-Fpo])
f9e9ad40 80599f1e nt!HvSyncHive+0x88 (FPO: [Non-Fpo])
f9e9ad5c 80599e78 nt!CmpDoFlushAll+0x6c (FPO: [Non-Fpo])
f9e9ad74 804e47fe nt!CmpLazyFlushWorker+0x51 (FPO: [Non-Fpo])
f9e9adac 8057dfed nt!ExpWorkerThread+0x100 (FPO: [Non-Fpo])
f9e9addc 804fa477 nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

81acb5f8-01<*>

THREAD 81acb5f8 Cid 0734.0748 Teb: 7ffdd000 Win32Thread: 00000000
WAIT: (Executive) KernelMode Non-Alertable
8055794c SynchronizationEvent
Not impersonating
DeviceMap e1006008
Owning Process 8198d458 Image: wuauclt.exe
Wait Start TickCount 8047 Ticks: 2081
(0:00:00:32.515)
Context Switch Count 5
UserTime 00:00:00.0000
KernelTime 00:00:00.0046
Start Address 0x7c810867
Win32 Start Address 0x0040bad5
Stack Init f790a000 Current f7909b40 Base f790a000 Limit f7907000
Call 0
Priority 15 BasePriority 8 PriorityDecrement 7 DecrementCount 16
ChildEBP RetAddr
f7909b58 804dc6a6 nt!KiSwapContext+0x2e (FPO: [EBP 0xf7909b8c]
[0,0,4])
f7909b64 804dc6f2 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f7909b8c 804db7ee nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
f7909ba8 80593cbd nt!ExAcquireFastMutexUnsafe+0x19 (FPO: [0,0,0])
f7909bc0 80593d4e nt!CmPrefetchHivePages+0x1c (FPO: [Non-Fpo])
f7909c48 8058e971 nt!CcPfPrefetchSections+0x2cc (FPO: [Non-Fpo])
f7909c88 8058e7ed nt!CcPfPrefetchScenario+0x7b (FPO: [Non-Fpo])
f7909d04 80589368 nt!CcPfBeginAppLaunch+0x158 (FPO: [Non-Fpo])
f7909d50 804fa477 nt!PspUserThreadStartup+0xeb (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

Threads Waiting On Exclusive Access:
81885770 818ce828 819d39c8 817ceda8

817c34d0 819edbe0 81a63020

1 total locks, 1 locks currently held

— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

1st, stop multiposting or crossposting in OSR lists. Read the FAQ, item 13.
“Faraz Ahmed” wrote in message news:xxxxx@ntdev…
Hi All;
I have run into the following situation.

1. At some stage of my code i REQUEUE the Work Items on the Workqueue. (i.e i cannot process them now).
2. To start the workq functionality i need to Write some Registry value, i use nt!RtlWriteRegistry which gets into a non-alertable kernel mode sleep and is NEVER woken up.

(PASSIVE)
f8087840 804dc6a6 818ce898 818ce828 804dc6f2 nt!KiSwapContext+0x2e
f808784c 804dc6f2 00000000 80557860 818ce828 nt!KiSwapThread+0x46
f8087874 8051793b 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1c2
f80878b0 804e4e2e 00000200 e1d967a0 f808792c nt!ExpWaitForResource+0xd2
f80878c0 80578c30 80557860 00000001 8057540f nt!ExAcquireResourceExclusiveLi
te+0x6f
f80878cc 8057540f e1d55cd0 00000000 00000004 nt!CmpLockRegistryExclusive+0x18
f808792c 8057561b e1d967a0 f8087984 00000004 nt!CmSetValueKey+0x72
f80879c0 804df06b 800004fc f8087a74 00000000 nt!NtSetValueKey+0x228
f80879c0 804de239 800004fc f8087a74 00000000 nt!KiFastCallEntry+0xf8
f8087a50 805b4c8a 800004fc f8087a74 00000000 nt!ZwSetValueKey+0x11
f8087a7c f9a6bebd 40000000 800004fc f9a6bcf8 nt!RtlWriteRegistryValue+0x40

3. Is there some relation between me REQUEING the workitems again and again and the lock contention.

Below is lock analysis for the give lock. why are not the given two threads releasing the lock.

Thanks and Regards
Faraz Ahmed. aa

kd> !locks -v 0x80557860

Resource @ nt!CmpRegistryLock (0x80557860) Shared 2 owning threads
Contention Count = 54
NumberOfExclusiveWaiters = 7
Threads: 81bca640-01<>

THREAD 81bca640 Cid 0004.0034 Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
f9e9a73c NotificationEvent
IRP List:
81baadd8: (0006,0094) Flags: 00000000 Mdl: 00000000
Not impersonating
DeviceMap e1006008
Owning Process 81bcc830 Image: System
Wait Start TickCount 9972 Ticks: 156 (0:00:00: 02.437)
Context Switch Count 1698
UserTime 00:00:00.0000
KernelTime 00:00:02.0812
Start Address nt!ExpWorkerThread (0x804e4729)
Stack Init f9e9b000 Current f9e9a4cc Base f9e9b000 Limit f9e98000 Call 0
Priority 14 BasePriority 12 PriorityDecrement 2 DecrementCount 16
ChildEBP RetAddr
f9e9a4e4 804dc6a6 nt!KiSwapContext+0x2e (FPO: [EBP 0xf9e9a518] [0,0,4])
f9e9a4f0 804dc6f2 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f9e9a518 f9890ea8 nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
f9e9a538 f9890db6 Ntfs!NtfsWaitSync+0x1c (FPO: [Non-Fpo])
f9e9a700 f98936fe Ntfs!NtfsNonCachedIo+0x30e (FPO: [Non-Fpo])
f9e9a7e0 f9892fbf Ntfs!NtfsCommonRead+0xbdd (FPO: [Non-Fpo])
f9e9a990 804e3d77 Ntfs!NtfsFsdRead+0x22d (FPO: [Non-Fpo])
f9e9a9a0 f9934459 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f9e9a9a8 804e3d77 sr!SrPassThrough+0x31 (FPO: [Non-Fpo])
f9e9a9b8 804fb168 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f9e9a9cc 804fb18f nt!IopPageReadInternal+0xf4 (FPO: [Non-Fpo])
f9e9a9ec 804fadf4 nt!IoPageRead+0x1b (FPO: [Non-Fpo])
f9e9aa60 804ec48a nt!MiDispatchFault+0x274 (FPO: [Non-Fpo])
f9e9aab0 804f842b nt!MmAccessFault+0x5bc (FPO: [Non-Fpo])
f9e9aaf0 804f0d5a nt!MmCheckCachedPageState+0x461 (FPO: [Non-Fpo])
f9e9ab38 804f0f3f nt!CcMapAndRead+0x94 (FPO: [Non-Fpo])
f9e9abcc 8057a780 nt!CcPinFileData+0x24a (FPO: [Non-Fpo])
f9e9ac40 8059a780 nt!CcPinRead+0xc4 (FPO: [Non-Fpo])
f9e9aca0 80596d24 nt!CmpFileWriteThroughCache+0x52 (FPO: [Non-Fpo])
f9e9ad28 80599b8b nt!HvpDoWriteHive+0x2b3 (FPO: [Non-Fpo])
f9e9ad40 80599f1e nt!HvSyncHive+0x88 (FPO: [Non-Fpo])
f9e9ad5c 80599e78 nt!CmpDoFlushAll+0x6c (FPO: [Non-Fpo])
f9e9ad74 804e47fe nt!CmpLazyFlushWorker+0x51 (FPO: [Non-Fpo])
f9e9adac 8057dfed nt!ExpWorkerThread+0x100 (FPO: [Non-Fpo])
f9e9addc 804fa477 nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

81acb5f8-01<>

THREAD 81acb5f8 Cid 0734.0748 Teb: 7ffdd000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
8055794c SynchronizationEvent
Not impersonating
DeviceMap e1006008
Owning Process 8198d458 Image: wuauclt.exe
Wait Start TickCount 8047 Ticks: 2081 (0:00:00:32.515)
Context Switch Count 5
UserTime 00:00:00.0000
KernelTime 00:00:00.0046
Start Address 0x7c810867
Win32 Start Address 0x0040bad5
Stack Init f790a000 Current f7909b40 Base f790a000 Limit f7907000 Call 0
Priority 15 BasePriority 8 PriorityDecrement 7 DecrementCount 16
ChildEBP RetAddr
f7909b58 804dc6a6 nt!KiSwapContext+0x2e (FPO: [EBP 0xf7909b8c] [0,0,4])
f7909b64 804dc6f2 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f7909b8c 804db7ee nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
f7909ba8 80593cbd nt!ExAcquireFastMutexUnsafe+0x19 (FPO: [0,0,0])
f7909bc0 80593d4e nt!CmPrefetchHivePages+0x1c (FPO: [Non-Fpo])
f7909c48 8058e971 nt!CcPfPrefetchSections+0x2cc (FPO: [Non-Fpo])
f7909c88 8058e7ed nt!CcPfPrefetchScenario+0x7b (FPO: [Non-Fpo])
f7909d04 80589368 nt!CcPfBeginAppLaunch+0x158 (FPO: [Non-Fpo])
f7909d50 804fa477 nt!PspUserThreadStartup+0xeb (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

Threads Waiting On Exclusive Access:
81885770 818ce828 819d39c8 817ceda8
817c34d0 819edbe0 81a63020

1 total locks, 1 locks currently held

4

My general rule is that I don’t answer once I see that someone has
cross-posted because it indicates they either haven’t read the rules or
they have read them and have decided they don’t apply in their special
case. I’m not sure which one is worse.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006 (note new date - MS scheduled plugfest the
same week again.)

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Tuesday, March 14, 2006 2:58 PM
To: ntdev redirect
Subject: Re:[ntdev] nt!CmpRegistryLock In definate Lock Contention

1st, stop multiposting or crossposting in OSR lists. Read the FAQ, item
13.

“Faraz Ahmed” wrote in message
news:xxxxx@ntdev…

Hi All;
I have run into the following situation.

1. At some stage of my code i REQUEUE the Work Items on the
Workqueue. (i.e i cannot process them now).
2. To start the workq functionality i need to Write some
Registry value, i use nt!RtlWriteRegistry which gets into a
non-alertable kernel mode sleep and is NEVER woken up.

(PASSIVE)
f8087840 804dc6a6 818ce898 818ce828 804dc6f2
nt!KiSwapContext+0x2e
f808784c 804dc6f2 00000000 80557860 818ce828
nt!KiSwapThread+0x46
f8087874 8051793b 00000000 00000000 00000000
nt!KeWaitForSingleObject+0x1c2
f80878b0 804e4e2e 00000200 e1d967a0 f808792c
nt!ExpWaitForResource+0xd2
f80878c0 80578c30 80557860 00000001 8057540f
nt!ExAcquireResourceExclusiveLi

te+0x6f
f80878cc 8057540f e1d55cd0 00000000 00000004
nt!CmpLockRegistryExclusive+0x18
f808792c 8057561b e1d967a0 f8087984 00000004
nt!CmSetValueKey+0x72
f80879c0 804df06b 800004fc f8087a74 00000000
nt!NtSetValueKey+0x228
f80879c0 804de239 800004fc f8087a74 00000000
nt!KiFastCallEntry+0xf8
f8087a50 805b4c8a 800004fc f8087a74 00000000
nt!ZwSetValueKey+0x11
f8087a7c f9a6bebd 40000000 800004fc f9a6bcf8
nt!RtlWriteRegistryValue+0x40

3. Is there some relation between me REQUEING the workitems
again and again and the lock contention.

Below is lock analysis for the give lock. why are not the given
two threads releasing the lock.

Thanks and Regards
Faraz Ahmed. aa

kd> !locks -v 0x80557860

Resource @ nt!CmpRegistryLock (0x80557860) Shared 2 owning
threads
Contention Count = 54
NumberOfExclusiveWaiters = 7
Threads: 81bca640-01<>

THREAD 81bca640 Cid 0004.0034 Teb: 00000000 Win32Thread:
00000000 WAIT: (Executive) KernelMode Non-Alertable
f9e9a73c NotificationEvent
IRP List:
81baadd8: (0006,0094) Flags: 00000000 Mdl: 00000000
Not impersonating
DeviceMap e1006008
Owning Process 81bcc830 Image:
System
Wait Start TickCount 9972 Ticks: 156
(0:00:00: 02.437)
Context Switch Count 1698
UserTime 00:00:00.0000
KernelTime 00:00:02.0812
Start Address nt!ExpWorkerThread (0x804e4729)
Stack Init f9e9b000 Current f9e9a4cc Base f9e9b000 Limit
f9e98000 Call 0
Priority 14 BasePriority 12 PriorityDecrement 2
DecrementCount 16
ChildEBP RetAddr
f9e9a4e4 804dc6a6 nt!KiSwapContext+0x2e (FPO: [EBP
0xf9e9a518] [0,0,4])
f9e9a4f0 804dc6f2 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f9e9a518 f9890ea8 nt!KeWaitForSingleObject+0x1c2 (FPO:
[Non-Fpo])
f9e9a538 f9890db6 Ntfs!NtfsWaitSync+0x1c (FPO: [Non-Fpo])
f9e9a700 f98936fe Ntfs!NtfsNonCachedIo+0x30e (FPO:
[Non-Fpo])
f9e9a7e0 f9892fbf Ntfs!NtfsCommonRead+0xbdd (FPO:
[Non-Fpo])
f9e9a990 804e3d77 Ntfs!NtfsFsdRead+0x22d (FPO: [Non-Fpo])
f9e9a9a0 f9934459 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f9e9a9a8 804e3d77 sr!SrPassThrough+0x31 (FPO: [Non-Fpo])
f9e9a9b8 804fb168 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
f9e9a9cc 804fb18f nt!IopPageReadInternal+0xf4 (FPO:
[Non-Fpo])
f9e9a9ec 804fadf4 nt!IoPageRead+0x1b (FPO: [Non-Fpo])
f9e9aa60 804ec48a nt!MiDispatchFault+0x274 (FPO: [Non-Fpo])
f9e9aab0 804f842b nt!MmAccessFault+0x5bc (FPO: [Non-Fpo])
f9e9aaf0 804f0d5a nt!MmCheckCachedPageState+0x461 (FPO:
[Non-Fpo])
f9e9ab38 804f0f3f nt!CcMapAndRead+0x94 (FPO: [Non-Fpo])
f9e9abcc 8057a780 nt!CcPinFileData+0x24a (FPO: [Non-Fpo])
f9e9ac40 8059a780 nt!CcPinRead+0xc4 (FPO: [Non-Fpo])
f9e9aca0 80596d24 nt!CmpFileWriteThroughCache+0x52 (FPO:
[Non-Fpo])
f9e9ad28 80599b8b nt!HvpDoWriteHive+0x2b3 (FPO: [Non-Fpo])
f9e9ad40 80599f1e nt!HvSyncHive+0x88 (FPO: [Non-Fpo])
f9e9ad5c 80599e78 nt!CmpDoFlushAll+0x6c (FPO: [Non-Fpo])
f9e9ad74 804e47fe nt!CmpLazyFlushWorker+0x51 (FPO:
[Non-Fpo])
f9e9adac 8057dfed nt!ExpWorkerThread+0x100 (FPO: [Non-Fpo])
f9e9addc 804fa477 nt!PspSystemThreadStartup+0x34 (FPO:
[Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

81acb5f8-01<>

THREAD 81acb5f8 Cid 0734.0748 Teb: 7ffdd000 Win32Thread:
00000000 WAIT: (Executive) KernelMode Non-Alertable
8055794c SynchronizationEvent
Not impersonating
DeviceMap e1006008
Owning Process 8198d458 Image:
wuauclt.exe
Wait Start TickCount 8047 Ticks: 2081
(0:00:00:32.515)
Context Switch Count 5
UserTime 00:00:00.0000
KernelTime 00:00:00.0046
Start Address 0x7c810867
Win32 Start Address 0x0040bad5
Stack Init f790a000 Current f7909b40 Base f790a000 Limit
f7907000 Call 0
Priority 15 BasePriority 8 PriorityDecrement 7
DecrementCount 16
ChildEBP RetAddr
f7909b58 804dc6a6 nt!KiSwapContext+0x2e (FPO: [EBP
0xf7909b8c] [0,0,4])
f7909b64 804dc6f2 nt!KiSwapThread+0x46 (FPO: [0,0,0])
f7909b8c 804db7ee nt!KeWaitForSingleObject+0x1c2 (FPO:
[Non-Fpo])
f7909ba8 80593cbd nt!ExAcquireFastMutexUnsafe+0x19 (FPO:
[0,0,0])
f7909bc0 80593d4e nt!CmPrefetchHivePages+0x1c (FPO:
[Non-Fpo])
f7909c48 8058e971 nt!CcPfPrefetchSections+0x2cc (FPO:
[Non-Fpo])
f7909c88 8058e7ed nt!CcPfPrefetchScenario+0x7b (FPO:
[Non-Fpo])
f7909d04 80589368 nt!CcPfBeginAppLaunch+0x158 (FPO:
[Non-Fpo])
f7909d50 804fa477 nt!PspUserThreadStartup+0xeb (FPO:
[Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

Threads Waiting On Exclusive Access:
81885770 818ce828 819d39c8
817ceda8
817c34d0 819edbe0 81a63020

1 total locks, 1 locks currently held

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer