A Day in WMI Debugging, The Case of the Missing Uptime

Today I encountered a puzzling issue while working with a monitoring setup: all components were reporting data — except system uptime. Everything else was fine: CPU, memory, disk — all metrics were flowing in smoothly. But the uptime metric stubbornly showed no data.

At first glance, it seemed like a data source glitch. But as always, when something defies logic, it’s time to dig into the internals.

Step 1: Testing WMI the Old-School Way

Since the system uptime metric comes from WMI, I decided to test the WMI query directly using PowerShell:

Get-WmiObject -ComputerName <TargetHost> -Class Win32_PerfRawData_PerfOS_System

To isolate permissions issues, I opened two separate PowerShell sessions:

• One using a Domain Admin account
• One running as the service account used by the monitoring tool

The Result? A Clear Discrepancy

• The Domain Admin session returned all the expected data, including the uptime counter.
• The Service account session returned nothing. No results. No errors. Just empty output.

This was the “aha” moment. It wasn’t a broken counter or a collector issue — it was a permissions problem.

Root Cause: Missing WMI and DCOM Rights

The service account, although functional for most monitoring, did not have permission to read some of the performance data classes via WMI. Specifically, it lacked access to:

• WMI namespace: root\cimv2
• DCOM launch and activation rights
• Proper Windows local group membership for performance monitoring

Fixing It: Giving the Service Account a Voice

Here’s what I did to fix it:

1. Granted WMI Namespace Permissions

On the target host:

1. Opened wmimgmt.msc
2. Went to WMI Control (Local) → Properties → Security
3. Selected root\cimv2
4. Added the service account with the following permissions:
   • Remote Enable
   • Read Security
   • Execute Methods

2. Configured DCOM Permissions

Using dcomcnfg:

1. Navigated to:
   Component Services → Computers → My Computer → Properties → COM Security

2. Edited Launch and Activation Permissions:

   • Added the service account
   • Allowed:
     • Local Launch
     • Remote Launch
     • Local Activation
     • Remote Activation

3. Added to Windows Groups

I added the service account to the following local groups on the target system:

• Performance Monitor Users
• Distributed COM Users

This ensures it has access to performance counters without requiring full administrator privileges.

4. Restarted Services

After applying the permissions, I restarted the WMI service on the target host:

net stop winmgmt
net start winmgmt

Note: A full system reboot is recommended if possible to ensure all permissions apply correctly.

The Final Test

I reran the same PowerShell command under the service account session:

Get-WmiObject -ComputerName <TargetHost> -Class Win32_PerfRawData_PerfOS_System

This time, it worked. The uptime data appeared as expected.

Shortly after, the monitoring system also reflected the change — system uptime was being reported correctly again.