WMI Windows Service Monitoring - Service not found (code: PE010)

Did you also send us a Support Bundle? I'm just asking, because we received a Support-Bundle containing a screenshot showing those "39081" and "39082" named service sensors, running on an AWS based probe. That was you, right? Or not? :)

I'll check the logs and answer you by email if that's fine for you. First advice would be in cases like this to raise the scanning interval, since this may happen when trying to scan every 60 seconds for example.

Kind regards.

Yes, that was us. Thank you!

I rebooted our Probe today and the new sensor I set up last week is also failing with the same message now, leaving us with two of the same failing sensors.

Thank you for the update. We're already discussing next steps with your MSP, who also sent us the Support Bundle.

Kind regards.

I hI have the same Problem trying to monitor a Service. Everything ng works fine until we restart the Server then the Code PE010 is there. How did you solve the Problem?

Hello ivancota,

Make sure you have the latest version of PRTG running as it contains several fixes regarding WMI sensors. Also try using alternatively the SNMP Windows Service Sensor to see if that works more reliably.

Kind regards,

Erhard

Erhard, Unfortunately, even on the latest software releases, this problem was never resolved. We sent log bundles and several patches were applied to no avail. We still regularly deal with three of our sensors that go to PE010 with every probe reboot. Re-adding the sensor has been the only workaround. Very frustrating, to be honest.

Hello thigley986,

I understand the frustration very well, because WMI related issues are very hard to debug. There were indeed a few issues inside PRTG regarding WMI -mostly connection related issues- that lead to several errors and were fixed now in the latest version.

Issues with only particular sensors is a different story or framed differently: The service sensor for example performs the same query, no matter which machine and which service you query, while for sure the queried host and the service are basically the variables that differ from machine to machine. Now what's going on, when the same sensor runs without issue on one host, monitoring a specific service, while being totally shaky when monitoring another particular host and one or several services on it? That's the big question in the end and the tricky part ist, that there is no comprehensive all-in-one-log anywhere that will reveal exactly that. Could be indeed an issue on the remote probe's WMI/RPC/DCOM stack running the sensor, could also be an issue on the queried host or both, everything's possible here.

Have you tried using the SNMP-based service sensor? Did you have issues with it, too? If that's the case, it is most likely an issue with the monitored service itself, somehow "behaving odd", for lack of better words.

Kind regards,

Erhard

The common thread in our failures is there is a trailing space in the Windows Service Name. Other monitoring software is able to query WMI appropriately. It almost "feels" like, at some point, PRTG is truncating the service name.

Ok, so "trailing space" means there is a space at the end of the service name (for what reason ever), correct?

That's the query the sensor performs:

SELECT Started,State,Status FROM Win32_Service WHERE Name='servicename'

'servicename' is however not the display name that is being used, instead the query goes against the service name visible in the properties of a service. For example Windows Firewall: Display name is "Windows Firewall", while the service name is "MpsSvc". Which service are you querying there (exact name)?

"Other monitoring software is able to query WMI appropriately." --> Are you actually monitoring this exact service with another monitoring software by WMI without issues and know which query it performs?

And also one more time: Have you tried using the SNMP Windows Service sensor to monitor the same service? Please try it to see if also fails.

Kind regards,

Erhard

Erhard, We have not tried SNMP as a replacement. As of today, we have renamed two of the three services to remove a trailing space at the end of the service name. We are awaiting the next Core Server reboot by our PRTG provider (the event that triggers the PE010 error). If two services survive the reboot and the unchanged service does not, we will have established a definitive cause of sorts.