Thanks — good, clear report. Short answers up front, then a practical troubleshooting + prevention checklist you can follow.
Short summary
- Most likely cause: the IIS “Web Service” and “Web Service Cache” performance objects are getting de-registered or their PerfLib/INI registration becomes corrupted (Perflib/PDH state or missing/altered PerfStringBackup.INI / winsxs INI entries). Windows will stop showing counter sets when the performance counter library for that service fails or is disabled in the registry. Microsoft documents this exact failure mode and the usual repair is to rebuild the counters with lodctr /r (or restore a good PerfStringBackup.INI).
- This is not usually an IIS runtime problem (requests continue to be served) — it’s a perf-counter registration/Perflib problem. Similar IIS/perf counter problems have shown up after updates/servicing in the field, so an update/servicing or a component that writes the Perf registry is a plausible trigger.
- You can detect and repair it non-destructively (lodctr /r, verify registry DisablePerformanceCounters, restore PerfStringBackup.INI). If it recurs automatically you should capture the Event Log entries (IIS-W3SVC-PerfCounters, Perflib) and open a Microsoft support case.
Detailed answers and actions
1) Why do these two specific IIS counter sets disappear?
- Perflib/PDH registration issue: Performance counter sets are provided by a “performance library” installed/registered by the IIS feature. If the Perf library for the IIS Web Service fails to register (or Perflib detects repeated errors) the object can be removed/disabled from the list PerfMon/PDH returns. Microsoft’s guidance calls out exactly this symptom (missing counters, event IDs from IIS-W3SVC-PerfCounters or Perflib) and points to registry/PerfStringBackup.INI corruption or missing winsxs INI files as common causes.
- Corruption or deletion of the PerfStringBackup.INI or winsxs registration files used by lodctr. The IIS perf counters are installed via INI stub files in the component store (winsxs); if those INI records are missing or the PerfStringBackup.INI is truncated, lodctr /r may not restore them.
- A Windows update / servicing regression or a component (WMI-based tool, management software, installer) that writes the Perflib registry can cause counter sets to be corrupted or disabled. Community/triage reports show IIS-related counter or localhost/IIS regressions after servicing on some platforms — while not a single Microsoft KB that says “Web Service counters disappear on Server 2022”, servicing-caused regressions are a known pattern to watch for.
2) Is this a known issue in Windows Server 2022 IIS performance counters?
- There is no single, widely-published Microsoft KB that says “these two IIS counters vanish after X days on Server 2022” (I checked Microsoft troubleshooting docs for missing counters and community reports). However, Microsoft’s perf-counter troubleshooting doc describes the exact failure mode (counters missing because of Perflib/registry corruption) and the community has reported IIS-related regressions after some updates/servicing. So the behavior you observe matches documented perf-counter corruption symptoms and known update/servicing regressions in the wild, even if there isn’t one narrow KB that names “Web Service / Web Service Cache disappear on Server 2022” as a product-wide bug.
3) Recommended steps to prevent the counters from getting unregistered (practical)
Immediate detection and single-server repair (safe, non-destructive)
- Check presence quickly:
- PowerShell:
Get-Counter -ListSet "Web Service*" or Get-Counter -ListSet * | Where-Object CounterSetName -like 'Web Service*'
- Check Event Logs for the trigger:
- Look in Application log for sources: Microsoft-Windows-IIS-W3SVC-PerfCounters and Perflib (Event ID examples: IIS-W3SVC-PerfCounters 2002; Perflib / PDH errors). If you see these, capture the timestamps + full messages.
- Rebuild perf counters (admin elevated):
lodctr /r- Verify
perfmon / Get-Counter again.
- If
lodctr /r does not restore the IIS counters, compare or restore C:\Windows\System32\PerfStringBackup.INI from a known-good server (or from your backups) and run lodctr /r again. Microsoft documents using lodctr /r and backing up/restoring PerfStringBackup.INI for stubborn cases.
Prevention and monitoring
- Monitor the Application event log for Perflib / IIS-W3SVC-PerfCounters errors and set an alert so you catch the issue when the counters first fail.
- Schedule a lightweight verification script (PowerShell) as a health-check: e.g., run hourly/daily a small script that checks
Get-Counter -ListSet "Web Service" and, if missing, runs an automated recovery action (log event, run lodctr /r, and optionally restart W3SVC or run iisreset) — only do an automated restart after you’ve validated lodctr /r in a test environment.
- Keep a clean copy of PerfStringBackup.INI (and consider storing a copy of the relevant winsxs INI files for IIS on a secure share) so you can restore them quickly if they’re truncated.
- Track servicing/patches: if this starts after an LCU/SSU or cumulative update, test the update in a staging ring and keep the captured Event Log evidence — if repeatable, open an MS support case. Community threads show IIS regressions have correlated with particular servicing in the past.
Longer-term fixes if the problem recurs
- If rebuilding counters doesn’t hold, consider scripting a protected restore (backup PerfStringBackup.INI, run lodctr /r on a schedule) and/or file a Microsoft Support case with the Event Log + time samples so Microsoft can investigate a servicing regression.
- As a last resort the IIS role remove/reinstall (what you already used) will re-register the counters; but that’s disruptive — prefer repairing Perflib first.
4) Which logs/components handle registration/unregistration of IIS counter sets?
- Perflib / Performance Counter subsystem (PDH/Perflib) — this is the Windows component that exposes and manages counters and can disable counters that generate errors. If Perflib observes repeated library errors it will disable the counters and you will see Perflib / IIS-W3SVC-PerfCounters events in the Application log. The Microsoft troubleshooting doc explains the Perflib/registry/INI interactions.
- Registry location for per-service performance settings: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<servicename>\Performance — a DisablePerformanceCounters value here (or missing/corrupt values) can cause the counters to be turned off. Microsoft docs point you to check these keys when counters are missing.
- PerfStringBackup.INI and the winsxs INI files used by lodctr — lodctr rebuilds from the PerfStringBackup.INI and from component INI entries under the component store; if those are missing/corrupt the counters won’t be restored.
- The IIS installer/feature scripts (when you install the Web-Server role) register the counters initially; any tool that modifies the registry (WMI-based tools, installers, some third-party monitoring/agent software) can inadvertently corrupt Perflib registrations. Community cases often show WMI or third-party agents involved in similar symptoms.
Concrete troubleshooting checklist you can copy/paste (run as Administrator)
1) Quick check
- PowerShell:
Get-Counter -ListSet "Web Service*"Get-EventLog -LogName Application -Source "IIS-W3SVC-PerfCounters","Perflib" -After (Get-Date).AddDays(-7)
2) Repair (non-destructive)
- Backup PerfStringBackup.INI:
copy C:\Windows\System32\PerfStringBackup.INI C:\temp\PerfStringBackup.INI.bak
- Rebuild:
- Verify:
Get-Counter -ListSet "Web Service*"
3) If rebuild fails
- Copy PerfStringBackup.INI from a known-good same-OS server (only if you understand the differences) and run
lodctr /r again. (Always keep backups.
- Inspect registry:
reg query "HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Performance"- Look for
DisablePerformanceCounters — value should be 0 or not present.
4) If it still reoccurs repeatedly
- Capture full Application event logs around the time counters disappear.
- Put the simple detection script + a webhook/email alert in place.
- Open a Microsoft Support case with the logs and timestamps (this gives Microsoft the data needed to triage a servicing regression).
Why your reinstall workaround “fixes” it
- Removing & reinstalling the IIS role forces the IIS performance DLL/INI to be re-registered in the component store/Perflib registry, which is why the counters come back. That’s consistent with the “registration/corruption” theory (but it’s heavier-weight than a lodctr repair).
References (useful reading)
- Microsoft: “Manually rebuild performance counters” (describes lodctr /r, PerfStringBackup.INI, and registry checks).
- Microsoft Q&A / community troubleshooting threads for Event IDs 2002 / Perflib errors.
- Notes that IIS exposes “Web Service” and “Web Service Cache” as perf objects (tools which rely on PDH / perfmon list these objects).
- Community reports on IIS/localhost and related regressions after servicing (useful context that updates can cause surprising side effects).
If you’d like, I can:
- Provide a small PowerShell health-check + auto-repair script you can run as a scheduled task (checks for Web Service / Web Service Cache and runs lodctr /r + logs the repair), or
- Help analyze your Application Event Log around the time the counters went missing (paste the relevant Event entries) to look for the exact trigger.
Which would you prefer?
