[This is preliminary documentation and subject to change.]
This is a sample Plug and Play filter driver that provides WMI data blocks. Typically, driver writers will copy the sample code into their own driver and make any minor modifications so that the WMI data blocks are always available when the driver is loaded. Alternatively, WmiSamp can be left as a filter driver if WMI data blocks should only be made available when the filter driver is loaded.
Follow these steps to WMI-enable a driver with the sample code.
1. Determine what data needs to be provided and organize it into data blocks that contain related data items. For example, packets sent and bytes sent could be part of a single data block, while transmit errors could be part of a data block that contains other error counts. Determine if the device needs notification when to enable and disable collections in the case of data blocks that impose a performance hit to collect.
2. Write one or more Managed Object Format (.mof) files that describe the data blocks. In doing this, the driver writer will need to run the GUIDgen tool to create globally unique GUIDs that are assigned to the data blocks. GUIDgen must be run so that no two data block formats have the same GUID. Compile the .mof files into .bmf files by using the Mofcomp tool. The resulting .bmf files are platform-independent binaries, and can be reported as resources attached to the .sys file or as one or more instances of a data block queried by WMI. The former mechanism is useful for drivers with a static .mof and the latter for drivers with a dynamic .mof. For .mof data reported via a resource attached to the .sys file, reference the .bmf file in the driver's .rc file so that the .bmf file data is included as a resource of the driver's .sys file. For .mof data reported as instances of a data block, the .x files are included into the source of the driver as a global data buffer. Note that .x files are created by wmimofck.exe and are the ASCII representation of the .bmf file. It is possible that a driver reporting via the data block query mechanism could have many instances of the binary .mof data block and only report those that are appropriate depending upon the state of the device. See the USE_BINARY_MOF_QUERY definition for more information. Also note that one of the byproducts of generating the binary .mof file is a header file that contains GUID and structure definitions for the data blocks. Use this header because it will always be up to date with the .mof.
3. Build the WMIGUIDREGINFO structure with the GUIDs for the data blocks defined in the .mof file. If the device should be notified when to start and stop collection of a data block, the WMIREG_FLAG_EXPENSIVE flag should be set for the data block in the WMIGUIDREGINFO structure.
4. Implement the six WMI function callback routines and reference them in a WMILIB_CONTEXT structure. Note that some of them are optional.
5. Modify the sources and makefile.inc files so that the .mof file is compiled into the .bmf, .x, .vbs and .h file. Also check that USE_BINARY_MOF_QUERY is defined appropriately for the method of reporting MOF data.
Note: Another byproduct of compiling the .mof is a .vbs file. This is a VBScript file that is run from the command line on the target machine running the new device driver. It will cause WMI to query all data blocks and properties, and put the results into a .log file. This can be very useful for testing WMI support in your driver. For more sophisticated testing, the VBScript can be extended by hand. The WBEMTest tool (located in %windir%\system32\wbem\) can also be used.
Please see the Kernel-Mode driver section of DDK documentation for more information on WMI. WMI Mof Check Tool
WmiMofCk validates that the classes, properties, methods and events specified in a binary mof file (.bmf) are valid for use with WMI. It also generates useful output files needed to build and test the WMI data provider.
If the -h parameter is specified, a C language header file is created that defines the GUIDs, data structures, and method indices specified in the MOF file.
If the -t parameter is specified, a VBScript applet is created that will query all data blocks and properties specified in the .mof file. This can be useful for testing WMI data providers.
If the -x parameter is specified, a text file is created that contains the text representation of the binary .mof data. This can be included in the source of the driver if the driver supports reporting the binary .mof via a WMI query rather than a resource on the driver image file.
Usage: wmimofck -h<C Header output file> -x<Hexdump output file> -t<VBScript test output file> <binary mof input file>
File DescriptionFilter.c NULL filter driver (boilerplate code) Filter.h Header file for the filter driver Filter.mof Managed Object Format file that contains descriptions of the data blocks events and methods implemented by the driver Filter.rc Resource file containing version information Inf.txt Sections of the .inf file to change Makefile Standard Windows NT makefile Pnp.c Plug and Play routines Power.c Power Management routines Sources Sources for build Util.c NULL filter driver—boilerplate code Wmisamp.c Sample device driver that shows various mechanisms for using WMI in a kernel-mode driver
© 1999 Microsoft Corporation