The wait operation timed out (Performance Counter error 0x102)
Custom Perfmon counter fails. It showed a working value for a few short periods but other than that it’s only every shown an error.
Other perfmon counters to the same server work fine and the counter in question works fine from the Perfmon MMC.
The customer perfmon counter KB also doesn’t describe what units are acceptable.
Created on Jun 29, 2015 3:16:53 PM by Chris Parr (41) ● 1
What operating systems are you using (on your Exchange and the PRTG server)?
Server 2008 R2 Enterprise Edition for Exchange 2010. Server 2008 R2 for the PRTG server.
Created on Jul 2, 2015 2:00:36 PM by Chris Parr (41) ● 1
Last change on Jul 3, 2015 8:34:05 AM by Stephan Linke [Paessler Support]
Strange — have you tried increasing the interval for those specific counters? Additionally, you can use any character as unit — it should resemble the value however 🙂
So just to clarify — the Units value is purely a label and has no bearing on if the data is displayed correctly?
I’ve recreated that counter and set it to check every 5 minutes rather than our default of every 60 seconds, and I still get the same error.
I can read the counter successfully from the Perfmon mmc with checks in any interval I like from 1 per second upwards.
Created on Jul 3, 2015 9:34:20 AM by Chris Parr (41) ● 1
Yep, purely a label. Could you try to install a remote probe on the server to see if it runs more stable then?
I’d suggest the KB page https://www.paessler.com/manuals/prtg/perfcounter_custom_sensor be updated to make that clear. I’ve been tearing my hair out trying to find what I need to set Units to.
Adding a separate probe seems excessive for a single perfmon counter. I’ve also tried creating a new custom sensor copying and pasting the values from the example for a different machine and get the same result.
Interestingly I also get the same error if I try to add the «PerfCounter IIS Application Pool» sensor. All our other Perfmon checks seem to be coming in via WMI.
Created on Jul 3, 2015 10:05:54 AM by Chris Parr (41) ● 1
Have you seen this thread already? Especially everything performance counter related, starting with «The re-enable performance counters option».
That article seems to be talking about fixing things on the server being monitored, however the counters work fine through PerfMon both locally and remotely so I’m not sure how it’s relevant.
Created on Jul 6, 2015 10:20:01 AM by Chris Parr (41) ● 1
Sorry for the delay in publishing/responding. What happens when you actually pause and resume the sensor when it’s in error state? Does it work properly then?
Pausing then resuming makes no difference. I get the same result on a couple of different checks to separate servers from the same probe.
I’ve just created a new check from a different probe to double check things and that one is mostly working, although every third entry in an error — it’s consistently recording two values then erroring, then recording another two values and erroring again. If I check the event log in PRTG it shows «The wait operation timed out (Performance Counter error 0x102)» here too as the error condition when it’s failing.
Created on Jul 8, 2015 11:53:02 AM by Chris Parr (41) ● 1
Any update on this? Restarting the probe services occasionally gives us a short period of successful monitoring, but it always fails again before long.
Created on Oct 19, 2015 1:16:34 PM by Chris Parr (41) ● 1
Did you already consider deploying a Remote Probe directly onto the target server? Then the monitoring would be local via localhost which usually is much less troublesome.
Hello, restart of PRTGProbeService on the PRTG server solve the problem. But it is workaround.
Created on Aug 3, 2020 9:58:22 AM by rpetrik (10) ● 1
Please log in or register to enter your reply.
Windows CPU BETA — Performance Counter Error 0x102
I understand that the Windows CPU Load WMI sensor is in BETA but i am having issues with it — Computers that have been added using the BETA sensor display the error periodically:
Performance Counter Error 0x102
Within the Warning count i a least have 9 entries a day
Created on Jan 29, 2013 12:11:37 PM by TimLaffan (1) ● 1
Best Answer
the issue here is that the Probe is running on Windows 2003, and Performance Counters only work on 2008 and newer. So the sensors sort-of cycle between trying Performance Counters, which won’t work, and WMI, but fall back to Performance Counters as soon as a WMI error comes in.
Please set the «Primary Method» in the «Windows Compatibility Options» for this entire probe (and so all its «child» devices and sensors) to «WMI Only».
which exact version of PRTG are you using? On what Windows version is the PRTG Probe running (that has these sensors with the errors)? And can you please upload a screenshot showing the Log-tab of one such problematic sensor?
Thanks for the quick reply,
Version: PRTG Network Monitor 12.4.7.3475 Probe: Windows 2003 R2 SP2
Created on Jan 30, 2013 8:19:36 AM by TimLaffan (1) ● 1
Last change on Jan 30, 2013 9:07:45 AM by Torsten Lindner [Paessler Support]
the issue here is that the Probe is running on Windows 2003, and Performance Counters only work on 2008 and newer. So the sensors sort-of cycle between trying Performance Counters, which won’t work, and WMI, but fall back to Performance Counters as soon as a WMI error comes in.
Please set the «Primary Method» in the «Windows Compatibility Options» for this entire probe (and so all its «child» devices and sensors) to «WMI Only».
Thanks, worked a treat
Created on Jan 30, 2013 12:11:08 PM by TimLaffan (1) ● 1
Please log in or register to enter your reply.
Direct performance counters stopped working
After recent network hiccup direct performace counters stopped working. Existing sensors (pure performace counters) report: The wait operation timed out (Performance Counter error 0x102) New sensor (pure performance counters) not possible to create with the same error. Several devices affected I have already checked requirements for performace counters: PRTG probe running on Windows 2008. Remote registry service running on both PRTG probe and target computer Both machines are members of the same domain I have checked credentials used for windows systems. Tried to use another one with domain admin privileges Such performance count exist on target machine. Moreover it’s possible to monitor it from another machine.
I can see nothing in PRTG log tab. What else I can check to identify where fault is? Thank you
Created on May 9, 2014 11:05:26 AM by Walker (0) ● 1
thank you very much for your KB-Post. Please try if any of the tips in our «Performance Counter Troubleshooting Guide» in our KB do help: My Windows sensors do not work when using direct Performance Counter access. What can I do?
Also, please do not hesitate to add any comments to this article, should you find anything helpful for you as well, that’s not yet mentioned!
Last change on Sep 28, 2015 11:38:12 AM by Torsten Lindner [Paessler Support]
Hi, That article exactly I’ve been using to troubleshoot my issue. As you can see from my initial question I’ve checked all requirements for performance counters and nothing found. Can you advice anything else please?
Created on May 12, 2014 1:51:44 PM by Walker (0) ● 1
Try rebooting the target, as well as the PRTG host machine. What happens then if you switch to WMI as preferred data source?
Target machine was already rebooted. At the moment it’s not possible to reboot PRTG host as it monitor a lot of other devices. If I choose WMI as preferred data source nothing will change. As far as I understand preferred data source only works with hybrid sensors, which can work either way. I use pure performance counter, for instance «PerfCounter IIS Application Pool BETA» or «PerfCounter Custom». This sensors only works as performance counters. Is that correct? What else I can do besides of rebooting PRTG host? Thank you
Created on May 12, 2014 3:42:41 PM by Walker (0) ● 1
You can also try restarting the Probe Service. Or finally, deploy a Remote Probe onto the target and try checking the Performance Counters locally.
Last change on May 12, 2014 4:21:59 PM by Torsten Lindner [Paessler Support]
Thank you. Reboot of Probe service on PRTG Probe host fixed the issue
Created on May 13, 2014 2:10:57 PM by Walker (0) ● 1
Hello, I’m getting the same error and I get a 404 when trying to follow the link above. Restarting the probe service solves it for a short while but the issue reoccurs.
Created on Sep 28, 2015 9:11:31 AM by Chris Parr (41) ● 1
Please try the link again, I did correct it.
Hi Paessler support team.
We’ve experienced some similar problems, and i think it could be be a bug in the remote probe part of your software. We’d like your input and potential help in diagnosing the problem. We’re running PRTG 15.1.13.1382+
We have about 800 sensors in our installation. I’ve seen the scenario i’m about to describe unfold twice now with exactly the same symptoms.
Part of our setup is a lot of WMI queries against a series of our windows servers. Lets call these sensors WA1, WA2, WB1, WB2 etc. denoting W (WMI sensor), A (machine A), 1 (sensor number 1). The exact sensor type is: «WMI Vital System Data (V2) sensor» For some other devices we have a some performance counter sensors. We’ll call these PX1, PX2, PY1, PY2 etc. denoting P (Perfcounter sensor), X (machine X), 1 (sensor number 1). The exact sensor type is «PerfCounter Custom sensor».
What we’ve experienced twice now is that some runaway process on a machine against which we run WMI sensors ate all the memory on the machine and then some. This caused the machine to become very «sluggish» and pretty much fail to respond to anything in a timely manner. This caused the WMI sensors to start timing out (for good reason) and this is exactly what we wanted to see because it revealed the problem. So in our error scenario for the sake of argument lets say sensors WB1 & WB2 go into a state of timeout (i believe the exact error was «Message was cancelled by the message filter», i was able to get the same error doing WMI queries against machine B from powershell).
Shortly after this happened we also started to see timeouts on all our performance counter sensors against completely different machines. The error for these sensors were «The wait operation timed out (Performance Counter error 0x102)». I.e. All of the «PerfCounter Custom sensor» PX1, PX2, PY1, PY2 etc. started displaying this timeout.
I went to the machines X,Y,Z etc and verified that there were no problems. The performance counters when viewed locally were fine. I also went to the server running our remote probe and tried to query the performance counters on machines X,Y,Z etc using something like powershells «Get-Counter» or the performance monitor and remote connecting to machines X,Y,Z again no problems were observed. The counters were replying just fine and giving correct values. However PRTG continued displaying timeouts.
In the meantime we booted the server B with the WMI sensors that were timing out, and the WMI sensors WB1 & WB2 started responding again and giving normal values. However our PerfCounter sensors PX1, PX2, PY1, PY2 etc were all still in a state of timeout. I’ve tried pausing the PerfCounter sensors for up to 30 minutes and resuming them to no avail, they timeout again as soon as they are resumed.
This scenario has played out twice now, and in both cases the only thing i could do to resolve the issue was to restart the PRTG remote probe service completely. That seems to «clear the pipes» so to say, and when the probe comes back online, and manages to catch up with the backlog of queries, then all the perf counter sensors are working fine again.
So the very short version of all this is: Timeouts on WMI sensors in one part of the architecture seems to cause all of our PerfCounter sensors against other parts of the architecture to start timing out as well with the error «The wait operation timed out (Performance Counter error 0x102) » for no apparent reason. The only way I’ve found to fix the problem is to restart the remote probe which is not very desirable because it leaves us «in the dark» so to say, with regards to monitoring while it catches back up.
Is this scenario something you can replicate in your internal test environments or do you have some potential ideas on what could be causing it?
Best Regards Peter Dahlgaard
Created on Jan 6, 2016 9:49:48 AM by dahlgaard (80) ● 1
My performance counter sensor does not work. What can I do?
I created a PerfCounter Custom sensor to monitor several performance counters on my operating system. Unfortunately, I get the error message The specified object is not found on the system. (Performance Counter error 0xC0000BB8).
I am sure that the paths to the specific counters are correct. When viewing the desired counters via the Performance Monitor interface of Windows, everything looks fine. Also, I can add some of the counters that are available from within Windows to PRTG, which works perfectly. So, where are my performance counters in PRTG?
Last change on Dec 10, 2020 10:26:54 AM by Brandy Greger [Paessler Support]
This article applies as of PRTG 22
Remote monitoring of specific performance counters
The PerfCounter Custom sensor can monitor a set of Windows performance counters that you can individually define. You can find available performance counters on your system via PerfMon as outlined in this article: How can I find out the names of available performance counters?.
If your probe with the PerfCounter Custom sensor runs on a different server than the performance counters that you want to monitor, there might be an issue with remote access.
On the PRTG core server system, try to remotely access the counters with PerfMon. If you can see some system counters (for example, processor information or SQL server), but not the desired performance counters, we recommend that you manually start Performance Counter DLL Host (perfhost.exe).
This Windows service enables remote users and 64-bit processes to query performance counters provided by 32-bit DLLs. It does not run by default, so that only local users and 32-bit processes are able to query performance counters provided by 32-bit DLLs.
Last change on Jun 2, 2022 9:00:34 AM by Brandy Greger [Paessler Support]