New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


Perfcounter IIS Application Pool 0x800007D0

Votes:

1

Your Vote:

Up

Down

A couple (2 or 3) times a day, a lot of Perfcounter IIS Application pool sensors give the message Down (Unable to connect the specified computer, or the computer is offline. (Performance Counter error 0x800007D0)) At that moments the monitored servers are running normally without having issues. I already have tried re-adding the IIS Application Pool sensors, but the issue is still there. I monitor all the application pools except _Total.

PRTG is running on a physical server and there are no other issues with sensors.

Does anyone have an idea how to solve this?

iis perfcounter prtg

Created on Nov 21, 2016 10:44:52 AM by  DickVink (1) 1



29 Replies

Votes:

0

Your Vote:

Up

Down

Hi there,

The error does not necessarily mean that the target host totally went down the drain, it just means the sensor cannot perform the required action, which basically is establishing a connection to the remote registry service on the target host.

Please check if remote registry service is running on the target host. Also try restarting the probe service to see if that helps.

See also: Reasons for Unsuccessful Access to Performance Counters

Kind regards,

Erhard

Created on Nov 22, 2016 1:32:08 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi,

Remote Registry services are running on the servers where the issues persist. I have restarted already the probe-service but have done this again right now. The strange thing is that the issue is there on several servers at the same time. So, I assume it had nothing to do with the monitored servers but maybe with some setting within PRTG.

Created on Nov 22, 2016 1:39:58 PM by  DickVink (1) 1



Votes:

0

Your Vote:

Up

Down

Have you also tried restarting remote registry service on the targets? The ugly thing about these errors is, they often come and go and it's hard to nail what really causes them.

See here a few options listed also for "repairing" performance counter related errors.

Kind regards,

Erhard

Created on Nov 22, 2016 2:40:12 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I had the same error.

I'm on the last version of PRTG. I already try to reboot the remote probe center without any success.

I had the chance to be ready when that happen. I made some test : reboot the WMI service and others repairing tips but nothing has worked.

After few minutes of downtime, all sensors came back to normal by them-self.

I also checked on event log but there is nothing related to this. During the downtime, I use the Paessler WMI tools and everything was working great. Moreover, the service deliver by this IIS pools are also wroking well.

In my case, the servers behind the IIS are Exchange servers.

Where can I dig ?

Thanks.

Created on Nov 23, 2016 3:37:31 PM by  Romain (0)



Votes:

0

Your Vote:

Up

Down

Hello Romain,

That's the problem with those errors, as they often just come and go and it's hard to really break it down to what's really causing it.

See here a few options listed also for "repairing" performance counter related errors, there's not much else we can recommend I'm afraid.

Kind regards,

Erhard

Created on Nov 24, 2016 2:35:33 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hallo Erhard, zuerst einmal Danke für das sehr gute Monitoring Tool PRTG. Auch wir haben das Problem, dass sporadisch (jeden Tag 2 bis 3 mal) bei den unterschiedlichsten Servern dieser 0x800007D0 Fehler im Zusammenhang vom Sensor "App Pool" auftritt. Ganz selten sehen wir dies ebenfalls beim bandwithsensor.

Wir haben nun schon wirklich alles untersucht und auch eure Ratschläge befolgt, aber wir finden nicht die Ursache um diesen Fehler zu beheben. Ebenfalls sehen wir, das bei einer virtuellen remote Probe dieses Problem überhaupt nicht auftritt. Irgend eine Idee wie wir dieses Probleme beheben können ?

Gruß Stefan

Created on Dec 14, 2016 9:07:53 AM by  StefanS (0) 1



Votes:

0

Your Vote:

Up

Down

Hallo StefanS,

wird die derzeit aktuellste Version von PRTG verwendet (16.4.28.7352)? Sind auf dem Probe System (PRTG Server selbst bzw. Remote Probe) und auf dem abgefragten Zielsystem die Windows Updates auf aktuellem Stand?

Bzgl. der virtuellen Remote Probe: Soll heißen, dass die selben Sensoren gegen das selbe Gerät gerichtet dort nicht auf den Fehler laufen?

Freundliche Grüße,

Erhard

Created on Dec 14, 2016 2:40:32 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hallo Erhard, danke für die schnelle Antwort, zu deinen Fragen folgende Antworten:

>>wird die derzeit aktuellste Version von PRTG verwendet (16.4.28.7352) hier wird noch die 16.4.27.7140 eingesetzt. Bis auf das "App Pool" Problem ist diese Version bisher ohne Probleme am laufen.

>>auf dem abgefragten Zielsystem die Windows Updates auf aktuellem Stand? ja auf allen.

>>Soll heißen, dass die selben Sensoren gegen das selbe Gerät gerichtet dort nicht auf den Fehler laufen? Nein, bei der Remote VM handelt es sich um einen anderen Standort. Jedoch werden hier Server mit dem selben OS (2012-R2) und mit den selben Application von PRTG geprüft wie beim PRTG Core. Also unterschiedliche Server die geprüft werden, jedoch identisches OS / Applikation.

Beim PRTG Core, wo wir die Probleme sehen, handelt es sich um einen physikalischen Server (2012-R2). Es gibt den Verdacht, das der Switch an dem dieser Server angebunden ist ev. mit seinen QoS Regeln dieses Problem verursacht. Die QoS Regel wurden angepasst, jetzt gilt es ab zu warten ob der Fehler damit behoben wurde.

Danke für deine Hilfe. Stefan

Created on Dec 14, 2016 2:58:41 PM by  StefanS (0) 1



Votes:

0

Your Vote:

Up

Down

Hallo Stefan,

was die PRTG Version angeht, die aktuellste hat noch diverse Fixes bzgl. WMI Sensoren, welche sich auch positiv auf diesen Sensor auswirken könnten.

Die Sache mit der Firewall ist aus meiner Sicht ein guter Ansatz. Der Fehler sagt zwar einerseits "Kann die Maschine nicht erreichen", was aber nicht zwingend heißen muss, dass Sie gerade überhaupt nicht erreichbar ist, aber eben der spezifische Aufruf des Sensors fehlschlug in dem Moment. Falls dies hilft mit der Firewall, würden wir uns freuen, wenn du deine Erkenntnisse hier teilen könntest, was angepasst wurde :)

Freundliche Grüße,

Erhard

Created on Dec 14, 2016 3:32:43 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hallo Erhard,

kurze Rückmeldung. Also das Problem besteht leider nach wie vor und "ausschließlich" nur der Sensor Typ "App Pool". Wir werden den Sensor löschen müssen, da sonst immer sporadisch das E-Mail Konto vom Techniker mit den daraus entstehenden Warnmeldungen geflutet wird. Eigentlich Schade den für bestimmte Server wäre der Sensor schon von nutzen. Es ist wirklich interessant alle anderen Sensoren arbeiten ohne Problem, auch bei größter Last auf den Zielsystemen, nur dieser "App Pool" kippt sporadisch weg. Was ist an diesem Sensor so speziell, das der diese Probleme verursacht ?

Gruß Stefan

Created on Dec 15, 2016 1:27:40 PM by  StefanS (0) 1



Votes:

0

Your Vote:

Up

Down

Hallo Stefan,

die Frage ist wahrscheinlich weniger, was an dem Sensor so speziell ist, sondern eher was bei IIS Application Pools so speziell ist :)

Aktuell vermuten wir, dass es mit dem sogenannten Recycling des IIS App Pools zusammenhängt, was die Sensoren hier durcheinander bringt, aber es ist wie gesagt aktuell nur eine Vermutung.

Freundliche Grüße,

Erhard

Created on Dec 16, 2016 12:00:57 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi, just for your information. I have justed updated our PRTG-version to 16.4.28.7421. I hope this fixes the problems with the App Pool sensors. Till this update we still had the problems with the app pool sensors a couple of times a day. I will let you know if the problem is gone or not.

Created on Dec 20, 2016 8:59:30 AM by  DickVink (1) 1



Votes:

0

Your Vote:

Up

Down

Unfortunately, this update didn't fix the problems with the App Pool sensors. Any suggestions to solve this are very welcome. I am out of ideas at this moment.

Created on Dec 21, 2016 8:26:42 AM by  DickVink (1) 1



Votes:

0

Your Vote:

Up

Down

Hi Dick,

How is application pool recycling currently configured on the IIS?

Try enabling logging of such events on the IIS to see if it correlates with the sensors failing when/after this happened, which could prove as a useful detail as we're currently also trying to figure out what might cause this:

Kind regards,

Erhard

Created on Dec 21, 2016 8:48:35 AM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hi Erhard, for all the application pools I have checked the recycling is configured for Regular Time Intervals (1740 minutes). On two test-servers (16 application pools) I have enabled logging from now. Now lets wait till the next time PRTG gives the app pool sensor errors. Hopefully the logging is showing some more information.

Kind regards,

Dick

Created on Dec 21, 2016 1:22:20 PM by  DickVink (1) 1



Votes:

0

Your Vote:

Up

Down

Hi Dick,

Great, let us know what you find out.

Kind regards,

Erhard

Created on Dec 21, 2016 1:49:23 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I already had again the sensor errors on the two test-servers, but no events/log about the recycling of IIS. And that can be right because it should recycle every 29 hours. And I got the errors on the sensors last night around 6PM and this morning around 10AM. I will keep digging.

Created on Dec 22, 2016 10:00:21 AM by  DickVink (1) 1



Votes:

0

Your Vote:

Up

Down

I've had this issue for a couple of years now. I've opened multiple support cases and never got any satisfactory resolution from the support team. At this point I just pause all app pool sensors on the server when a few go red. After 15 minutes the errors clear. If they don't, then I just start the process of creating a new app pool sensor and that kicks everything back to functional. It's ridiculous to have a bug like this with absolutely no firm resolution and no follow-up from the support team. This is honestly the reason that I wouldn't bother using PRTG in another environment if it's not already established. PRTG definitely has ease of use but if it's this buggy then I'd rather take more time setting up a monitoring system that always works.

Created on May 21, 2018 4:53:04 PM by  rslater (0) 1



Votes:

1

Your Vote:

Up

Down

Hello rslater,

Hard to argue against what you wrote, I'm not happy about it either. What I can say is that development is aware of the issue and the related code needs a massive overhaul that in fact means re-creating the sensors/the way they operate from scratch. It's one of many tasks though in our development backlog and so far there is still no ETA for a fix I'm afraid.

Kind regards,

Erhard

Created on May 22, 2018 6:12:03 AM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Any news on this issue? We also getting random errors with message: Unable to connect to the specified computer, or the computer is offline]. [(Performance Counter error 0x800007D0. It is now 5-6-2018, when it will be fixed? Problem is still around since 2016.

Created on Jun 5, 2018 12:34:33 PM by  ConantheB (0)



Votes:

0

Your Vote:

Up

Down

Still nothing new I'm afraid, still on the development's backlog and currently on hold due to other topics with higher priority and the effort behind totally creating the sensors anew from scratch.

Kind regards,

Erhard

Created on Jun 6, 2018 1:32:54 PM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Same problem... with continual random failures on hundreds of app pools, it makes monitoring app pools impossible & the sensor quite useless. Making it go away would be better than ongoing false positives...

Created on Oct 4, 2018 1:07:49 PM by  cdr (0)



Votes:

0

Your Vote:

Up

Down

It's always like, on different servers I get too many alerts on these sensors. Solve it please.

Created on Apr 24, 2019 4:25:31 PM by  Dantes93 (0)



Votes:

0

Your Vote:

Up

Down

We've had this problem for three years... no solutions that work have ever been offered to fix this issue. And it is now July 2019. Not even a remote session for assistance even though we're paying for support.

Created on Jul 30, 2019 5:05:05 PM by  sanangel (0)



Votes:

0

Your Vote:

Up

Down

Hi sanangel,

To be honest, there is no point in doing a remote session, when the issue needs to be fixed inside the sensor's code, which in this case means rewriting the whole code of this sensor to address the issues properly. There is a documented workaround here, yes, it's not pretty, but it's better than nothing.

Kind regards,

Erhard

Created on Jul 31, 2019 5:48:11 AM by  Erhard Mikulik [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Dear PRTG, We are having the same problem, every day, on various Exchange servers. It looks like this issue has been known for over 3 years and there is still no fix? Thank you, Jon

Created on Feb 26, 2020 4:59:12 PM by  Jon Hege (0)



Votes:

0

Your Vote:

Up

Down

Hi Jon,

We are painfully aware of that situation but there is still nothing new. Erhard's statement is still accurate and the workaround described here is the best approach that we can offer at present :(

Best,
Sebastian

Created on Feb 27, 2020 3:10:10 PM by  Sebastian Kniege [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello,

I had the same issue with some iis pool sensors on one target machine and also with other performance counter sensors on the same target. In my case the service "WMI Performance Adapter" on the target system was stopped when the error occured. After starting the service the sensors returned to Ok. I set the service starting configuration from "manual" to "automatically". Maybe this will improve the reliability of the sensors.

Created on Apr 6, 2020 7:18:08 AM by  Johannes B. Latzel ([email protected]) (24) 1



Votes:

0

Your Vote:

Up

Down

Same issue for my environment. This thread is very disappointing. I don't see how something that could cause a customer to have hundreds of false down alerts to show up for them, could be left unaddressed for this long. I understand that I don't have insight into PRTG's development, but this is egregious.

Created on Jul 16, 2020 2:42:33 PM by  DaralenManta (0)



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.