A question for Doron Holan,
Can you tell me whether the bug I described below is likely to exist in XP
as well? Thanks very much,
Douglas.
--------------8<-------------
Message 4 in thread
Subject: RE: Suspect Configuration Manager code?
From: “Doron Holan” mailto:xxxxx >
Date: Wed, 21 Jul 2004 16:56:44 -0700
The CM owner says this will be fixed in Server SP1
d
________________________________________
From: xxxxx@lists.osr.com mailto:xxxxx
[mailto:xxxxx@lists.osr.com] On Behalf Of Douglas G.
Hanley
Sent: Wednesday, July 21, 2004 2: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:
_________________________________________________________________
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.</http:></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>