Windows 7 : Programming WMI Support (part 4) - Troubleshooting Specific WMI Problems

7. Troubleshooting Specific WMI Problems

The following paragraphs cover some of the common problems found in setting up and using WMI.

7.1. Driver’s WMI Classes Do Not Appear in the \root\wmi Namespace

The following steps cover how we would approach the troubleshooting of this particular problem.

1.	Use wmimofck driver.bmf to check if the binary MOF file format is correct. Additional error messages may be found in mofcomp.log.
2.	Check the system event log to see if the driver is returning a malformed WMIREGINFO data structure in response to the registration request.
3.	Check that the driver is returning the correct values for RegistryPath and MofResourceName within the WMIREGINFO structure.
4.	If the driver provides its MOF data in a separate file, check that the MofImagePath registry value for the driver is set correctly.
5.	Check the WMI WDM provider log for errors.
6.	Use Mofcomp to recompile and reload your MOF text file. For example, the command mofcomp –N:root/wmi driver.mof tries to recompile and reload any MOF data in the driver.mof file. Check to see what error messages Mofcomp generates in mofcomp.log. Note that if your MOF file uses preprocessor directives such as #define, you need to use the already preprocessed MOF file, and not the original source file. If the operation succeeds, it actually registers the new WMI class data with the system. You need to delete these classes (by using Wbemtest, for example) to test if your driver’s MOF data is being read correctly. If this step succeeds, the most likely problem is that the members of WMIREGINFO, such as MofResourceName, are specified incorrectly. Alternatively, the problem could be that your MOF file specifies a class derived from a base class that doesn’t exist.
7.	If the driver is using dynamic MOF data, check that the driver is receiving WMI IRP requests for the MSWmi_MofData_GUID GUID and that is completing the IRP successfully and with no error logged.

7.2. Driver’s WMI Properties or Methods Cannot Be Accessed

Use the following steps if you cannot access the driver’s WMI properties or methods:

1.	Use wmimofck driver.bmf to check if the binary MOF file format is correct.
2.	Check the system event log for errors.
3.	Check the WMI WDM Provider log for errors.
4.	Make sure the driver receives a WMI IRP whenever you use Wbemtest to query the driver’s classes. If not, check that the specified GUID in the MOF file matches the GUID the driver is expecting. Also check that the driver is receiving the WMI registration request, it is succeeding, and the driver is registering the right GUIDs.
5.	If the driver receives the IRP, ensure that the IRP is completed successfully, and that the driver is returning the right type of WNOFE_XXX structure.
6.	If Wbemtest returns an error, click the More Information button and check the Description property for a description of the error.
7.	For methods, check that your driver supports handling the IRP_MN_QUERY_ALL_DATA and IRP_MN_QUERY_SIGLE_INSTANCE requests for the method’s GUID. WMI always performs one of those two requests before executing a method.

7.3. Driver’s WMI Events Are Not Being Received

Use the following steps if the driver’s WMI events are not being received:

1.	Check the system event log for errors. For example, if the driver specifies a static event name when calling IoWMIWriteEvent but the driver did not register any static event names, this would produce an entry in the system event log.
2.	Check the WMI WDM provider log for errors. Note: If the driver is sending an event reference, the driver should receive an IRP_MN_QUERY_SINGLE_INSTANCE request immediately after sending the event reference. If the driver does not receive the IRP, the WNODE_EVENT_REFERENCE structure may have been malformed. If the driver receives the IRP, it should be completing it with status STATUS_SUCCESS.
3.	If the driver uses IoWMIWriteEvent to send the event or event reference, make sure the event structure (either WNODE_SINGLE_INSTANCE or WNODE_EVENT_REFERENCE) is filled out correctly. In particular, if the event GUID is registered for static instance names, make sure that the correct instance index and provider ID are provided. If the event GUID is registered for dynamic instance names, make sure the instance name is included when the event is sent. If using the WNODE_EVENT_REFERENCE structure to specify the event, check that Wnode.Guid matches TargetGuid.
4.	If the driver uses WmiFireEvent to send the event, make sure the correct value is passed for the Guid and InstanceIndex parameters.

7.4. Changes in Security Settings for WMI Requests Do Not Take Effect

If the changes we made in security settings for WMI Request do not take effect, you should do the following.

Unload and reload the WMI WDM Provider. For WMI data blocks registered with the WMIREG_FLAG_EXPENSIVE flag, the provider keeps a handle open to the data blocks as long as there are consumers for that block. The new security settings will not take effect until the provider closes the handle. Unloading and reloading the provider makes sure the handle has been closed.