The Performance Monitor tool built into the Windows operating system can give you a wealth of information regarding what's going on with your system at a given moment. Most of the time, the information it gives you is exactly what you'd expect to see. Maybe you're not expecting to see the exact range of values that Performance Monitor is reporting for a given counter, but Performance Monitor itself is behaving just as you would expect it to throughout the monitoring process.
Sometimes, however, Performance Monitor behaves really strangely. You may wonder what this odd behavior means and whether you can trust the counter values it's given you. This article will attempt to shed some light on a few of this tool's eccentricities.
One common anomaly occurs when the counter you are monitoring constantly reports a value of zero, regardless of what you think the value realistically should be.
Several things can cause this problem. One possibility is that the counter you are monitoring is somehow tied into a service that has stopped. Suppose you were monitoring the number of SMTP services received per minute on a mail server. If the service responsible for processing those messages stopped, no messages would be coming into the server. If Performance Monitor were monitoring the underlying service directly, the monitoring would probably fail completely after the service stops.
However, if Performance Monitor were monitoring a message queue rather than the service that brings the messages into the server, then it would likely continue to report that zero messages have been received. The queue is functional, the Performance Monitor is giving you accurate results, but the stopped service is the reason why mail isn't flowing. This is just a hypothetical example, but the same principle can be applied to any monitoring situation that depends on services.
Another reason why Performance Monitor may consistently report a value of zero for a counter is that you don't have permissions to access the resource being monitored. Usually, if you try to monitor a counter that is bound to a resource that you don't have permissions for (such as a resource on another computer), you will receive an Access Denied message. However, I have seen instances in which the currently logged-on user lacks permissions to monitor a local service-related resource, and Performance Monitor reports a value of zero for the resource rather than producing an Access Denied message.
Gaps in the graph
Here's one that will really mess with your mind. Have you ever seen a Performance Monitor graph with missing pieces? I'm not talking about areas in which the counter data values were off the scale, but rather areas with no data at all.
An overburdened system almost always causes this problem. The Windows operating system is a multitasking environment. One problem with a multitasking OS is that it must make decisions regarding how much processing time each thread receives. The algorithm that Windows uses to determine how much CPU time each thread receives is fairly complex, but one of the factors that the OS looks at is the thread's priority. For example, a low-priority thread would receive less processor time than a normal-priority thread, and a high-priority thread receives more CPU time than a thread with a normal priority.
Most of the time this doesn't cause any real problems. However, if the system is running low on resources, and high-priority applications (or applications that are configured to run in real time) are running on the system, then Windows might steal CPU cycles from the Performance Monitor to keep the higher priority threads running efficiently. And if it doesn't receive an adequate number of CPU cycles, gaps in the line graph may result.
Counters stop working after you install a new app
Sometimes application-specific Performance Monitor counters might stop working after you install an application. There isn't much you can do to prevent this from happening because there is nothing stopping an application developer from creating Performance Monitor counters that interfere with counters related to another application.
If counters that you're still using no longer work after you install a new application, there is a way to fix the problem. Unfortunately, doing so often causes problems with the counters related to the new application. When you install an application that includes Performance Monitor counters, Windows creates a backup copy of the Registry entries related to the Performance Monitor. This backup is saved to a file named PerfStringBackup.ini. Windows creates this backup so that the Performance Monitor-related Registry entries can be salvaged should the new application's Setup fail. But after the application finishes installing, the PerfStringBackup.ini file is overwritten with the current Performance Monitor-related Registry entries. This means that you no longer have a backup of the Registry entries as they existed prior to installing the application.
The trick to fixing your counters is that you have to restore the PerfStringBackup.ini file from a tape backup that was made prior to installing the new application. Just restoring this file won't fix your problem though. You have to tell Windows to update the Registry to reflect the contents of the newly restored file. To do so, you must use the following command: Lodctr /r:PerfStringBackup.ini
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He has written for SearchWinSystems.com and other TechTarget sites, as well as for Microsoft, CNET, ZDNet, MSD2D, Relevant Technologies and other companies.
