On a particular Vista machine, I was setting up a PerfMon view to monitor the .NET memory performance of an application and ran into a problem. The.NET Memory # Bytes in All Heaps Performance Counter wasn’t in the list of performance counters. That was quite odd so I checked if that Performance Counter was there in Process Explorer by adding it to the main window display. Since Process Explorer has all the Performance Counter names hard coded, that would tell me if the problem was with the Performance Counter Library itself as PerfMon builds the list dynamically.
After pressing OK, Process Explorer showed no values at all in the columns. That pretty much proved that there was something seriously wrong with the Performance Counters on that particular machine. Without those performance counters it’s pretty hard to do monitoring and performance tuning! Comparing two machines side by side, I noticed that the problem machine was missing a metric ton of other Performance Counters.
A few quick internet searches got me to the Microsoft KB article 300956, which discusses how to manually rebuild Performance Counter Libraries. If you read over that article, you start to get very scared very quickly because it tells you to manually replace files on the machine with the files from the installation CD, a bunch of manual registry editing, and so on. Fortunately, at the end of the article, they mention that running LODCTR /R from an elevated prompt (note the /R uppercase is required) will rebuild the Performance Counter Library including third party and extension performance counters.
Figuring I had nothing left to lose, I gave it a run. After shutting down PerfMon and Process Explorer, I restarted both and was very happy to see all the Performance Counters reappeared. After a big sigh of relief, I thought I’d write up what worked in case you are missing some Performance Counters. Of course, this advice comes with the usual Internet warning: Worked on My Machine ™.
Microsoft Azure and Amazon Web Services (AWS) are two of the most popular cloud platforms.…
Cloud management is difficult to do manually, especially if you work with multiple cloud…
Azure’s scalable infrastructure is often cited as one of the primary reasons why it's the…
https://www.youtube.com/watch?v=wDzCN0d8SeA Watch our "Unlocking the Power of AI in your Software Development Life Cycle (SDLC)"…
FinOps is a strategic approach to managing cloud costs. It combines financial management best practices…
Using Kubernetes with Azure combines the power of Kubernetes container orchestration and the cloud capabilities…
View Comments
When implementing performance counters for my server application, I used sample code from Jeff Richter's book "Writing Server-Side Applications for Windows 2000". That code directly manipulates the "Counter" and "Help" registry entries, but I'm not sure how well it copes when the counter text strings have become very large - which after installing several versions of .NET, and a few instances of SQL Server, they are. Much larger than they generally were back in the Windows 2000 era.
Anyway, we started to see some customer servers where the text strings had been partially or wholly lost. Performance Monitor then shows simply the numbers of the counters, but since these are different (potentially) from one system to the next, it's not generally very useful. We're not sure if this was caused by us, but since there was the possibility I decided to switch over to the officially supported method: write a header containing counter numbers, an INI containing text strings, and call LoadPerfCounterTextStringsW. In the process I discovered that, counter to the documentation, this API had actually been present on Windows NT 4.0!
If you pull out Reflector, you can see that this is what .NET does when you create performance counters through the PerformanceCounter class.
Incredible, Mr. Robbins!
The lodctr /R worked perfectly!
thanks