Description from The SentryOne community
One of the things we’ve come to understand in our dealings with the Windows operating system as it relates to performance monitoring is that the performance counter system is very fragile. It doesn’t take much at all to set it off kilter and most of the time you won’t even know what happened or when.
The first thing to do in this case is to verify if the counters exist on the server that has the instance being monitored. This can be done from Windows Performance Monitor. From the server’s desktop click Start-> Run and type “perfmon.exe”. When it opens, you can right click in the perfmon window and select add counters. From here you will want to add a counter being referenced in the error.
If they are not there, you may actually be in a bit of luck. Since all of the counter categories listed are from SQL Server, there is a very good chance that restarting the SQL Server service will set them back in order. If that doesn’t work, you may need to rebuild the counters. Information about this process can be found here:
How to manually rebuild the entire Performance Counter Library: https://docs.microsoft.com/en-US/troubleshoot/windows-server/performance/rebuild-performance-counter-library-values
How to rebuild SQL Server 2005 / 2008 performance counters: https://techcommunity.microsoft.com/t5/sql-server-support-blog/troubleshooting-sql-server-2005-2008-performance-counter/ba-p/315693
Please note that this blog calls for the default instance of SQL Server to use the performance counters in “sqlctr.ini” however; in some circumstances we have found that the file does not load after making the necessary edits. Instead it gives a Windows error that there was some conflict with the registry. In this case, please look for a file named “perf-MSSQLSERVERsqlctr.ini” in the BINN folder. This file should have all the edits already made and load without a problem to restore the counters.
If you do need to rebuild the counters, please keep in mind that neither SQL Sentry nor any other monitoring tool that looks at the SQL Server performance counters (including Windows Performance Monitor) will be able to offer any assistance as far as the metrics specific to these counter categories go.
If you can get the counters locally, then the next step is to verify if you can access them from the server hosting the SQL Sentry service.
To do this you will need to open Windows Performance Monitor on the server hosting the SQL Sentry Monitoring service. When it is open, enter the UNC path to the server in question (\\MACHINENAME) then wait just a few moments to let perfmon connect to the machine and refresh the counters list. Once it’s refreshed, look for the counter categories listed in the error message. If you can’t find them, then you have verified that there is a communication error.
Assuming the counters aren’t there, the next thing you can try is restarting the remote registry service on the watched server. This is simple to do and shouldn’t create any type of service interruption. Once the service is running again retry the previous procedure to test for the counters again.
Once the counters are available in Windows Performance Monitor, start the SQL Sentry Client and wait a few minutes for the error to clear. If it does not clear you can restart the SQL Sentry Monitoring Service and wait a few more moments for the error to clear.