Problem with WDF WMI support.

OSR_Community_User · August 8, 2007, 7:34am

I seem to have an interesting WMI problem / bug-ette.

I have multiple providers on multiple devices.
Some of those providers are “the same”.
If I have two identical providers on a different devices where at
least one of them does not expose any instances, then WMI clients get
very unhappy, typically throwing up various errors. If I require that
all providers have at least one instance registered then the problem
seems to go away.

Just wondering: has anyone seen this before? Is it by design? Is there a
workaround/fix?

MH.

Doron_Holan · August 8, 2007, 11:43am

There is a bug where if the instance count goes back down to zero (e.g.
you remove all the current instances) the provider is no longer
registered and disappears from the wmi namespace (assuming there are no
other devices which have instances, otherwise it remains). This is
fixed in v1.7. I have not seen an issue where you create a provider
with no instances though, what type of errors are you seeing in the
applications?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Wednesday, August 08, 2007 4:33 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Problem with WDF WMI support.

I seem to have an interesting WMI problem / bug-ette.

I have multiple providers on multiple devices.
Some of those providers are “the same”.
If I have two identical providers on a different devices where at
least one of them does not expose any instances, then WMI clients get
very unhappy, typically throwing up various errors. If I require that
all providers have at least one instance registered then the problem
seems to go away.

Just wondering: has anyone seen this before? Is it by design? Is there a

workaround/fix?

MH.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

OSR_Community_User · August 9, 2007, 7:09am

Doron Holan wrote:

There is a bug where if the instance count goes back down to zero (e.g.
you remove all the current instances) the provider is no longer
registered and disappears from the wmi namespace (assuming there are no
other devices which have instances, otherwise it remains). This is
fixed in v1.7.

OK. This is likely to be an issue for us.

I have not seen an issue where you create a provider
with no instances though, what type of errors are you seeing in the
applications?

OK, using CIM studio, and Powershell, I have seen two basic issues which
occur when there are two providers registered, and only one has
instances. One I call “half working”, and the other I call “not working”.

In the “half working” situation, Powershell tends to list those that
are exist, but then throws an error message. Graphical clients (CIM
studio) just tend to show a dialog box indicating that there are no
instances whatsoever.

I suspect this may be a client problem enumerating things off multiple
providers, and not handling the error cases right. This situation seems
to occur where the provider with no instances created is the “second”
that’s enumerated internally, some exception gets thrown and clients
that aren’t so smart throw away all the data.

Unfortunately neither of the clients give me a nice COM / WMI error code.

However, I’ve turned on WMI verbose logging. Here’s what I get:

WBEMCORE.LOG

(Thu Aug 09 12:04:08 2007.789109) : CALL ConnectionLogin::NTLMLogin
wszNetworkResource = \localhost\root\wmi
pPreferredLocale =
lFlags = 0x0
(Thu Aug 09 12:04:08 2007.789109) : DCOM connection from SWTEST\mch at
authentiction level Privacy, AuthnSvc = 10, AuthzSvc = 0, Capabilities = 0
(Thu Aug 09 12:04:08 2007.789109) : GetUserDefaultLCID failed,
restorting to system verion(Thu Aug 09 12:04:08 2007.789109) : CALL
CWbemNamespace::ExecQuery
BSTR QueryFormat = WQL
BSTR Query = select * from EFX_Root
IEnumWbemClassObject **pEnum = 0xDB820
(Thu Aug 09 12:04:08 2007.789109) : CALL CWbemNamespace::ExecQueryAsync
BSTR QueryFormat = WQL
BSTR Query = select * from EFX_Root
IWbemObjectSink* pHandler = 0x0
(Thu Aug 09 12:04:08 2007.789125) : STARTING a main queue thread 2760
for a total of 1
(Thu Aug 09 12:04:08 2007.789125) : CALL CWbemNamespace::GetObject
BSTR ObjectPath = EFX_Root
long lFlags = 0
IWbemClassObject ** pObj = 0x175FBC4
(Thu Aug 09 12:04:08 2007.789125) : CALL CWbemNamespace::GetObjectAsync
BSTR ObjectPath = EFX_Root
long lFlags = 0
IWbemObjectSink* pHandler = 0x0
(Thu Aug 09 12:04:08 2007.789125) : STARTING a main queue thread 2764
for a total of 2
(Thu Aug 09 12:04:08 2007.789125) : Query Engine request: querying dyn
provider with
(Thu Aug 09 12:04:08 2007.789125) : Query Engine actual: querying dyn
provider with
(Thu Aug 09 12:04:08 2007.789125) : CALL CWbemNamespace::GetObject
BSTR ObjectPath = EFX_Root
long lFlags = 0
IWbemClassObject pObj = 0x118F938
(Thu Aug 09 12:04:08 2007.789125) : CALL CWbemNamespace::GetObject
BSTR ObjectPath = __ExtendedStatus
long lFlags = 0
IWbemClassObject pObj = 0x118F938
(Thu Aug 09 12:04:08 2007.789125) : Error 8004100f occured executing
request for EFX_Root

WMIPROV.LOG

(Thu Aug 09 12:04:08 2007.789125) :
(Thu Aug 09 12:04:08 2007.789125) : Invalid Name Block
(Thu Aug 09 12:04:08 2007.789125) :
(Thu Aug 09 12:04:08 2007.789125) :

(Thu Aug 09 12:04:08 2007.789125) : Enable verbose logging for more
information
(Thu Aug 09 12:04:08 2007.789125) :

(Thu Aug 09 12:04:08 2007.789125) : WNODE_HEADER 0x34b00
(Thu Aug 09 12:04:08 2007.789125) : BufferSize…0x43
(Thu Aug 09 12:04:08 2007.789125) : ProviderId…0x8a230cc0
(Thu Aug 09 12:04:08 2007.789125) : Version…0x0
(Thu Aug 09 12:04:08 2007.789125) : TimeStamp:LowPart.0x225e97a
(Thu Aug 09 12:04:08 2007.789125) : TimeStamp:HiPart…0x1c7da75
(Thu Aug 09 12:04:08 2007.789125) : Guid…(Thu Aug 09
12:04:08 2007.789125) : {4CA65E60-3AC8-4A45-E445-AAC984F5F8EE}(Thu Aug
09 12:04:08 2007.789125) :
(Thu Aug 09 12:04:08 2007.789125) :
(Thu Aug 09 12:04:08 2007.789125) : Flags…0x10081
(Thu Aug 09 12:04:08 2007.789125) : ***********************************
(Thu Aug 09 12:04:08 2007.789125) : WNODE_ALL_DATA 0x34b00
(Thu Aug 09 12:04:08 2007.789125) : DataBlockOffset…40
(Thu Aug 09 12:04:08 2007.789125) : InstanceCount…0
(Thu Aug 09 12:04:08 2007.789125) : OffsetInstanceNameOffsets…40
(Thu Aug 09 12:04:08 2007.789125) : OffsetInstanceData…0
(Thu Aug 09 12:04:08 2007.789125) : LengthInstanceData…0
(Thu Aug 09 12:04:08 2007.789125) : Writing out buffer, total size to
write: 67
(Thu Aug 09 12:04:08 2007.789125) : 43 00 00 00 c0 0c 23 8a 00 00
(Thu Aug 09 12:04:08 2007.789125) : 00 00 00 00 00 00 7a e9 25 02
(Thu Aug 09 12:04:08 2007.789125) : 75 da c7 01 60 5e a6 4c c8 3a
(Thu Aug 09 12:04:08 2007.789125) : 45 4a e4 45 aa c9 84 f5 f8 ee
(Thu Aug 09 12:04:08 2007.789125) : 00 00 00 00 81 00 01 00 40 00
(Thu Aug 09 12:04:08 2007.789125) : 00 00 00 00 00 00 40 00 00 00
(Thu Aug 09 12:04:08 2007.789125) : 00 00 00 00 00 00 00 00 00 00
(Thu Aug 09 12:04:08 2007.789125) : WDM specific return code: 0
(Thu Aug 09 12:04:08 2007.789125) :

2. In the “not working” situation, the client seems to enumerate the
provider that has no instances whatsoever first. In this case,
Powershell shows up no errors, but lists nothing, and CIM studio again
shows a dialog box indicating that no instances exist. In this case,
removing the provider with no instances then “exposes” the other
provider so that you can see its instances.

WBEMCORE.LOG

(Thu Aug 09 12:05:53 2007.893890) : CALL ConnectionLogin::NTLMLogin
wszNetworkResource = \localhost\root\wmi
pPreferredLocale =
lFlags = 0x0
(Thu Aug 09 12:05:53 2007.893890) : DCOM connection from SWTEST\mch at
authentiction level Privacy, AuthnSvc = 10, AuthzSvc = 0, Capabilities = 0
(Thu Aug 09 12:05:53 2007.893890) : GetUserDefaultLCID failed,
restorting to system verion(Thu Aug 09 12:05:53 2007.893906) : CALL
CWbemNamespace::ExecQuery
BSTR QueryFormat = WQL
BSTR Query = select * from EFX_PortGroup
IEnumWbemClassObjectpEnum = 0xFF098
(Thu Aug 09 12:05:53 2007.893906) : CALL CWbemNamespace::ExecQueryAsync
BSTR QueryFormat = WQL
BSTR Query = select * from EFX_PortGroup
IWbemObjectSink pHandler = 0x0
(Thu Aug 09 12:05:53 2007.893906) : STARTING a main queue thread 2912
for a total of 1
(Thu Aug 09 12:05:53 2007.893906) : CALL CWbemNamespace::GetObject
BSTR ObjectPath = EFX_PortGroup
long lFlags = 0
IWbemClassObject pObj = 0x171FBC4
(Thu Aug 09 12:05:53 2007.893906) : CALL CWbemNamespace::GetObjectAsync
BSTR ObjectPath = EFX_PortGroup
long lFlags = 0
IWbemObjectSink pHandler = 0x0
(Thu Aug 09 12:05:53 2007.893906) : STARTING a main queue thread 2916
for a total of 2
(Thu Aug 09 12:05:53 2007.893906) : Query Engine request: querying dyn
provider with
(Thu Aug 09 12:05:53 2007.893906) : Query Engine actual: querying dyn
provider with
(Thu Aug 09 12:05:53 2007.893906) : CALL CWbemNamespace::GetObject
BSTR ObjectPath = EFX_PortGroup
long lFlags = 0
IWbemClassObject pObj = 0x118F938
(Thu Aug 09 12:05:53 2007.893906) : CALL CWbemNamespace::GetObject
BSTR ObjectPath =__ExtendedStatus
long lFlags = 0
IWbemClassObject ** pObj = 0x118F938

WMIPROV.LOG

(Thu Aug 09 12:05:53 2007.893906) : WDM specific return code: 0
(Thu Aug 09 12:05:53 2007.893906) :

OSR_Community_User · August 9, 2007, 12:11pm

Doron Holan wrote:

There is a bug where if the instance count goes back down to zero … This is
fixed in v1.7.

I have retested the code using KMDF 1.7 from WDK 6001 beta 3 on Longhorn
Server Beta 3. I still see the same problem.

MH.

Doron_Holan · August 9, 2007, 1:26pm

is the provider marked as expensive? When the count goes back to zero,
we deregister the guid for non expensive providers. For expensive
providers, they remain registered even with zero instances

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin Harvey
Sent: Thursday, August 09, 2007 9:10 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem with WDF WMI support.

Doron Holan wrote:

There is a bug where if the instance count goes back down to zero …
This is
fixed in v1.7.

I have retested the code using KMDF 1.7 from WDK 6001 beta 3 on Longhorn

Server Beta 3. I still see the same problem.

MH.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

OSR_Community_User · August 10, 2007, 9:02am

Doron Holan wrote:

is the provider marked as expensive?

I have tried setting the expensive flag on all of my providers and I
still see the same problems.

I have two devices, each with many WMI providers for the same set of WMI
classes/GUIDs. For brevity my output below focuses on just two WMI
classes which illustrate the issues I’m seeing:

Child WDFHANDLEs of 0x0000057ffe20cff8:
WDFDEVICE 0x0000057ffe20cff8
dt FxDevice 0xfffffa8001df3000
context: dt 0xfffffa8001df3370 BUS_DEVICE_CONTEXT (size is
0x212280 bytes)
EvtDestroyCallback fffffa6001a31880 sfcbus!EvtDestroyCallback

[… SNIP …]

WDFWMIPROVIDER 0x0000057ffdff9fd8
dt FxWmiProvider 0xfffffa8002006020

WDFWMIINSTANCE 0x0000057ffdff6d88
dt FxWmiInstanceExternal 0xfffffa8002009270
context: dt 0xfffffa8002009340 BUS_PORT_GROUP_CONTEXT
(size is 0x8 bytes)
EvtCleanupCallback fffffa6001a3a5b0
sfcbus!TeamWmiPortGroupCleanup

[… SNIP …]

WDFWMIPROVIDER 0x0000057ffdff91f8
dt FxWmiProvider 0xfffffa8002006e00

[… SNIP …]

Child WDFHANDLEs of 0x0000057ffdf5ab78:
WDFDEVICE 0x0000057ffdf5ab78
dt FxDevice 0xfffffa80020a5480
context: dt 0xfffffa80020a57f0 BUS_SINGLETON_CONTEXT (size is
0x80 bytes)
EvtCleanupCallback fffffa6001a32580 sfcbus!BusSingletonEvtCleanup

[… SNIP …]

WDFWMIPROVIDER 0x0000057ffdf56858
dt FxWmiProvider 0xfffffa80020a97a0

[… SNIP …]

WDFWMIPROVIDER 0x0000057ffdf56a78
dt FxWmiProvider 0xfffffa80020a9580

WDFWMIINSTANCE 0x0000057ffdf56d98
dt FxWmiInstanceExternal 0xfffffa80020a9260
context: dt 0xfffffa80020a9330 BUS_ROOT_CONTEXT (size is
0x8 bytes)

[… SNIP …]

The first provider shown on each device is for my EFX_PortGroup class,
the second provider is for my EFX_Root class.

The first device has an instance of the EFX_PortGroup class, whilst the
second device has none. In fact the second device has never had any
instances of this class. When using a client, such as PowerShell, to
return all instances of the class I see the first device’s instance of
that class and an error:

PS> C:\Windows\System32> Get-WmiObject -namespace root\wmi EFX_PortGroup

GENUS : 2
CLASS : EFX_PortGroup
SUPERCLASS :
DYNASTY : EFX_PortGroup
RELPATH :
EFX_PortGroup.InstanceName=“PCI\VEN_1924&DEV_0703&SUBSYS_00011924&REV_01\4&26a7f3f5&0&0008_0”

PROPERTY_COUNT : 8
DERIVATION : {}
SERVER : AL-TEST-LH64
NAMESPACE : root\wmi
PATH :
\AL-TEST-LH64\root\wmi:EFX_PortGroup.InstanceName=“PCI\VEN_1924&DEV_0703&SUBSYS_00011924&REV_0

1\4&26a7f3f5&0&0008_0”
Active : True
Id : 1
InstanceName :
PCI\VEN_1924&DEV_0703&SUBSYS_00011924&REV_01\4&26a7f3f5&0&0008_0
NetworkAdapterIds : {1, 0, 0, 0…}
Nonpersistent : 1
NumNetworkAdapterIds : 1
NumPortIds : 1
PortIds : {1, 0, 0, 0…}

Get-WmiObject : Invalid object
At line:1 char:14
+ Get-WmiObject <<<< -namespace root\wmi EFX_PortGroup

PS>

The error disappears if I disable the second device, therefore it seems
as though the error is somehow being caused by the second device having
no instances of this class. If the second device also has instances of
this class all instances are returned correctly with no errors.

The situation is reversed for the EFX_Root class. The first device has
no (and has never had) instances of the EFX_Root class, whereas the
second device has one instance. If I ask for all instances of the
EFX_Root class, PowerShell returns no instances:

PS> Get-WmiObject -namespace root\wmi EFX_Root
PS>

Almost as if the enumeration stopped when no instances were found in the
first device’s provider for this class, rather than going on to check
other devices. When I disable the first device and repeat the query, I
correctly see the instance on the second device:

PS> Get-WmiObject -namespace root\wmi EFX_Root

GENUS : 2
CLASS : EFX_Root
SUPERCLASS :
DYNASTY : EFX_Root
RELPATH :
EFX_Root.InstanceName=“Root\SFCBUS_SINGLETON\UNIQUE_INSTANCE_0”
PROPERTY_COUNT : 3
DERIVATION : {}
SERVER : AL-TEST-LH64
NAMESPACE : root\wmi
PATH :
\AL-TEST-LH64\root\wmi:EFX_Root.InstanceName=“Root\SFCBUS_SINGLETON\UNIQUE_INSTANCE_0”

Active : True
Dummy : 0
InstanceName : Root\SFCBUS_SINGLETON\UNIQUE_INSTANCE_0

PS>

Extra WinDbg output, that may or may not be useful
--------------------------------------------------

1: kd> dt FxWmiProvider 0xfffffa8002006020
Wdf01000!FxWmiProvider
+0x000 __VFN_table : 0xfffffa6000ac7108 +0x008 m_Type : 0x1004 +0x00a m_ObjectSize : 0xc0 +0x00c m_Refcnt : 2 +0x010 m_Globals : 0xfffffa8001df0e30 _FX_DRIVER_GLOBALS
+0x018 m_ObjectFlags : 0x4a
+0x018 m_ObjectFlagsByName : FxObject::::
+0x01a m_ObjectState : 1
+0x020 m_ChildListHead : _LIST_ENTRY [0xfffffa80020092b0 - 0xfffffa80020092b0]
+0x030 m_SpinLock : 0
+0x038 m_ParentObject : 0xfffffa8001df3000 FxObject +0x040 m_ChildEntry : _LIST_ENTRY [0xfffffa8002006f50 -
0xfffffa8001df1240] +0x050 m_DisposeSingleEntry : _SINGLE_LIST_ENTRY +0x058 m_NPLock : 0 +0x060 m_ListEntry : _LIST_ENTRY [0xfffffa8002006f70 -
0xfffffa8001df1260] +0x070 m_InstanceListHead : _LIST_ENTRY [0xfffffa80020092d0 -
0xfffffa80020092d0] +0x080 m_NumInstances : 1 +0x088 m_Parent : 0xfffffa8001df0490 FxWmiIrpHandler
+0x090 m_Guid : _GUID {8cae0915-48f8-e3b2-8e72-2b519f2b0de0}
+0x0a0 m_TracingHandle : 0
+0x0a8 m_MinInstanceBufferSize : 0x420
+0x0ac m_Flags : 2
+0x0ac m_FlagsByName : FxWmiProvider::::
+0x0b0 m_FunctionControl : FxWmiProviderFunctionControlCallback
+0x0b8 m_EventControlEnabled : 0 ‘’
+0x0b9 m_DataBlockControlEnabled : 0x1 ‘’
+0x0ba m_RemoveGuid : 0 ‘’
1: kd> dt FxWmiProvider 0xfffffa8002006e00
Wdf01000!FxWmiProvider
+0x000__VFN_table : 0xfffffa6000ac7108 +0x008 m_Type : 0x1004 +0x00a m_ObjectSize : 0xc0 +0x00c m_Refcnt : 1 +0x010 m_Globals : 0xfffffa8001df0e30 _FX_DRIVER_GLOBALS
+0x018 m_ObjectFlags : 0x4a
+0x018 m_ObjectFlagsByName : FxObject::::
+0x01a m_ObjectState : 1
+0x020 m_ChildListHead : _LIST_ENTRY [0xfffffa8002006e20 - 0xfffffa8002006e20]
+0x030 m_SpinLock : 0
+0x038 m_ParentObject : 0xfffffa8001df3000 FxObject +0x040 m_ChildEntry : _LIST_ENTRY [0xfffffa8002006d30 -
0xfffffa8002006f50] +0x050 m_DisposeSingleEntry : _SINGLE_LIST_ENTRY +0x058 m_NPLock : 0 +0x060 m_ListEntry : _LIST_ENTRY [0xfffffa8002006d50 -
0xfffffa8002006f70] +0x070 m_InstanceListHead : _LIST_ENTRY [0xfffffa8002006e70 -
0xfffffa8002006e70] +0x080 m_NumInstances : 0 +0x088 m_Parent : 0xfffffa8001df0490 FxWmiIrpHandler
+0x090 m_Guid : _GUID {f376858b-f0f8-9fbc-0e38-5bbd14d31f81}
+0x0a0 m_TracingHandle : 0
+0x0a8 m_MinInstanceBufferSize : 4
+0x0ac m_Flags : 2
+0x0ac m_FlagsByName : FxWmiProvider::::
+0x0b0 m_FunctionControl : FxWmiProviderFunctionControlCallback
+0x0b8 m_EventControlEnabled : 0 ‘’
+0x0b9 m_DataBlockControlEnabled : 0x1 ‘’
+0x0ba m_RemoveGuid : 0 ‘’
1: kd> dt FxWmiProvider 0xfffffa80020a97a0
Wdf01000!FxWmiProvider
+0x000 __VFN_table : 0xfffffa6000ac7108 +0x008 m_Type : 0x1004 +0x00a m_ObjectSize : 0xc0 +0x00c m_Refcnt : 1 +0x010 m_Globals : 0xfffffa8001df0e30 _FX_DRIVER_GLOBALS
+0x018 m_ObjectFlags : 0x4a
+0x018 m_ObjectFlagsByName : FxObject::::
+0x01a m_ObjectState : 1
+0x020 m_ChildListHead : _LIST_ENTRY [0xfffffa80020a97c0 - 0xfffffa80020a97c0]
+0x030 m_SpinLock : 0
+0x038 m_ParentObject : 0xfffffa80020a5480 FxObject +0x040 m_ChildEntry : _LIST_ENTRY [0xfffffa80020a96d0 -
0xfffffa80020a98f0] +0x050 m_DisposeSingleEntry : _SINGLE_LIST_ENTRY +0x058 m_NPLock : 0 +0x060 m_ListEntry : _LIST_ENTRY [0xfffffa80020a96f0 -
0xfffffa80020a9910] +0x070 m_InstanceListHead : _LIST_ENTRY [0xfffffa80020a9810 -
0xfffffa80020a9810] +0x080 m_NumInstances : 0 +0x088 m_Parent : 0xfffffa80020909d0 FxWmiIrpHandler
+0x090 m_Guid : _GUID {8cae0915-48f8-e3b2-8e72-2b519f2b0de0}
+0x0a0 m_TracingHandle : 0
+0x0a8 m_MinInstanceBufferSize : 0x420
+0x0ac m_Flags : 2
+0x0ac m_FlagsByName : FxWmiProvider::::
+0x0b0 m_FunctionControl : FxWmiProviderFunctionControlCallback
+0x0b8 m_EventControlEnabled : 0 ‘’
+0x0b9 m_DataBlockControlEnabled : 0x1 ‘’
+0x0ba m_RemoveGuid : 0 ‘’
1: kd> dt FxWmiProvider 0xfffffa80020a9580
Wdf01000!FxWmiProvider
+0x000__VFN_table : 0xfffffa6000ac7108 +0x008 m_Type : 0x1004 +0x00a m_ObjectSize : 0xc0 +0x00c m_Refcnt : 2 +0x010 m_Globals : 0xfffffa8001df0e30 _FX_DRIVER_GLOBALS
+0x018 m_ObjectFlags : 0x4a
+0x018 m_ObjectFlagsByName : FxObject::::
+0x01a m_ObjectState : 1
+0x020 m_ChildListHead : _LIST_ENTRY [0xfffffa80020a92a0 - 0xfffffa80020a92a0]
+0x030 m_SpinLock : 0
+0x038 m_ParentObject : 0xfffffa80020a5480 FxObject +0x040 m_ChildEntry : _LIST_ENTRY [0xfffffa80020a94b0 -
0xfffffa80020a96d0] +0x050 m_DisposeSingleEntry : _SINGLE_LIST_ENTRY +0x058 m_NPLock : 0 +0x060 m_ListEntry : _LIST_ENTRY [0xfffffa80020a94d0 -
0xfffffa80020a96f0] +0x070 m_InstanceListHead : _LIST_ENTRY [0xfffffa80020a92c0 -
0xfffffa80020a92c0] +0x080 m_NumInstances : 1 +0x088 m_Parent : 0xfffffa80020909d0 FxWmiIrpHandler
+0x090 m_Guid : _GUID {f376858b-f0f8-9fbc-0e38-5bbd14d31f81}
+0x0a0 m_TracingHandle : 0
+0x0a8 m_MinInstanceBufferSize : 4
+0x0ac m_Flags : 2
+0x0ac m_FlagsByName : FxWmiProvider::::
+0x0b0 m_FunctionControl : FxWmiProviderFunctionControlCallback
+0x0b8 m_EventControlEnabled : 0 ‘’
+0x0b9 m_DataBlockControlEnabled : 0x1 ‘’
+0x0ba m_RemoveGuid : 0 ‘’
1: kd> dt FxWmiInstanceExternal 0xfffffa8002009270
Wdf01000!FxWmiInstanceExternal
+0x000 __VFN_table : 0xfffffa6000ac7210 +0x008 m_Type : 0x1034 +0x00a m_ObjectSize : 0xa0 +0x00c m_Refcnt : 1 +0x010 m_Globals : 0xfffffa8001df0e30 _FX_DRIVER_GLOBALS
+0x018 m_ObjectFlags : 0x48
+0x018 m_ObjectFlagsByName : FxObject::::
+0x01a m_ObjectState : 1
+0x020 m_ChildListHead : _LIST_ENTRY [0xfffffa8002009290 - 0xfffffa8002009290]
+0x030 m_SpinLock : 0
+0x038 m_ParentObject : 0xfffffa8002006020 FxObject +0x040 m_ChildEntry : _LIST_ENTRY [0xfffffa8002006040 -
0xfffffa8002006040] +0x050 m_DisposeSingleEntry : _SINGLE_LIST_ENTRY +0x058 m_NPLock : 0 +0x060 m_ListEntry : _LIST_ENTRY [0xfffffa8002006090 -
0xfffffa8002006090] +0x070 m_Provider : 0xfffffa8002006020 FxWmiProvider
+0x078 m_QueryInstanceCallback : FxWmiInstanceQueryInstanceCallback
+0x080 m_SetInstanceCallback : FxWmiInstanceSetInstanceCallback
+0x088 m_SetItemCallback : FxWmiInstanceSetItemCallback
+0x090 m_ExecuteMethodCallback : FxWmiInstanceExecuteMethodCallback
+0x098 m_ContextLength : 0
+0x09c m_UseContextForQuery : 0 ‘’
1: kd> dt FxWmiInstanceExternal 0xfffffa80020a9260
Wdf01000!FxWmiInstanceExternal
+0x000__VFN_table : 0xfffffa6000ac7210 +0x008 m_Type : 0x1034 +0x00a m_ObjectSize : 0xa0 +0x00c m_Refcnt : 1 +0x010 m_Globals : 0xfffffa8001df0e30 _FX_DRIVER_GLOBALS
+0x018 m_ObjectFlags : 0x48
+0x018 m_ObjectFlagsByName : FxObject::::
+0x01a m_ObjectState : 1
+0x020 m_ChildListHead : _LIST_ENTRY [0xfffffa80020a9280 - 0xfffffa80020a9280]
+0x030 m_SpinLock : 0
+0x038 m_ParentObject : 0xfffffa80020a9580 FxObject +0x040 m_ChildEntry : _LIST_ENTRY [0xfffffa80020a95a0 -
0xfffffa80020a95a0] +0x050 m_DisposeSingleEntry : _SINGLE_LIST_ENTRY +0x058 m_NPLock : 0 +0x060 m_ListEntry : _LIST_ENTRY [0xfffffa80020a95f0 -
0xfffffa80020a95f0] +0x070 m_Provider : 0xfffffa80020a9580 FxWmiProvider
+0x078 m_QueryInstanceCallback : FxWmiInstanceQueryInstanceCallback
+0x080 m_SetInstanceCallback : FxWmiInstanceSetInstanceCallback
+0x088 m_SetItemCallback : FxWmiInstanceSetItemCallback
+0x090 m_ExecuteMethodCallback : FxWmiInstanceExecuteMethodCallback
+0x098 m_ContextLength : 0
+0x09c m_UseContextForQuery : 0 ‘’

OSR_Community_User · August 13, 2007, 8:15pm

Martin-

My apologies for the delayed response. We do feel that this is a serious issue that needs further investigation.

I will be investigating this myself- unfortunately there will be an unusually long delay (my vacation). I wish we could do better, but we’re intensely shorthanded these days- this appears to be the best we can do for now.

May I contact you at your email if I need additional information? Feel free to contact me if you have further concerns (or you can post here- I at least skim every post, although I’ve not much time to do much more these days).

Bob Kjelgaard
Windows Driver Frameworks Quality Assurance