CmpRegistryLock deadlock

Hi all,

We are using the OSR FDDK to monitor file access (create, read, write,
etc). One of the things we want to do is to change the start mode of our
driver based on some external factors. Each time I try to modify the
registry value that controls the start mode of my driver
(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services<driver>\Start) I
end up with the deadlock shown below.

Is writing to the registry while monitoring file access just a problem
in general because of the lazy writer flushing the registry hives?

Thanks,

Paul Judson

Resource @ nt!CmpRegistryLock (0x808a6940) Shared 2 owning threads
Contention Count = 2
Threads: 82470208-01<>

THREAD 82470208 Cid 0004.0e9c Teb: 00000000 Win32Thread: 00000000
WAIT: (Unknown) KernelMode Non-Alertable
fdacd0b8 SynchronizationEvent
IRP List:
ec394e00: (0006,01fc) Flags: 40000834 Mdl: 00000000
Not impersonating
DeviceMap e1000170
Owning Process 8259b818 Image: System
Wait Start TickCount 175907 Ticks: 759
(0:00:00:11.859)
Context Switch Count 3
UserTime 00:00:00.0000
KernelTime 00:00:00.0015
Start Address cgwfunc!ChangeDriverStartMode (0xf2b3e900)
Stack Init f2d6d000 Current f2d6c8e0 Base f2d6d000 Limit f2d6a000
Call 0
Priority 8 BasePriority 8 PriorityDecrement 0
ChildEBP RetAddr
f2d6c8f8 80820128 nt!KiSwapContext+0x25 (FPO: [EBP 0xf2d6c910]
[0,0,4])
f2d6c910 8081f9de nt!KiSwapThread+0x83 (FPO: [Non-Fpo])
f2d6c954 8094310d nt!KeWaitForSingleObject+0x2e0 (FPO: [Non-Fpo])
f2d6c9f0 8082337b nt!NtSetInformationFile+0x73b (FPO: [Non-Fpo])
f2d6c9f0 80822399 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @
f2d6ca0c)
f2d6ca7c 8091ffe5 nt!ZwSetInformationFile+0x11 (FPO: [5,0,0])
f2d6cabc 8092fa90 nt!CmpDoFileSetSize+0x5e (FPO: [Non-Fpo])
f2d6cad4 8092faf0 nt!CmpFileSetSize+0x16 (FPO: [Non-Fpo])
f2d6caf4 8092fb13 nt!HvpGrowLog1+0x52 (FPO: [Non-Fpo])
f2d6cb18 8091cd7d nt!HvMarkDirty+0x453 (FPO: [Non-Fpo])
f2d6cb40 8091ddda nt!HvMarkCellDirty+0x255 (FPO: [Non-Fpo])
f2d6cbb4 8092c886 nt!CmSetValueKey+0x390 (FPO: [Non-Fpo])
f2d6cc44 8082337b nt!NtSetValueKey+0x241 (FPO: [Non-Fpo])
f2d6cc44 80822565 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @
f2d6cc64)
f2d6ccd4 809db7e0 nt!ZwSetValueKey+0x11 (FPO: [6,0,0])
f2d6cd1c f2b411a4 nt!VfZwSetValueKey+0x9a (FPO: [Non-Fpo])
f2d6cd48 f2b3e99a cgwfunc!CgwKernel::RegKey::SetDword+0x34 (FPO:
[Non-Fpo]) (CONV: thiscall)
f2d6cdac 80905d2c cgwfunc!ChangeDriverStartMode+0x9a (FPO:
[Non-Fpo]) (CONV: stdcall)
f2d6cddc 80828499 nt!PspSystemThreadStartup+0x2e (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

82597b40-01<
>

THREAD 82597b40 Cid 0004.0050 Teb: 00000000 Win32Thread: 00000000
GATEWAIT
Not impersonating
DeviceMap e1000170
Owning Process 8259b818 Image: System
Wait Start TickCount 176178 Ticks: 488
(0:00:00:07.625)
Context Switch Count 27905
UserTime 00:00:00.0000
KernelTime 00:00:02.0734
Start Address nt!ExpWorkerThread (0x80820300)
Stack Init f88ab000 Current f88aac7c Base f88ab000 Limit f88a8000
Call 0
Priority 12 BasePriority 12 PriorityDecrement 0
ChildEBP RetAddr
f88aac94 80820128 nt!KiSwapContext+0x25 (FPO: [EBP 0xf88aacac]
[0,0,4])
f88aacac 80848cfe nt!KiSwapThread+0x83 (FPO: [Non-Fpo])
f88aacd4 8081a9fc nt!KeWaitForGate+0xe2 (FPO: [Non-Fpo])
f88aad30 80939776 nt!ExfAcquirePushLockExclusive+0xea (FPO:
[Non-Fpo])
f88aad58 80921c99 nt!CmpDoFlushNextHive+0xba (FPO: [Non-Fpo])
f88aad80 808203bd nt!CmpLazyFlushWorker+0x7f (FPO: [Non-Fpo])
f88aadac 80905d2c nt!ExpWorkerThread+0xeb (FPO: [Non-Fpo])
f88aaddc 80828499 nt!PspSystemThreadStartup+0x2e (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

Exactly. By calling the registry modification routines in a path that
might be invoked as a result of writing to the registry files you’ve
introduced an unexpected reentrancy for which the locking is just not
going to work property (push locks, in particular, are non-reentrant
reader/writer locks.)

If you want to do this, why not decouple the registry modification from
the registry write? In other words, why not post the registry
modification to a worker thread (or service queue or some other
asynchronous mechanism) and allow the original registry write to
proceed?

Of course, this all begs the question of whether or not modifying the
registry in this way is a good idea in the first place.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Paul Judson
Sent: Tuesday, May 30, 2006 5:20 PM
To: ntfsd redirect
Subject: [ntfsd] CmpRegistryLock deadlock

Hi all,

We are using the OSR FDDK to monitor file access (create, read, write,
etc). One of the things we want to do is to change the start mode of our
driver based on some external factors. Each time I try to modify the
registry value that controls the start mode of my driver
(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services<driver>\Start) I
end up with the deadlock shown below.

Is writing to the registry while monitoring file access just a problem
in general because of the lazy writer flushing the registry hives?

Thanks,

Paul Judson

Resource @ nt!CmpRegistryLock (0x808a6940) Shared 2 owning threads

Contention Count = 2

Threads: 82470208-01<>

THREAD 82470208 Cid 0004.0e9c Teb: 00000000 Win32Thread: 00000000
WAIT: (Unknown) KernelMode Non-Alertable

fdacd0b8 SynchronizationEvent

IRP List:

ec394e00: (0006,01fc) Flags: 40000834 Mdl: 00000000

Not impersonating

DeviceMap e1000170

Owning Process 8259b818 Image: System

Wait Start TickCount 175907 Ticks: 759
(0:00:00:11.859)

Context Switch Count 3

UserTime 00:00:00.0000

KernelTime 00:00:00.0015

Start Address cgwfunc!ChangeDriverStartMode (0xf2b3e900)

Stack Init f2d6d000 Current f2d6c8e0 Base f2d6d000 Limit f2d6a000
Call 0

Priority 8 BasePriority 8 PriorityDecrement 0

ChildEBP RetAddr

f2d6c8f8 80820128 nt!KiSwapContext+0x25 (FPO: [EBP 0xf2d6c910]
[0,0,4])

f2d6c910 8081f9de nt!KiSwapThread+0x83 (FPO: [Non-Fpo])

f2d6c954 8094310d nt!KeWaitForSingleObject+0x2e0 (FPO: [Non-Fpo])

f2d6c9f0 8082337b nt!NtSetInformationFile+0x73b (FPO: [Non-Fpo])

f2d6c9f0 80822399 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @
f2d6ca0c)

f2d6ca7c 8091ffe5 nt!ZwSetInformationFile+0x11 (FPO: [5,0,0])

f2d6cabc 8092fa90 nt!CmpDoFileSetSize+0x5e (FPO: [Non-Fpo])

f2d6cad4 8092faf0 nt!CmpFileSetSize+0x16 (FPO: [Non-Fpo])

f2d6caf4 8092fb13 nt!HvpGrowLog1+0x52 (FPO: [Non-Fpo])

f2d6cb18 8091cd7d nt!HvMarkDirty+0x453 (FPO: [Non-Fpo])

f2d6cb40 8091ddda nt!HvMarkCellDirty+0x255 (FPO: [Non-Fpo])

f2d6cbb4 8092c886 nt!CmSetValueKey+0x390 (FPO: [Non-Fpo])

f2d6cc44 8082337b nt!NtSetValueKey+0x241 (FPO: [Non-Fpo])

f2d6cc44 80822565 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @
f2d6cc64)

f2d6ccd4 809db7e0 nt!ZwSetValueKey+0x11 (FPO: [6,0,0])

f2d6cd1c f2b411a4 nt!VfZwSetValueKey+0x9a (FPO: [Non-Fpo])

f2d6cd48 f2b3e99a cgwfunc!CgwKernel::RegKey::SetDword+0x34 (FPO:
[Non-Fpo]) (CONV: thiscall)

f2d6cdac 80905d2c cgwfunc!ChangeDriverStartMode+0x9a (FPO:
[Non-Fpo]) (CONV: stdcall)

f2d6cddc 80828499 nt!PspSystemThreadStartup+0x2e (FPO: [Non-Fpo])

00000000 00000000 nt!KiThreadStartup+0x16

82597b40-01<
>

THREAD 82597b40 Cid 0004.0050 Teb: 00000000 Win32Thread: 00000000
GATEWAIT

Not impersonating

DeviceMap e1000170

Owning Process 8259b818 Image: System

Wait Start TickCount 176178 Ticks: 488
(0:00:00:07.625)

Context Switch Count 27905

UserTime 00:00:00.0000

KernelTime 00:00:02.0734

Start Address nt!ExpWorkerThread (0x80820300)

Stack Init f88ab000 Current f88aac7c Base f88ab000 Limit f88a8000
Call 0

Priority 12 BasePriority 12 PriorityDecrement 0

ChildEBP RetAddr

f88aac94 80820128 nt!KiSwapContext+0x25 (FPO: [EBP 0xf88aacac]
[0,0,4])

f88aacac 80848cfe nt!KiSwapThread+0x83 (FPO: [Non-Fpo])

f88aacd4 8081a9fc nt!KeWaitForGate+0xe2 (FPO: [Non-Fpo])

f88aad30 80939776 nt!ExfAcquirePushLockExclusive+0xea (FPO:
[Non-Fpo])

f88aad58 80921c99 nt!CmpDoFlushNextHive+0xba (FPO: [Non-Fpo])

f88aad80 808203bd nt!CmpLazyFlushWorker+0x7f (FPO: [Non-Fpo])

f88aadac 80905d2c nt!ExpWorkerThread+0xeb (FPO: [Non-Fpo])

f88aaddc 80828499 nt!PspSystemThreadStartup+0x2e (FPO: [Non-Fpo])

00000000 00000000 nt!KiThreadStartup+0x16


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com