Splitting up WMI Providers for Troubleshooting

Splitting up WMI Providers for Troubleshooting

  • Comments 3
  • Likes

Good Morning AskPerf!  My name is Jim Martin, and I am a Support Escalation Engineer on the Performance team.  In today’s post, we are going to take a look at splitting up WMI providers.  I had been working with some customers who were experiencing issues with slow SQL WMI queries.  Since WMI providers by default share the same WMIPRVSE process with other providers that need to run in the same security context, you can run into issues where a problem with one provider can cause issues with another one in the same hosting process.  The technique below can be used to help isolate which specific provider is responsible for a performance problem inside a specific instance of WMIPRVSE – a leak for example.  This technique does not replace some of our other troubleshooting techniques such as Process Explorer or ADPlus for diagnosing issues – but it is another handy tool to have in your bag of tricks!

In order to split them up you can change the HostingModel in the .mof file for the product/component you want to split out and recompile the .mof file.  Open up the .mof file and search for “HostingModel” (without the quotes).  Here is an example of the change for CIMWin32, but I would typically leave that one alone and change the .mof file for SQL or other component.  The mof file for SQL 2005 is sqlmgmproviderxpsp2up.mof.  The change would be almost identical in the SQL .mof file.  The name after the colon can be any character string from what I can tell, but I would not use special characters.  Then just recompile the .mof file using MOFCOMP, and restart WINMGMT.  Below is the original section of the file:

Instance of __Win32Provider as $P
{
  Name = "CIMWin32";
  ClsId = "{d63a5850-8f16-11cf-9f47-00aa00bf345c}";
  ImpersonationLevel = 1;
  PerUserInitialization = "FALSE";
  HostingModel = "NetworkServiceHost";
};

… this can be changed as shown below:

Instance of __Win32Provider as $P
{
  Name = "CIMWin32";
  ClsId = "{d63a5850-8f16-11cf-9f47-00aa00bf345c}";
  ImpersonationLevel = 1;
  PerUserInitialization = "FALSE";
  HostingModel = "NetworkServiceHost:CIMWin32";
};

Once you have made the changes and recompiled the .mof file, you can use Process Explorer to find out which instance of WMIPRVSE has the provider loaded by going to the Find menu option and entering the name of the DLL file.  If no results are returned, then the provider is not loaded.  This is a good way to test if you have been successful in splitting out the provider into its own instance.

clip_image001

Remember that this should only be used in very specific troubleshooting scenarios.  By creating multiple instances of of the WMIPRVSE process you are creating additional system overhead – if you leave the providers split out you may run into resource issues.

That’s it for today’s post.  Have a great Friday!

Additional Resources:

- Jim Martin

Share this post :


Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I appreciate your explanation was very good for such useful information on the benefits of our work

  • WMI  I have taught it when I'm at unversity

  • # ments are moderated. This helps us to avoid comment spam.

    # While we welcome active discu