Writing WMI provider in a day


Writing WMI provider in native code has steep learning curve. It involves writing MOF files and implementing methods from IWbemServices and IWbemProviderInit interfaces. Sometimes it becomes difficult and time consuming to debug issues in the WMI provider.


WMI.Net Provider Extension 2.0 was first introduced in Visual studio 2008 and is part of .Net Framework 3.5. It is based on the attribution model where MOF files are generated automatically and developers doesn’t have to implement any of the methods from the IWbemProviderInit or IWbemServices interfaces. Attributes can be added at the assembly, class, properties or method levels to specify what part of the managed application exposes WMI functionality. WMI.Net Provider Extension 2.0 generates MOF file and register it automatically based on the information provided in the attributes.


WMI.Net Provider Extensions 2.0 can be used to write both coupled providers and decoupled providers. There is a very good article on writing coupled providers here .


Writing WMI Providers in WMI.Net Provider extension 2.0 is fairly easy to write and debug. To give an idea I was able to write my own Win32_Process class with extended functionality in less than a day.

Comments (8)

  1. a dev says:

    debugging this is a nightmare. WMI is poorly designed when it comes to debugging wmi providers.

  2. kmathur says:

    Do let us know if you have any suggestions to improve the debugging experience.

  3. bm says:

    WMI provider using System.Management.Instrumentation (WmiConfiguration) sucks. Writing is simple, but testing to see if it works is hell of a deal.

    I wrote a simple windows forms application and with a WMI provider class (very basic with a key and two readonly properties), installed it using installutil and then published the instance of the class. Wbemtest wouldn’t show any instances. No matter what i tried.

    However if I use Instrumented attribute and associated classes, it works.

    I can’t figure out what is it that I am missing.

  4. mabra says:

    Hi !

    Thanks for this pointer!

    But:This is a badly written article, because it starts very deep, giving you no chance to understand the code without first studying the SDK … do I have to implement my own process, or not?? Ok, I am searching …

    Although WMI is very important and generally a good thing, it is – facing it’s complexity – a underdocumented thing. This moment, I was looking for all classes which are singletons:You have no hope with the SDK [no overviews/tables with details]. As alway, I stranded to write the next hack ….

    MS should really start to make some quality control [not only for the software, but for their articles also!] and finally implement the wmi properties, administrators are looking for [yes, the huge amount of NULL values, like fileCRC, stati – withound end!].

    And it looks like, MS is interested mostly to have a good layer for SMS/MOM and so important providers [compare windows xp to server 2003] are removed, which could admins a good help!

    Just my two cents. I am using WMI sinde the beginning.

    br–mabra

  5. wayne says:

    the article and frankly all information around this topic is a disaster. there isn’t any books on the subject which means you have to try make sense out of examples that are messy and miss out valuable information. there are no step by step guides only fragments of code which then are thrown together in make shift examples that cannot be followed or understood. the codeproject have the best examples but even they are not clear about elements to the technology that need to be understood to succeed

  6. John P. Grieb says:

    I’m trying to create a WMI Coupled Provider within a Windows Forms application using the information from the article at http://msdn.microsoft.com/en-us/library/cc268228.aspx and I’m having a problem implementing the GetInstance method. Any suggestions or examples on how I can do this?

  7. brant says:

    The WMI.Net Provider Extension 2.0 makes it easy to expose data from your application, but it is poorly documented and very fragile. I created a decoupled provider and found that calling a method (management task) doesn't work for WMI entity singletons and throws an ExecutionEngineException. It does the same for multi-instance WMI entities when you call the method on anything but the first instance. Any problems end up hanging your application (and also block future queries using wmic). We found that adding WMI.NET instrumentation to our services added instability when we were adding it to help identify stability issues. I don't see lots of people complaining about stability of the WMI.NET extensions, so I'm sure if we're doing something wrong (which is hard to know because the documentation is so slim) or whether nobody is using it. Very frustrating. Is anyone else running into these kinds of issues?

  8. Phil says:

    WMI should be run over with a steam roller. I would like to know what insane person would ever put this out there for people to struggle and pull there hair out figuring this thing out. Without examples – good luck!