Writing WMI providers FAQ series – 1 – If a provider doesn’t support query capabilities, how is the query handled by WMI?

The aim of the series is to cover a WMI Provider writing question  per post. If you have a question, you'd like the WMI team to answer, do leave a comment.

Now, for the answer -  

Let's take the Win32_Product class supported by the MSI provider as it is today. This class returns a complete list of installed MSI applications. When a WMI client requests all Win32_Product instances with WQL queries such as:


  • Select * From Win32_Product


  • Select * From Win32_Product Where Vendor="Microsoft"


the corresponding WMI provider gets loaded and WMI callbacks the provider at the level of:


  • its query interfaces if the provider claims that it supports WQL queries in its registration data. In this case, up to the provider to handle the query and the filtering based on the WHERE statement specified (if any).


  • its Enum interfaces to get the collection of all instances if the provider claims that it doesn't support WQL queries in its registration data. In this case, based on the WHERE statement filtering (if any), WMI makes a post filtering on the collection returned by the WMI provider to ensure that the data returned by WMI is matching the WMI client query.


So, in conclusion:


  • If the provider supports WQL queries, the provider itself handles queries and does the filtering on Vendor="Microsoft" as used in the query example.
  • If the provider doesn't support WQL queries, WMI core will make a post filtering on the collection returned by the provider based on the Vendor="Microsoft" as used in the query example.


Of course, it is important to note that depending on the nature and complexity of the object model, returning a collection to WMI core is not always the best way to proceed. There are situations where a filtering handled by WMI core will not be efficient enough (e.g. when the collection is extremely large). In such a case, it is recommended that the WMI provider supports queries in order to perform the filtering in the provider code. This makes sense as the provider it is the only software component having a perfect understanding of the manageable entity model it surfaces.

Kapil Mathur [MSFT] 


Comments (3)

  1. unnisworld says:

    I am trying to query for HBA attributes through winrm using the following command,

    winrm e wmi/root/MSFC_FCAdapterHBAAttributes

    The error message that i am getting is : The WS-Management service cannot process the request. The service cannot find the resource identified by the resource URI and selectors.

    I am able to query for cim classes like – wmi/root/cimv2/Win32_ComputerSystem

    This is a Windows 2003 machine and fcinfo tool is installed on the machine. I am able to see the HBA details through WMI Object browser tool.

    Am I using the wrong URI ?

  2. kmathur says:

    You are missing something in the URI – the missing part is the WMI namespace: winrm e wmi/root/<something>/MSFC_FCAdapterHBAAttributes. <something> would be whichever namespace the customer used when connecting through the WMI object browser.

  3. Manoj says:

    the something is wmi.

    the following query works

    winrm e wmi/root/wmi/MSFC_FCAdapterHBAAttributes

Skip to main content