NSClient - ERROR: Failed to get PDH value ERROR: Could not get data for 5 perhaps we dont collect data this far back?

— ny_wk

The NSClient++ "Failed to get PDH value" / "Could not find counter" error almost always means the Windows performance counter (PDH) registry on the monitored host is corrupted, disabled, or out of sync. Rebuilding the counters with lodctr /R, re-syncing WMI performance data, and restarting the NSClient++ service fixes the vast majority of cases. The guide below walks through every realistic root cause and a tested, step-by-step repair so your Nagios or Icinga CPU, memory, and uptime checks return to OK.

What the error looks like

When Nagios or Icinga polls a Windows server through NSClient++ and the underlying Performance Data Helper (PDH) layer fails, your monitoring system stops receiving usable values. The service state flips to UNKNOWN rather than CRITICAL, because the agent cannot read the metric at all. Typical alert text includes:

• NSClient - ERROR: Failed to get PDH value
• NSClient - ERROR: Could not get data for 5 perhaps we dont collect data this far back?
• NSClient - ERROR: Could not get value
• ERROR: Could not find counter: \Processor(_Total)\% Processor Time

These messages appear on checks such as CPU Usage, Memory Usage, and Uptime — exactly the checks that depend on Windows performance counters. A revealing companion symptom: open perfmon (Performance Monitor) directly on the affected host and you will often see empty counter lists, missing objects, or an error when adding counters. If perfmon itself is broken, NSClient++ never had a chance.

Root causes of the PDH counter failure

The same error string can come from several distinct underlying problems. Identifying which one you have saves a lot of guesswork.

1. Corrupted PDH performance counter registry

Windows stores counter names and indexes under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib. Software installs/uninstalls, .NET updates, SQL Server, IIS, or an aborted patch can leave this database inconsistent. When the index no longer matches the counter text, PDH cannot resolve a query and NSClient++ reports Failed to get PDH value.

2. Performance counters disabled in the registry

Individual counter providers can be flagged disabled. If you query the counters and see something like [PerfOS] Performance Counters (Disabled), the operating-system performance object (which feeds CPU and memory metrics) is switched off, so the agent has nothing to read. This is a common state after "performance counter" troubleshooting articles tell people to disable counters to fix a different problem.

3. Localized counter names

NSClient++ checks often reference English counter names like \Processor(_Total)\% Processor Time or \Memory\Available Bytes. On a German, French, Spanish, Japanese, or other non-English Windows build, the counter names are translated (for example \Prozessor(_Total)\Prozessorzeit (%)). A literal English name then resolves to Could not find counter. This is one of the most overlooked causes on international servers.

4. 32-bit vs 64-bit mismatch

On 64-bit Windows there are two parallel counter sets. A 32-bit process can only read 32-bit counters, and a 64-bit process reads 64-bit counters. If you run the 32-bit build of NSClient++ on a 64-bit OS (or vice versa) and the matching counter set is broken or absent, PDH queries fail even though perfmon (64-bit) looks fine. The fix involves rebuilding both the 64-bit and the WOW64 32-bit counters.

5. WMI / performance library out of sync

Windows keeps a separate WMI performance class layer (the Win32_PerfFormattedData_* classes) that mirrors the raw counters. If the WMI performance cache is stale or corrupt, checks that route through WMI return no data even when the raw PDH store is healthy.

6. Permissions and service account

Reading performance data requires membership in the Performance Monitor Users group (and, for some counters, Performance Log Users). If NSClient++ runs under a restricted account rather than Local System, it may be denied access to the PDH provider and surface the same generic error.

7. NSClient++ configuration (CheckSystem / PDH module)

NSClient++ must have the right collector module loaded. If CheckSystem (legacy) or the modern PDH collector is not enabled in nsclient.ini, or if its counter buffer has not filled yet, you will see "Could not get data for 5 perhaps we dont collect data this far back?" — the agent is being asked for a 5-interval average it has not yet accumulated.

Step-by-step fix

Work through these in order. Perform every step on the monitored Windows host (the one running NSClient++), not on the Nagios/Icinga server. Most steps require an elevated command prompt.

Step 1: Confirm the failure is local

1. Log on to the affected Windows server.
2. Open Run and launch perfmon.
3. Try to add counters for Processor and Memory. If the objects are missing or you get an error, the counter database is the problem and the rebuild below will fix it.

Step 2: Rebuild the performance counters with lodctr /R

This is the single most effective fix and resolves the majority of "Failed to get PDH value" cases.

1. Click Start, type cmd, right-click Command Prompt and choose Run as administrator.
2. Change into the system directory: cd /d C:\Windows\System32
3. Rebuild the counter database from the registry baseline: lodctr /R
   (Use a capital /R. This rebuilds all performance counters from the cached settings. It can take a minute, so let it finish.)
4. On 64-bit Windows, also rebuild the 32-bit (WOW64) counters from the SysWOW64 folder: cd /d C:\Windows\SysWOW64 then lodctr /R

Tip: If lodctr /R returns "Unable to rebuild performance counter setting from system backup store, error code is 2", run it again, or first restore from a known-good .ini with lodctr /S:perfstringbackup.ini and then re-run the rebuild.

Step 3: Verify what got rebuilt

1. Query the counter database: lodctr /Q
2. Inspect the output. A healthy provider looks like this:
   • [PerfOS] Performance Counters (Enabled)
   • DLL Name: %SystemRoot%\System32\perfos.dll
3. If a provider you need shows (Disabled) — for example [PerfOS] Performance Counters (Disabled) — continue to Step 4 to re-enable it.

Step 4: Re-enable disabled counters in the registry

If PerfOS or the global Perflib is disabled, CPU and memory collection is blocked. Set the disable flags back to zero.

1. Open regedit as administrator.
2. Navigate to HKLM\SYSTEM\CurrentControlSet\Services\PerfOS\Performance and set the value Disable Performance Counters to 0. (If the value does not exist, the counters are not explicitly disabled — leave it.)
3. Navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib and set Disable Performance Counters to 0.
4. Repeat for any other provider that showed (Disabled), e.g. ...\Services\PerfProc\Performance (process counters) and ...\Services\PerfDisk\Performance.

You can do the same from an elevated prompt without regedit:

1. reg add "HKLM\SYSTEM\CurrentControlSet\Services\PerfOS\Performance" /v "Disable Performance Counters" /t REG_DWORD /d 0 /f
2. reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib" /v "Disable Performance Counters" /t REG_DWORD /d 0 /f

Step 5: Re-sync the WMI performance layer

After rebuilding the raw counters, refresh the WMI performance classes so WMI-based checks match.

1. From the elevated prompt run: winmgmt /resyncperf
2. If WMI itself is suspect, verify the repository: winmgmt /verifyrepository (only run winmgmt /salvagerepository if it reports inconsistency).

Step 6: Restart the affected services

1. Restart the performance/WMI plumbing and the agent: net stop nscp && net start nscp (the NSClient++ service is named nscp on current builds; older builds use NSClientpp).
2. If counters still look stale, a full reboot guarantees every provider DLL reloads against the rebuilt index. On production servers a reboot is frequently the cleanest finish to a counter rebuild.

Step 7: Check and correct nsclient.ini

Confirm NSClient++ is actually configured to collect system counters. Open C:\Program Files\NSClient++\nsclient.ini and ensure the relevant modules are enabled:

1. Under [/modules], enable the system collector: CheckSystem = enabled (this loads CPU/memory/uptime collection). For NRPE-based setups also confirm NRPEServer = enabled; for legacy check_nt confirm NSClientServer = enabled.
2. Confirm the allowed hosts list includes your monitoring server, e.g. under [/settings/default]: allowed hosts = 10.0.0.0/8,127.0.0.1
3. If you use custom PDH counters, define them under [/settings/system/windows/counters] with the exact counter path, for example: cpu = \Processor(_Total)\% Processor Time
4. Save the file and restart the service (Step 6). NSClient++ needs a few collection intervals before "5"-sample averages become available — wait 1-2 minutes before re-testing CPU.

Step 8: Handle localized (non-English) Windows

If the server's display language is not English, do not hard-code English counter names. Instead:

• Use the numeric counter index path, which is language-independent. Map English names to indexes with the registry under ...\Perflib\009 (English) versus ...\Perflib\CurrentLanguage.
• Or rebuild the English counter strings: lodctr /R followed by adding the English (009) language so PDH can resolve both.
• In NSClient++, prefer the built-in check_cpu / check_memory commands (which use indexes internally) over raw English counter paths.

Common pitfalls to avoid

• Running the fix on the wrong machine. The counters live on the monitored Windows host. Running lodctr on the Nagios/Icinga server does nothing.
• Forgetting the 32-bit set. On 64-bit Windows you must rebuild from both System32 and SysWOW64, otherwise a 32-bit NSClient++ build still fails.
• Using lowercase /r inconsistently. The switch is case-insensitive on modern Windows, but always confirm with lodctr /Q that providers came back Enabled — do not assume.
• Testing immediately after restart. Averaged counters (CPU over 5 samples) need time to accumulate. The "don't collect data this far back" message is normal for the first minute or two after a restart and clears on its own.
• Ignoring permissions. If NSClient++ runs as a non-system account, add it to Performance Monitor Users; otherwise the rebuild succeeds but the agent is still denied.
• Disabling counters as a "fix." Setting Disable Performance Counters = 1 stops the noise but also stops monitoring. Re-enable (value 0) for real metrics.
• Skipping the WMI resync. If your checks route through WMI rather than raw PDH, the counter rebuild alone may not be enough — run winmgmt /resyncperf too.

Verification: confirm the checks return to OK

Validate the repair from the monitoring server so you are testing the full path, not just local perfmon.

Test with check_nt (NSClient legacy / port 12489)

1. CPU: ./check_nt -H 10.146.19.70 -p 12489 -v CPULOAD -l 5,80,90
2. Memory: ./check_nt -H 10.146.19.70 -p 12489 -v MEMUSE -w 80 -c 90
3. Uptime: ./check_nt -H 10.146.19.70 -p 12489 -v UPTIME

A healthy result returns text like CPU Load 4% (5 min average) | '5 min avg Load'=4%;80;90;0;100 instead of the PDH error.

Test with check_nrpe (modern NRPE / port 5666)

1. CPU: ./check_nrpe -H 10.146.19.70 -c check_cpu -a warning=load>80 critical=load>90
2. Memory: ./check_nrpe -H 10.146.19.70 -c check_memory
3. Basic connectivity / version: ./check_nrpe -H 10.146.19.70 (should print the NSClient++ version).

Finally, in Icinga or Nagios, reschedule the next check for CPU Usage, Memory Usage, and Uptime. They should transition from UNKNOWN back to OK within one or two check intervals.

Quick reference table

Key Takeaways

• Rebuild first: lodctr /R from an elevated prompt in System32 (and SysWOW64 on 64-bit) fixes most "Failed to get PDH value" errors.
• Always verify with lodctr /Q and re-enable any provider that shows (Disabled) by setting the registry disable flag to 0.
• Re-sync WMI with winmgmt /resyncperf when checks travel through WMI performance classes, then restart the nscp service.
• Watch for localization and bitness: non-English Windows breaks hard-coded English counter names, and 32/64-bit mismatch breaks PDH reads even when perfmon looks fine.
• Confirm the fix end-to-end from the monitoring host using check_nt or check_nrpe, not just local perfmon.

Frequently Asked Questions

Does lodctr /R delete my custom performance counters?

lodctr /R rebuilds the entire counter database from the registry baseline, which re-registers all installed providers. It does not erase application counters that are still registered, but a provider whose DLL or registry stub is missing will not reappear. After running it, re-register any third-party counters (for example via the application's installer or lodctr provider.ini) and confirm with lodctr /Q.

Why does CPU show "could not get data for 5" right after I restart NSClient++?

CPU load checks ask for a multi-sample (e.g. 5-minute) average. Immediately after a restart the agent has not yet collected enough samples to compute that window, so it warns that it does not collect data "this far back." Wait one to two collection intervals and the value populates normally. If it never clears, the counter itself is still broken.

The counters work in perfmon but NSClient++ still fails. Why?

Perfmon runs 64-bit, so it reads the 64-bit counter set. If your NSClient++ is the 32-bit build on a 64-bit OS, it reads the WOW64 set, which may still be corrupt. Rebuild from C:\Windows\SysWOW64 as well. The other common cause is permissions: a non-system service account must belong to the Performance Monitor Users group.

My Windows is in German/French/Japanese and the counter name is not found. What do I do?

Counter display names are localized, so an English path like \Processor(_Total)\% Processor Time will not resolve. Use the numeric counter index (language-independent) in your NSClient++ counter definition, or rely on the built-in check_cpu/check_memory commands, which resolve counters by index internally rather than by translated text.

For more Windows monitoring and sysadmin walkthroughs, subscribe to @explorenystream on YouTube.