Find the Binary File for Any WMI Class

One of the really frustrating aspects in troubleshooting any Windows Management Instrumentation (WMI) issue is trying to determine which binaries are responsible for supporting the hundreds of classes registered in any given system. Each class in WMI has a corresponding WMI provider, which is simply a COM object and usually in the form of a DLL binary. Since WMI providers are COM objects, the main task will be to find the GUID registered for the binary, then search the registry for that GUID.

One typical problem with WMI is high CPU utilization. You may have experienced a high-CPU problem where the WMIPrvse.exe process was spiking the CPU, and you might have even known what WMI query generated all the CPU activity. But how do you find the actual DLL binary responsible for the class being queried? And why is knowing the DLL important? Knowing the name and location of a DLL will provide you information such as which vendor the binary belongs to, which will enable you to find out whether updates are available for the binary and whether the problem you're experiencing is a known issue and has been fixed already. Simply doing an Internet search on "High CPU wmiprvse.exe" might return too many hits, none of which could be your problem. However, if you can include the exact DLL name in your search—for example, "high cpu wmiprvse provider.dll"—the search results are more likely to return more accurate and relevant information. Let's look at how to find the DLL binary for a WMI class by walking through an example.

Enabling Logging to Find the Class Namespace
The first step in finding the DLL of a particular class is to understand which namespace the class resides in. To accomplish this, we must enable logging. Here's how you do it.

For Windows Server 2003 and Windows XP: You can enable verbose logging through the WMI Control called WMIMgmt.msc. Click the control's Logging tab, then click the Verbose radio button. You'll notice entries in the Wbemcore.log file such as the following, indicating which namespace is being queried.

ConnectionLogin:NTLMLogin - wszNetworkResource = root\cimv2

For Windows Vista and Windows Server 2008: The logging mechanism is new in Windows Vista and Server 2008, which now have what are called Analytic and Debug logs. These logs have replaced the previous verbose logging in Windows 2003 and XP. For detailed steps on how to enable the WMI Analytic and Debug logs on Windows Vista and later, see the Windows Management Infrastructure blog post "Is WMIprvse a real villain?" at blogs.msdn.com/wmi/archive/2009/05/27/is-wmiprvse-a-real-villain.aspx.

For testing purposes, I've created a sample WMI class called InstProvSamp. In Figure 1, notice the event that logs the WMI query to the class (select * from InstProvSamp) and the namespace where the class resides (\\root\default).

Finding the Provider DLL
Now that we have the WMI class and namespace, we can start our search for the provider DLL. Every WMI class has a qualifier called provider, which is the name of the provider but not necessarily the binary name. We need to find out what the qualifier name is for our test class (InstprovSamp), and we can use wbemtest.exe to do so.

Run wbemtest.exe, connect to root\default, then click the Open Class button. Enter the class name—in our example, InstProvSamp. Click OK, and now notice that the Object editor opens for this class. As you can see in Figure 2, under the Qualifiers, there is a "provider" string called InstProvSamp. Here, the provider name is the same as the class name, but usually this isn't the case.