Condividi tramite

Writing WMI provider in a day

  • Articolo

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

  • Anonymous
    July 08, 2009
    debugging this is a nightmare. WMI is poorly designed when it comes to debugging wmi providers.

  • Anonymous
    July 23, 2009
    Do let us know if you have any suggestions to improve the debugging experience.

  • Anonymous
    October 02, 2009
    The comment has been removed

  • Anonymous
    November 11, 2009
    The comment has been removed

  • Anonymous
    December 16, 2009
    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

  • Anonymous
    December 27, 2009
    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?

  • Anonymous
    August 28, 2010
    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?

  • Anonymous
    December 17, 2015
    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!