|
|
DiskPerfWbem
The DiskPerfWbem sample surfaces disk performance information
produced by the DiskPerf driver using WMI. The driver produces disk partition performance
instrumentation data and exposes this data through a WMI interface. The information provided includes statistics
such as number of bytes read and written, number of read and write operations
performed and the time these operations took to complete. The DiskPerf driver is included as a sample
on the Windows 2000 Professional Beta 3 DDK and is also standard as part of the
Windows 2000 Professional Beta 3 operating system installation.
NOTE: The DiskPerf sample driver
was also present in the Windows 2000 Beta 2 DDK. While the DiskPerfWbem sample
application may also work with Windows 2000 Beta 2 and the Windows 2000 Beta 2
DDK version of the driver, it is highly recommended that Windows 2000 Beta 3
and the Windows 2000 Beta 3 DDK version of the driver be used.
Getting Started with the
DiskPerfWbem Sample
To use this sample, the following steps are required:
1)
Install Windows 2000 Professional Beta 3 operating system.
2)
Install the WMI SDK for Windows 2000 Professional Beta 3.
3)
Compile the sample application provided here, using the WMI SDK to
produce dpwbem.exe.
4)
If desired, the DiskPerf driver in the Windows 2000 Professional
Beta 3 DDK can replace the one from the operating system install. To do so, compile the DiskPerf driver in the
DDK substitute it for the standard driver.
5)
Open Device Manager.
Select Disk Drives and view properties via the Action menu. Choose the “Advanced” tab and check the
“Enable Disk Performance Counters” option.
6) Restart Windows
2000 Professional and run dpwbem.exe. You should now see instrumentation data
produced by the DiskPerf driver visible via the WMI application.
General Notes
Things
to remember when you're building your own WMI client application:
1.
If you want your client to
run on NT and non-DCOM versions of Windows 95, manually load the ole32.dll and
see if CoInitializeSecurity() exists. This routine won’t exist on Windows 95
installations that don’t have DCOM installed separately. If this routine
doesn't exist, the asynchronous routines in this sample won’t work because of
mismatched security level problems. The synchronous techniques will still work.
2.
If you don’t care about
non-DCOM versions of Windows 95, you can define _WIN32_DCOM so that CoInitializeSecurity() is available for
implicit linking. Don't use _WIN32_WINNT to get this prototype since it won't
compile under the Windows 95/98 operating systems.
3.
In any case, the
CoInitializeSecurity() call (in InitInstance()) is required to work around a
security problem when WMI trying to call a Sink object but won't identify
itself. The CoInitializeSecurity() call turns off the authentication
requirement.
4.
WMI interfaces are defined
in wbemcli.h and wbemprov.h found in the wmi\include directory. You may #include both these files by
including just wbemidl.h located in the same directory.
5.
WMI interface CLSIDs are
defined in wbemuuid.lib. If you get unresolved externals in interfaces and
CLSIDs, this is what is missing.
6.
You'll need to link with
oleaut32.lib and ole32.lib to get the needed COM support.
7.
In the Link|Output
settings, specify 'wWinMainCRTStartup' as the entry point. This is per the
Unicode programming instructions.
8.
If you're using the makefiles, don't forget to set the VC vars. In
VC++ 5.0, it is VCVARS32.BAT.