I’ve never used the interface but…
The wait is executed on a kevent buried in a fast_mutex in the CM callback
structure allocated from paged pool. Unless pageable objects are waitable,
and I do not believe that they are, this would appear to be a bug.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Douglas G. Hanley
Sent: Wednesday, July 21, 2004 5:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Suspect Configuration Manager code?
Ah, the hubris that a glass of wine brings out in one. I am using
the new Configuration Manager (CM) callback interface that is included in
recent DDKs but, as yet, not officially documented/supported by Microsoft.
When running with forced IRQL checking via driver verifier I am seeing some
interesting crashes. In particular, it looks like the new code that
administrates the callback mechanism can end up placing a dispatcher object
(KEVENT) in paged memory and ruining my party. Firstly, is anybody else
using this interface in anger and can they comment on the reliability of it?
Secondly, surely some Microsoft CM devs have the odd squint at this forum -
please contribute. Now for the detail. Here is the stack trace of my
IRQL_NOT_LESS_OR_EQUAL crash;
STACK_TEXT:
be474c28 e0b25f32 e193df64 00000000 00000000
nt!KeWaitForSingleObject+0xdb
be474c48 e0c7c5a2 e20c91a8 e193df48 00000000
hal!ExAcquireFastMutex+0x32
be474c58 e0c7c62e e193df48 be474c74 e21d2ea0
nt!CmpCheckRecursionAndRecordThreadInfo+0x12
be474c88 e0c55954 0000000e be474cb8 00000000
nt!CmpCallCallBacks+0x3e
be474cb0 e0bf294a e21d2ea0 00000000 e21d2e88
nt!CmpDeleteKeyObject+0x38
be474cd0 e0b5deb8 e21d2ea0 00000000 00000cc8
nt!ObpRemoveObjectRoutine+0xe3
be474cec e0bf2c3e e14d5b70 f89d2d88 f8797cf0
nt!ObfDereferenceObject+0x4b
be474d04 e0bf2cb4 e14d5b70 e21d2ea0 00000cc8
nt!ObpCloseHandleTableEntry+0x137
be474d4c e0bf2d17 00000cc8 00000001 e0b4bd24 nt!ObpCloseHandle+0x80
be474d58 e0b4bd24 00000cc8 00000000 00000000 nt!NtClose+0x17
be474d58 7ffe0304 00000cc8 00000000 00000000 nt!KiSystemService+0xd0
0f8bf854 77f42397 77da2ddc 00000cc8 00000cc8
SharedUserData!SystemCallStub+0x4
0f8bf858 77da2ddc 00000cc8 00000cc8 0f8bf890 ntdll!ZwClose+0xc
0f8bf868 77da2d8d 0f8bf878 6d229713 00000cc8
ADVAPI32!BaseRegCloseKeyInternal+0x4f
0f8bf870 6d229713 00000cc8 00f4f26e 0df9ebf4
ADVAPI32!RegCloseKey+0x75
WARNING: Stack unwind information not available. Following frames
may be wrong.
0f8bf890 00f4e750 00000cc8 02ec3d60 02ec3ce8
java!Java_java_util_prefs_WindowsPreferences_WindowsRegCloseKey+0xa
0f8bf8e0 00f45060 00000cc8 0343b7f8 00000cc8 0xf4e750
.
.
.
0f8bffb8 77e4a990 0be10388 00000000 00000000
msvcrt!_endthreadex+0x95
0f8bffec 00000000 77bc917e 0be10388 00000000
kernel32!BaseThreadStart+0x34
WinDbg says that the memory (read) referenced that caused the
bugcheck is 0xe193df64. This is the argument to KeWaitForSingleObject()…
3: kd> !pool e193df64
Pool page e193df64 region is Paged pool
e193d000 size: 330 previous size: 0 (Allocated) Ntff
.
.
.
e193df38 size: 8 previous size: 30 (Free) Port
*e193df40 size: 40 previous size: 8 (Allocated) *CMcb
Pooltag CMcb : Internal Configuration manager allocations, Binary
: nt!cm
e193df80 size: 80 previous size: 40 (Allocated) CMDa
…so whatever it is, it is in a block of paged pool with a tag of
“CMcb” (and it is valid memory). Considering we are at IRQL SYNCH_LEVEL,
having just acquired the dispatcher database lock, not a good idea. The tag
“CMcb” sounds just like the kind of tag I would use for my callback admin
data structure. Are there many of these things? Poolfind tells me this is
the single instance on the whole system. I would suspect my code is the
single entity making use of this facility on the system. So, what is the
dispatcher object? It looks like a KEVENT to me…
3: kd> dt -b nt!_KEVENT e193df64
+0x000 Header :
+0x000 Type : 0x1 ‘’
+0x001 Absolute : 0 ‘’
+0x002 Size : 0x4 ‘’
+0x003 Inserted : 0 ‘’
+0x003 DebugActive : 0 ‘’
+0x000 Lock : 262145
+0x004 SignalState : 0
+0x008 WaitListHead : [0xe193df6c - 0xe193df6c]
+0x000 Flink : 0xe193df6c
+0x004 Blink : 0xe193df6c
All that client code supplies to the CB interface is a callback
address, a context pointer and the address of a LARGE_INTEGER into which it
places cookie info. My point is that the interface is pretty opaque and it
seems very unlikely that my input could influence the content of a CMcb
block. My hypothesis then is that the CM is erroneously putting its
dispatcher object into paged pool and causing the crash.
Somebody tell me where I have gone off the tracks so that I can get
on with falling on my own sword. Thanks,
Douglas.
Douglas G. Hanley
Senior Developer
The Neverfail Group
t: +44 (0)870 770 0234
f: +44 (0)870 770 0235
m: +44 (0)790 666 0965
e: xxxxx@neverfailgroup.com
mailto:xxxxx
w: http://www.neverfailgroup.com
http:</http:>
Protected by Neverfail for Exchange
http:</http:>
_________________________________________________________________
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@hollistech.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx>