Blog Post

Ask The Performance Team
3 MIN READ

Memory and Handle Quotas in the WMI Provider Service

CraigMarcho's avatar
CraigMarcho
Icon for Microsoft rankMicrosoft
Mar 16, 2019
First published on TECHNET on Sep 16, 2008

Hi folks, Mark Ghazai here once again with a quick tidbit on tweaking the WMI Provider Service (WMIPRVSE.EXE).  We’ve been getting some calls recently about the performance of this service and some failures that customers have been experiencing – in particular “Out of Memory” errors when certain WMI-related tasks are running.  We’ve talked about various memory management issues in previous posts, but the WMI Provider Service has some interesting quotas that administrators should be aware of.  So, as the saying goes … tally ho!

Within the WMI System Classes there is a configuration class for host provider processes.  The name of this class is _ProviderHostQuotaConfiguration.  This class allows limits to be set on host process usage of system resources.  The different properties available are:

  • ThreadsPerHost: Defines the number of threads owned by any one host
  • HandlesPerHost: Defines the number of kernel object handles each host may have
  • ProcessLimitAllHosts: Defines the total number of host processes that can be executing concurrently
  • MemoryPerHost: Defines the amount of private memory that can be held by each host
  • MemoryAllHosts: Defines the combined amount of private memory (in bytes) that can be held by all hosts

When the WMI Provider service reaches its quota limit, WMI queries that are being handled by that instance of WMIPRVSE.EXE will most likely fail.  However, there are applications like System Center that may require more memory or handles for the process.  These quotas are configurable, however – do not modify these quotas for the sake of modifying them !  If the WMIPRVSE.EXE process is actually leaking handles or memory, modifying the quota will only delay the issue from occurring, not eliminate it.  In instances such as these, normal leak troubleshooting must be performed to identify the root cause.

That having been said, if you are in a situation where there is a need to modify these values, you can do so using the steps below:

  1. Go to Start--> run and type wbemtest.exe
  2. Click Connect on the Windows Management Instrumentation Tester
  3. In the namespace text box just enter "root" (without quotes)
  4. Click Connect

    Note: you aren’t connecting to CimV2 or any other namespaces. It’s ROOT

  5. Click "Enum Instances…"

  6. In the Class Info dialog box enter Superclass Name as "__ProviderHostQuotaConfiguration" (without quotes) and press OK.

  7. A query Result window will come up. In this windows now double click "__ProviderHostQuotaConfiguration=@"

  8. An Object Editor windows will come up now
  9. Under properties find the property "MemoryPerHost" or any other ones you need to modify and double click it

    <In the case of modifying the memory quota;>

  10. Change the value to 512 MB which is 536870912
  11. Click Save Property
  12. Click Save Object in the Object Editor window
  13. Close the other windows now and exit WMI Tester
  14. Restart the machine.

A quick note here - on Windows XP and Windows Server 2003 systems, the memory quota per host is 128MB.  For Windows Vista and Windows Server 2008 systems the memory quota per host is 512MB.  The rest of quotas are all the same.  And, with that, it’s time to bring this post to a close.  Take care!

Additional Resources:

- Mark Ghazai

Share this post :
Updated Mar 16, 2019
Version 2.0
leak
memory management
Performance
wmi
  • MS_PerfGuy's avatar
    MS_PerfGuy
    Icon for Microsoft rankMicrosoft
    Sep 29, 2022

    Hi Julius, 

    When wmiprvse hits quota limit that instance will stop working and get closed out. There is not really a way to use troubleshooting efforts prior to know if we are leaking handles in my opinion since it will close out when limit is reached or do we simply have a demand for more handles that is not a leak. What I always did in those cases was to double the quota handle limit and monitor the handle count to see if it satisfied handle usage requirement and if it didn't and I hit the new quota limit, then I was pretty sure had a handle leak. In the later, now turn to troubleshooting. 

    Here is link of the blog series I did for different scenarios and there is one there for high handle count. They are dated and would not go the route of using debugger and htrace. Would do the gflags and then get process dump, but of course would most likely need Microsoft to look at the dump. Sometimes you can just use process explorer and right click on the instance of wmiprvse with high handle count and click on provider type and see if the provider running in that instance is something like ccm or event log provider to give you quicker clue to who is the culprit. Like in instance of event log usually a 3rd party doing heavy querying to the logs or someone has made the log size larger and it now takes longer or more expensive query to get thru all the entries when querying the event log.  You can also use Windows Performance Recorder tracing and analyze with Windows Performance Analyzer with the handle profile as a more up-to-date method to try and determine cause of leak. 
    https://techcommunity.microsoft.com/t5/ask-the-performance-team/bg-p/AskPerf/label-name/wmiseries 

  • JuliusPIV's avatar
    JuliusPIV
    Brass Contributor
    Aug 02, 2022

    Hey there CraigMarcho !  Thanks for bringing this old post over.  In the original post written by Mark Ghazai (back in his PFE Days!), Mark says (emphasis added):

    If the WMIPRVSE.EXE process is actually leaking handles or memory, modifying the quota will only delay the issue from occurring, not eliminate it.  In instances such as these, normal leak troubleshooting must be performed to identify the root cause.

    What exactly is "normal leak troubleshooting"?  Can you shed some light on that or perhaps point readers in the right direction?  Any chance we can tease that information out from Mark? 😁

    Many Thanks!