Manifest-based (PerfLib V2) performance counters show only GUID in Performance Monitor on Windows Server 2025 — possible duplicate of known WS2025 regression

Question

Product / Environment:

• OS: Windows Server 2025 (LTSC), build 10.0.26100.32684
• Application: [Mediaroom] - Windows Installer (MSI)-based deployment that registers multiple manifest-based performance counter providers via lodctr.exe /m:"<name>.man" during install (approx. 25+ separate providers, one .man file each)

Summary: After a clean installation on Windows Server 2025, all of our manifest-based performance counter providers register successfully according to the installer log, but they are not usable in Performance Monitor: the object appears only as a raw provider GUID (no friendly name), and expanding it to view counters fails with "Can't load counters." This matches the signature of a known Windows Server 2025 regression reported in a Microsoft Q&A thread (referenced below) for a different product (Configuration Manager), and we would like to confirm whether we are hitting the same root cause.

Evidence from our install log: For every provider, the deferred custom action log shows successful registration, e.g.:

Executing op: CustomActionSchedule(Action=RegisterPerfmonManifest,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData="lodctr.exe" /m:"C:\Program Files\xxx\manifest\PerfCounters\Syncserver.man"
Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIxxxx.tmp, Entrypoint: CAQuietExec

CAQuietExec:

CAQuietExec: Info: Successfully installed performance counters from file "C:\Program Files\<Our Product>\manifest\PerfCounters\Syncserver.man".

This pattern repeats with a "Successfully installed" result for every one of our ~25 .man manifests, with no errors, no non-zero return codes, and no privilege issues (MSI_LUA logs confirm the custom actions ran "with sufficient privileges").

Symptom:

• Open perfmon.exe, Add Counters
• The provider is listed only as its raw GUID (e.g. {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}), not by its intended friendly name
• Expanding it, shows no counters (Cant load counters)

Confirmed workaround (no file replacement required): From an elevated, interactive Command Prompt, re-running:

unlodctr.exe /m:"C:\Program Files\<Our Product>\manifest\PerfCounters\<Name>.man"

lodctr.exe /m:"C:\Program Files\<Our Product>\manifest\PerfCounters\<Name>.man"

immediately resolves the issue for that provider — the friendly name and counters then appear correctly in Performance Monitor. No files (e.g., loadperf.dll) needed to be replaced.

Things we've ruled out:

• Not a permissions/UAC issue (installer log confirms elevated context throughout)
• Not a corrupted/incorrect manifest (same manifest, re-registered manually, works)
• winmgmt /resyncperf does not resolve the issue (expected, since this is PerfLib V2 registration and does not go through the WMI/PerfLib bridge that command refreshes)

Suspected root cause: Based on the above, we suspect this is a name-resolution/enumeration failure between PerfLib and PDH (pdh.dll) — the raw provider registration succeeds, but something in the provider-list/name-string cache consumed by PDH during Performance Monitor's enumeration is not refreshed when many providers are registered in rapid succession within an MSI deferred custom action context (all ~25 of ours register within a few seconds during install). A manual, isolated re-registration outside of that context appears to correctly trigger whatever cache/notification step is missing.

Reference to a possible duplicate: We found a Microsoft Q&A thread describing what appears to be the same underlying symptom on Windows Server 2025 - a performance counter provider (SMS_INVENTORY_DATA_LOADER, used by Configuration Manager) that registers successfully in Perflib but remains invisible to PDH enumeration: https://learn.microsoft.com/en-us/answers/questions/5807044/log-flooding-counterthreadproc-mifs-min-counter-mi

In that thread, a Microsoft engineer confirmed it as a known issue in Windows Server 2025 (and future OS builds), stated that a fix has been developed but did not meet the bar for backporting to the already-released OS, with no ETA earlier than autumn 2026.

Questions for Microsoft:

1. Can you confirm whether our issue and the one described in Q&A thread 5807044 share the same root cause / are tracked under the same internal bug? If the answer is yes,
   1. Is there an official KB article or public tracking ID for this issue that we can reference for our own customers?
2. Is there a supported workaround or hotfix currently available (outside of manually re-running unlodctr/lodctr after install)?
3. Can you confirm/update the expected fix or backport timeline?

Answer 1

Hi Jiaqi,

Your findings are consistent with the Windows Server 2025 performance-counter issue discussed in the Q&A thread you referenced. A Microsoft employee confirmed in July 2026 that the referenced behavior is an issue in Windows Server 2025 and related OS code, that a fix has been developed, but that there was no committed ETA earlier than autumn 2026.

However, based on the public information, we cannot confirm that your PerfLib V2 providers are tracked under the exact same internal bug ID. That requires Microsoft engineering/support confirmation.

Your workaround is also significant: because the same .man file works immediately after unlodctr /m followed by lodctr /m, this strongly suggests a registration/enumeration issue rather than an invalid manifest or simple permissions problem.

Regarding your questions:

1. There does not appear to be a public KB or tracking ID confirming that your scenario and the ConfigMgr issue are the same internal bug.
2. I would continue using your unlodctr/lodctr workaround if it is reliable in your testing. I would not copy/replace Windows Server 2025 system DLLs based on the ConfigMgr workaround, because that workaround was specifically implemented inside the ConfigMgr directory rather than replacing the OS files.
3. The latest public Microsoft response in the referenced thread says the Windows fix was developed but gave no firm release date, only “no earlier than this autumn.”

Given that you have a clean reproduction with ~25 manifest providers, I recommend opening a Microsoft Unified Support case and providing the manifests, MSI registration logs, before/after lodctr results, and exact reproduction steps. Microsoft Support can then confirm whether your case maps to the existing internal bug and provide the current fix/backport status.