May GetAdaptersInfo() be used in a kernel-mode driver?
I suppose one has to use the IP Helper methods. What should be used to get be used to retrieve MAC addresses?
In Windows Vista and later there are kernel equivalents of some “IP Helper”
functions. Search for “IP Helper” in the WDK documentation.
If you are writing a NDIS 6 protocol or filter then some of the information
you are looking for may be in the bind or attach parameters.
On XP you are more limited. There are some OIDs that pass IP addressing
information if that is what you are looking for.
Good luck,
Thomas F. Divine
http://www.pcausa.com
From:
Sent: Tuesday, October 19, 2010 10:50 PM
To: “Windows System Software Devs Interest List”
Subject: [ntdev] GetAdaptersInfo()
> May GetAdaptersInfo() be used in a kernel-mode driver?
>
>
>
> —
> 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
What sort of driver are you writing?
If you are writing a NDIS 6 driver then that is probably handed to you in
the bind or attach callbacks.
On XP you may need to have your NDIS 5 protocol or filter make it’s own NDIS
query for OID_802_3_CURRENT_ADDRESS.
Good luck,
Thomas F. Divine
http://www.pcausa.com
From:
Sent: Tuesday, October 19, 2010 11:17 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] GetAdaptersInfo()
> I suppose one has to use the IP Helper methods. What should be used to get
> be used to retrieve MAC addresses?
>
> —
> 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
What sort of driver are you writing?
If you are writing a NDIS 6 driver then that is probably handed to you in
the bind or attach callbacks.
On XP you may need to have your NDIS 5 protocol or filter make it’s own NDIS
query for OID_802_3_CURRENT_ADDRESS.
Good luck,
Thomas F. Divine
http://www.pcausa.com
From:
Sent: Tuesday, October 19, 2010 11:17 PM
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] GetAdaptersInfo()
> I suppose one has to use the IP Helper methods. What should be used to get
> be used to retrieve MAC addresses?
>
> —
> 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
Kernel mode filter driver for XP machines and up.
Well, you can enumerate installed adapters by IOCTLing with OID_802_3_CURRENT_ADDRESS each device found in:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Adapters
If adapter is down, the IOCTLing will fail, of course.
Ah, please don't rummage around in internal registry keys. (How would you like it if Windows messed with your data?) This is broken anyway, since TCPIP doesn't bind to every single adapter.
Also, the IOCTL interface is deprecated, and we kinda want it to go away. It's only documented to work for statistics OIDs, and it's something of an accident that it might work for a few other OIDs. It certainly doesn't work for all OIDs.
If you are really only interested in the adapter to which your filter is bound, then great, issue the OIDs yourself (e.g., OID_802_3_CURRENT_ADDRESS as mentioned earlier). That's a normal thing for filters to be interested in, and NDIS is all set up for you to easily get it. Problem solved.
On the other hand, if you want to know about *other* adapters to which you are *not* bound (or if you are not an NDIS driver at all), then that's a little more exotic. Since you need to work on XP, the best approach is to roll up your sleeves and get out the WMI.
I will take the cheap route and provide an example in usermode -- below is a PowerShell script that uses WMI to query the MAC addresses of all the adapters on your system. But the same WMI class works from kernel-mode too (it just takes a few more lines of code, since C isn't as awesome as PowerShell).
Purpose: Print out a list of adapters with their MAC addresses
Get an array of objects, one for each adapter
$Adapters = Get-WMIObject -namespace root\wmi -class MSNdis_EthernetCurrentAddress
$Adapters | ForEach-Object {
Write-Host $_.InstanceName
Convert to hex and print in the usual hyphen-separated style
($.NdisCurrentAddress.Address | % {"{0:x2}" -f $}) -join "-"
}
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@shcherbyna.com
Sent: Friday, October 22, 2010 8:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] GetAdaptersInfo()
Well, you can enumerate installed adapters by IOCTLing with OID_802_3_CURRENT_ADDRESS each device found in:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Adapters
If adapter is down, the IOCTLing will fail, of course.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at ListServer/Forum
Say wait a minute Jeffery, are you are saying I can do WMI instance queries
from KERNEL MODE? I always knew there were user and kernel mode WMI
providers, but always though ACCESS to much of the data was from user mode
only? I’ve always assumed WMI does not function until the user mode WMI
service is up and running. Can you clarify what you meant when you said "
But the same WMI class works from kernel-mode"?
Jan
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-428875-
xxxxx@lists.osr.com] On Behalf Of Jeffrey Tippet
Sent: Friday, October 22, 2010 10:24 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] GetAdaptersInfo()Ah, please don’t rummage around in internal registry keys. (How would you
like it if Windows messed with your data?) This is broken anyway, since
TCPIP doesn’t bind to every single adapter.Also, the IOCTL interface is deprecated, and we kinda want it to go away.
It’s
only documented to work for statistics OIDs, and it’s something of an
accident that it might work for a few other OIDs. It certainly doesn’t
work for
all OIDs.If you are really only interested in the adapter to which your filter is
bound,
then great, issue the OIDs yourself (e.g., OID_802_3_CURRENT_ADDRESS as
mentioned earlier). That’s a normal thing for filters to be interested
in, and
NDIS is all set up for you to easily get it. Problem solved.On the other hand, if you want to know about *other* adapters to which
you are *not* bound (or if you are not an NDIS driver at all), then that’s
a
little more exotic. Since you need to work on XP, the best approach is to
roll
up your sleeves and get out the WMI.I will take the cheap route and provide an example in usermode – below is
a
PowerShell script that uses WMI to query the MAC addresses of all the
adapters on your system. But the same WMI class works from kernel-mode
too (it just takes a few more lines of code, since C isn’t as awesome as
PowerShell).Purpose: Print out a list of adapters with their MAC addresses
Get an array of objects, one for each adapter $Adapters = Get-WMIObject
-namespace root\wmi -class MSNdis_EthernetCurrentAddress
$Adapters | ForEach-Object {
Write-Host $_.InstanceName
Convert to hex and print in the usual hyphen-separated style
($.NdisCurrentAddress.Address | % {“{0:x2}” -f $}) -join “-”
}-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-428797-
xxxxx@lists.osr.com] On Behalf Of xxxxx@shcherbyna.com
Sent: Friday, October 22, 2010 8:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] GetAdaptersInfo()Well, you can enumerate installed adapters by IOCTLing with
OID_802_3_CURRENT_ADDRESS each device found in:HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Adapters
If adapter is down, the IOCTLing will fail, of course.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
It would be helpful to have a sample of a KM WMI ‘client’ to point at to
demonstrate just enough of how IoWMIOpenBlock() and the IoWMIQueryXxx() and
IoWMISetXxxx() routines work. In particular, the WDK docs don’t say much
that someone familiar with WMI from UM would recognize as a means to
translate the powerscript into KM ‘C’ code.
Is it your (Mr. Tippet’s) hint to:
IoWMIOpenBlock( , WMIGUID_QUERY,
&wmiDataBlock );
IoWMQueryAllData( wmiDataBlock, &bufferSize, buffer );
and then wander through the buffer of WNODE_ALL_DATA walking the returned
instance data?
Cheers,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Tippet
Sent: Saturday, October 23, 2010 1:24 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] GetAdaptersInfo()
Ah, please don’t rummage around in internal registry keys. (How would you
like it if Windows messed with your data?) This is broken anyway, since
TCPIP doesn’t bind to every single adapter.
Also, the IOCTL interface is deprecated, and we kinda want it to go away.
It’s only documented to work for statistics OIDs, and it’s something of an
accident that it might work for a few other OIDs. It certainly doesn’t work
for all OIDs.
If you are really only interested in the adapter to which your filter is
bound, then great, issue the OIDs yourself (e.g., OID_802_3_CURRENT_ADDRESS
as mentioned earlier). That’s a normal thing for filters to be interested
in, and NDIS is all set up for you to easily get it. Problem solved.
On the other hand, if you want to know about other adapters to which you
are not bound (or if you are not an NDIS driver at all), then that’s a
little more exotic. Since you need to work on XP, the best approach is to
roll up your sleeves and get out the WMI.
I will take the cheap route and provide an example in usermode – below is a
PowerShell script that uses WMI to query the MAC addresses of all the
adapters on your system. But the same WMI class works from kernel-mode too
(it just takes a few more lines of code, since C isn’t as awesome as
PowerShell).
# Purpose: Print out a list of adapters with their MAC addresses
# Get an array of objects, one for each adapter
$Adapters = Get-WMIObject -namespace root\wmi -class
MSNdis_EthernetCurrentAddress
$Adapters | ForEach-Object {
Write-Host $.InstanceName
# Convert to hex and print in the usual hyphen-separated style
($.NdisCurrentAddress.Address | % {“{0:x2}” -f $_}) -join “-”
}
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@shcherbyna.com
Sent: Friday, October 22, 2010 8:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] GetAdaptersInfo()
Well, you can enumerate installed adapters by IOCTLing with
OID_802_3_CURRENT_ADDRESS each device found in:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Adapters
If adapter is down, the IOCTLing will fail, of course.
—
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
—
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
There are IoWmi routines that let you query wmi. It is not the user mode com interfaces.
d
dent from a phpne with no keynoard
-----Original Message-----
From: Jan Bottorff
Sent: October 23, 2010 12:44 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] GetAdaptersInfo()
Say wait a minute Jeffery, are you are saying I can do WMI instance queries
from KERNEL MODE? I always knew there were user and kernel mode WMI
providers, but always though ACCESS to much of the data was from user mode
only? I’ve always assumed WMI does not function until the user mode WMI
service is up and running. Can you clarify what you meant when you said “
But the same WMI class works from kernel-mode”?
Jan
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-428875-
> xxxxx@lists.osr.com] On Behalf Of Jeffrey Tippet
> Sent: Friday, October 22, 2010 10:24 PM
> To: Windows System Software Devs Interest List
> Subject: RE: RE:[ntdev] GetAdaptersInfo()
>
> Ah, please don’t rummage around in internal registry keys. (How would you
> like it if Windows messed with your data?) This is broken anyway, since
> TCPIP doesn’t bind to every single adapter.
>
> Also, the IOCTL interface is deprecated, and we kinda want it to go away.
It’s
> only documented to work for statistics OIDs, and it’s something of an
> accident that it might work for a few other OIDs. It certainly doesn’t
work for
> all OIDs.
>
> If you are really only interested in the adapter to which your filter is
bound,
> then great, issue the OIDs yourself (e.g., OID_802_3_CURRENT_ADDRESS as
> mentioned earlier). That’s a normal thing for filters to be interested
in, and
> NDIS is all set up for you to easily get it. Problem solved.
>
> On the other hand, if you want to know about other adapters to which
> you are not bound (or if you are not an NDIS driver at all), then that’s
a
> little more exotic. Since you need to work on XP, the best approach is to
roll
> up your sleeves and get out the WMI.
>
> I will take the cheap route and provide an example in usermode – below is
a
> PowerShell script that uses WMI to query the MAC addresses of all the
> adapters on your system. But the same WMI class works from kernel-mode
> too (it just takes a few more lines of code, since C isn’t as awesome as
> PowerShell).
>
>
> # Purpose: Print out a list of adapters with their MAC addresses
>
> # Get an array of objects, one for each adapter $Adapters = Get-WMIObject
> -namespace root\wmi -class MSNdis_EthernetCurrentAddress
>
> $Adapters | ForEach-Object {
>
> Write-Host $.InstanceName
>
> # Convert to hex and print in the usual hyphen-separated style
> ($.NdisCurrentAddress.Address | % {“{0:x2}” -f $_}) -join “-”
> }
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-428797-
> xxxxx@lists.osr.com] On Behalf Of xxxxx@shcherbyna.com
> Sent: Friday, October 22, 2010 8:30 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] GetAdaptersInfo()
>
> Well, you can enumerate installed adapters by IOCTLing with
> OID_802_3_CURRENT_ADDRESS each device found in:
>
> HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Adapters
>
> If adapter is down, the IOCTLing will fail, of course.
>
>
>
> —
> 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
>
>
> —
> 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
—
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
I have working code.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Saturday, October 23, 2010 10:39 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] GetAdaptersInfo()
It would be helpful to have a sample of a KM WMI ‘client’ to point at to
demonstrate just enough of how IoWMIOpenBlock() and the IoWMIQueryXxx() and
IoWMISetXxxx() routines work. In particular, the WDK docs don’t say much
that someone familiar with WMI from UM would recognize as a means to
translate the powerscript into KM ‘C’ code.
Is it your (Mr. Tippet’s) hint to:
IoWMIOpenBlock( , WMIGUID_QUERY,
&wmiDataBlock );
IoWMQueryAllData( wmiDataBlock, &bufferSize, buffer );
and then wander through the buffer of WNODE_ALL_DATA walking the returned
instance data?
Cheers,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Tippet
Sent: Saturday, October 23, 2010 1:24 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] GetAdaptersInfo()
Ah, please don’t rummage around in internal registry keys. (How would you
like it if Windows messed with your data?) This is broken anyway, since
TCPIP doesn’t bind to every single adapter.
Also, the IOCTL interface is deprecated, and we kinda want it to go away.
It’s only documented to work for statistics OIDs, and it’s something of an
accident that it might work for a few other OIDs. It certainly doesn’t work
for all OIDs.
If you are really only interested in the adapter to which your filter is
bound, then great, issue the OIDs yourself (e.g., OID_802_3_CURRENT_ADDRESS
as mentioned earlier). That’s a normal thing for filters to be interested
in, and NDIS is all set up for you to easily get it. Problem solved.
On the other hand, if you want to know about other adapters to which you
are not bound (or if you are not an NDIS driver at all), then that’s a
little more exotic. Since you need to work on XP, the best approach is to
roll up your sleeves and get out the WMI.
I will take the cheap route and provide an example in usermode – below is a
PowerShell script that uses WMI to query the MAC addresses of all the
adapters on your system. But the same WMI class works from kernel-mode too
(it just takes a few more lines of code, since C isn’t as awesome as
PowerShell).
# Purpose: Print out a list of adapters with their MAC addresses
# Get an array of objects, one for each adapter $Adapters = Get-WMIObject
-namespace root\wmi -class MSNdis_EthernetCurrentAddress
$Adapters | ForEach-Object {
Write-Host $.InstanceName
# Convert to hex and print in the usual hyphen-separated style
($.NdisCurrentAddress.Address | % {“{0:x2}” -f $_}) -join “-”
}
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@shcherbyna.com
Sent: Friday, October 22, 2010 8:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] GetAdaptersInfo()
Well, you can enumerate installed adapters by IOCTLing with
OID_802_3_CURRENT_ADDRESS each device found in:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Adapters
If adapter is down, the IOCTLing will fail, of course.
—
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
—
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
—
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
And what can be done from kernel mode with IoWMISetSingleInstance and IoWMIExecuteMethod…
– pa
Hello Jeffrey,
Correct me if I am wrong, but from what I’ve observed, on a large scale the WMI turns out to be unreliable solution which has to be avoided.
I am using WMI to get hardware information of machines in enterprise environment and it turns out that 5% or more of all Windows machines have constant problems with WMI. It is not my code which is buggy, other software on those machines cannot use WMI as well. If I ask for Event Logs I see a lot of WMI failures and the most popular is “WMI Critical Error”. No extra details, just generic errors.
The interesting thing is that Microsoft does not provide any tools to recover WMI it only recommends to repair Windows or restore to snapshot: http://support.microsoft.com/kb/823775
However, in real life, this solution is not affordable. Given above, I am not sure it is good to use WMI in kernel mode 
Please correct me if I am wrong. I will appriciate if you will point me out some tools to troubleshoot WMI issues.
Thanks.
Jeffrey Tippet [MSFT] wrote:
>I will take the cheap route and provide an example in usermode – below is a PowerShell script that uses WMI to query the MAC addresses of all the adapters on your system. But the same WMI class works from kernel-mode too (it just takes a few more lines of code, since C isn’t as awesome as PowerShell). <<
Fine. Here’s how to do the exact same thing in kernel mode. The function’s input is an adapter’s InstanceName (e.g., the Hyper-V synthetic NIC might have name “Microsoft Virtual Machine Bus Network Adapter”). The output is a UCHAR array with its MAC address.
Querying WMI from kernel mode is actually Not Too Difficult Once You Get The Hang Of It ™, but there’s enough distracting boilerplate with manual memory management and etc., that I find it’s much easier to use PowerShell to explore and illustrate NDIS’s WMI classes.
#define INITGUID
#include <wdm.h>
#include <wmistr.h>
#include <wmidata.h>
__drv_requiresIRQL(PASSIVE_LEVEL)
NTSTATUS
kmwmiQueryMacAddress(
__in PUNICODE_STRING AdapterName,
out PUSHORT MacAddressLength,
out_bcount_part(32, *MacAddressLength) PUCHAR MacAddress)
{
NTSTATUS NtStatus;
PVOID WmiDataBlock = NULL;
ULONG WmiBufferSize = 0;
PWNODE_SINGLE_INSTANCE WNode = NULL;
PMSNdis_EthernetCurrentAddress CurrentAddress;
// Get the MSNdis_EthernetCurrentAddress block
NtStatus = IoWMIOpenBlock(
&MSNdis_EthernetCurrentAddress_GUID,
WMIGUID_QUERY,
&WmiDataBlock);
if (STATUS_SUCCESS != NtStatus)
{
WmiDataBlock = NULL;
goto Cleanup;
}
// Query for the miniport instance that we’re interested in.
// AdapterName is the same name that !NDISKD.MINIPORT would show at the top.
// Note that the AdapterName is a UNICODE_STRING without NULL termination.
WmiBufferSize = 0;
NtStatus = IoWMIQuerySingleInstance(
WmiDataBlock,
AdapterName,
&WmiBufferSize,
WNode);
if (STATUS_BUFFER_TOO_SMALL != NtStatus)
{
goto Cleanup;
}
// Allocate enough space for the WNODE and requery.
WNode = ExAllocatePoolWithTag(NonPagedPool, WmiBufferSize, ‘imwk’);
if (!WNode)
{
goto Cleanup;
}
NtStatus = IoWMIQuerySingleInstance(
WmiDataBlock,
AdapterName,
&WmiBufferSize,
WNode);
if (STATUS_SUCCESS != NtStatus)
{
goto Cleanup;
}
// For this GUID, the data type is PMSNdis_EthernetCurrentAddress.
// (See wmidata.h to learn the GUID/structure association).
CurrentAddress = (PMSNdis_EthernetCurrentAddress)((PUCHAR)WNode + WNode->DataBlockOffset);
*MacAddressLength = 6;
RtlCopyMemory(MacAddress, CurrentAddress->NdisCurrentAddress.Address, 6);
Cleanup:
if (WmiDataBlock)
{
ObDereferenceObject(WmiDataBlock);
}
if (WNode)
{
ExFreePool(WNode);
}
return NtStatus;
}
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Saturday, October 23, 2010 7:39 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] GetAdaptersInfo()
It would be helpful to have a sample of a KM WMI ‘client’ to point at to demonstrate just enough of how IoWMIOpenBlock() and the IoWMIQueryXxx() and
IoWMISetXxxx() routines work. In particular, the WDK docs don’t say much
that someone familiar with WMI from UM would recognize as a means to translate the powerscript into KM ‘C’ code.
Is it your (Mr. Tippet’s) hint to:
IoWMIOpenBlock( , WMIGUID_QUERY, &wmiDataBlock );
IoWMQueryAllData( wmiDataBlock, &bufferSize, buffer );
and then wander through the buffer of WNODE_ALL_DATA walking the returned instance data?
Cheers,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Tippet
Sent: Saturday, October 23, 2010 1:24 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] GetAdaptersInfo()
Ah, please don’t rummage around in internal registry keys. (How would you like it if Windows messed with your data?) This is broken anyway, since TCPIP doesn’t bind to every single adapter.
Also, the IOCTL interface is deprecated, and we kinda want it to go away.
It’s only documented to work for statistics OIDs, and it’s something of an accident that it might work for a few other OIDs. It certainly doesn’t work for all OIDs.
If you are really only interested in the adapter to which your filter is bound, then great, issue the OIDs yourself (e.g., OID_802_3_CURRENT_ADDRESS as mentioned earlier). That’s a normal thing for filters to be interested in, and NDIS is all set up for you to easily get it. Problem solved.
On the other hand, if you want to know about other adapters to which you are not bound (or if you are not an NDIS driver at all), then that’s a little more exotic. Since you need to work on XP, the best approach is to roll up your sleeves and get out the WMI.
I will take the cheap route and provide an example in usermode – below is a PowerShell script that uses WMI to query the MAC addresses of all the adapters on your system. But the same WMI class works from kernel-mode too (it just takes a few more lines of code, since C isn’t as awesome as PowerShell).
# Purpose: Print out a list of adapters with their MAC addresses
# Get an array of objects, one for each adapter $Adapters = Get-WMIObject -namespace root\wmi -class MSNdis_EthernetCurrentAddress
$Adapters | ForEach-Object {
Write-Host $.InstanceName
# Convert to hex and print in the usual hyphen-separated style
($.NdisCurrentAddress.Address | % {“{0:x2}” -f $_}) -join “-”
}
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@shcherbyna.com
Sent: Friday, October 22, 2010 8:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] GetAdaptersInfo()
Well, you can enumerate installed adapters by IOCTLing with OID_802_3_CURRENT_ADDRESS each device found in:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Adapters
If adapter is down, the IOCTLing will fail, of course.
—
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
—
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
—
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</wmidata.h></wmistr.h></wdm.h>
WMI is a very large set of technologies, which is used by many system components. Saying “I saw some errors relating to WMI, therefore all WMI is unreliable and I don’t want to use it” is sort of like saying “I saw some errors relating to networking, therefore all networking is unreliable and I don’t want to use it”.
In particular, the topic being discussed here is kernel-mode WMI, where one kernel component talks directly to another, using WMI. Here WMI is a very thin wrapper (similar to IOCTL, but with a slightly more structure) between the two components (in this case, between NDIS.SYS and your driver code). This is almost certainly not broken on “5% or more of all Windows machines”, since that would mean that those computers are nearly unusable (WMI is used for lots of things across the system).
Chances are, you’re seeing problems with the WMI *remoting* layer, which allows one computer to make WMI queries against another computer over the network. This involves considerably many moving parts (networking, authentication, winmgmt service, etc.), and therefore has a higher chance of failure. (Since engineering tells us that more moving parts == more complexity == more failure modes). I can’t help you diagnose problems with that layer, since I’m not at all an expert, and it’s not really on-topic for this forum anyway.
My point is that even if you have the opinion that WMI can’t be used to remotely manage computers in your domain, that shouldn’t scare you away from calling a kernel function with “WMI” in its name, since they’re actually not the same thing. (Or rather, the latter is a very small and reliable subset of the former). I would encourage you to think of kernel-mode WMI as being similar to IOCTLs, except WMI has additional benefits, like being easy to script from usemode.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@shcherbyna.com
Sent: Monday, October 25, 2010 1:53 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] GetAdaptersInfo()
Hello Jeffrey,
Correct me if I am wrong, but from what I’ve observed, on a large scale the WMI turns out to be unreliable solution which has to be avoided.
I am using WMI to get hardware information of machines in enterprise environment and it turns out that 5% or more of all Windows machines have constant problems with WMI. It is not my code which is buggy, other software on those machines cannot use WMI as well. If I ask for Event Logs I see a lot of WMI failures and the most popular is “WMI Critical Error”. No extra details, just generic errors.
The interesting thing is that Microsoft does not provide any tools to recover WMI it only recommends to repair Windows or restore to snapshot: http://support.microsoft.com/kb/823775
However, in real life, this solution is not affordable. Given above, I am not sure it is good to use WMI in kernel mode
Please correct me if I am wrong. I will appriciate if you will point me out some tools to troubleshoot WMI issues.
Thanks.
Jeffrey Tippet [MSFT] wrote:
>I will take the cheap route and provide an example in usermode – below is a PowerShell script that uses WMI to query the MAC addresses of all the adapters on your system. But the same WMI class works from kernel-mode too (it just takes a few more lines of code, since C isn’t as awesome as PowerShell). <<
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
Salut Jeffrey,
I like your metaphorical expression. Speaking metaphorically I can only give you an example of failure in WSAStartup (…) after which you indeed cannot use any winsock functions
I am not using WMI remotely. I lhave a client instaled on machine which is connecting to WMI using COM in a way it is described in MSDN: http://msdn.microsoft.com/en-us/library/aa389762(v=VS.85).aspx
Majority of errors I observe are when calling method ConnectServer (http://msdn.microsoft.com/en-us/library/aa390418(v=VS.85).aspx), I got 0x8004100a which stands for WBEM_E_CRITICAL_ERROR (http://msdn.microsoft.com/en-us/library/aa394559(VS.85).aspx)
If I would have this error just when querying some specified class - I could live with that. But it is something like failure of WSAStartup in the entry point of your application - a blocking issue for me.
I agree with you that WMI is a huge set of functionality. Given compexity like this, why Microsoft did not provide us the troubleshooting tools for it?
We have filemon, regmon, tdimon, etc. But nothing regarding WMI troubleshooting.
Finishing this message, just take a look at how this topic is popular
P.S. I forgot to mention this utility: http://www.microsoft.com/downloads/en/details.aspx?familyid=D7BA3CD6-18D1-4D05-B11E-4C64192AE97D&displaylang=en which actually gave quite a verbose output with something like this at the end “your wmi is corrupted, repair it”.
But how?
(Or rather, the latter is a very small and reliable subset of the former).
Does this imply that the range of WMI classes available via this interface
are limited to those mapped to WinMgmt via the WMI provider? (I may have
the terminology a bit muddled). For example, I can query stuff from NDIS
but not from Windows Installer? I know, I can just go try it and find out.
I am being a bit lazy.
Thanks,
Dave Cattley
I honestly don’t know the extent of the capabilities of the kernel-mode WMI consumer interface. I know it works for all the MSNdis_* classes, and beyond that, my interest is fairly limited.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Monday, October 25, 2010 3:04 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] GetAdaptersInfo()
(Or rather, the latter is a very small and reliable subset of the former).
Does this imply that the range of WMI classes available via this interface
are limited to those mapped to WinMgmt via the WMI provider? (I may have
the terminology a bit muddled). For example, I can query stuff from NDIS
but not from Windows Installer? I know, I can just go try it and find out.
I am being a bit lazy.
Thanks,
Dave Cattley
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