Perfcounter IIS Application Pool 0x800007D0

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

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.

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

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.

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

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

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

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

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

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

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

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.

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.

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:

• Configure Logging of Events when an Application Pool Recycles because of Non-Configured Recycling Events (IIS 7)
• Configure Logging of Events when an Application Pool Recycles because of Configured Recycling Events (IIS 7)

Kind regards,

Erhard

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

Hi Dick,

Great, let us know what you find out.

Kind regards,

Erhard

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.

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.

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

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.

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

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...

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

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.

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

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

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

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.

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.

When will this be fixed? It's nearly 2022, and the whole "we can't figure it out" nonsense is getting really old. You are providing a product that people pay for, this is an absolute necessary function in a product like this and its way past embarrassing. We have on-call resources being bombarded with hundreds of false alerts throughout all hours of the day and night.

I'm not interested in some hack job workaround, I want it to work properly. If you can't bothered to get off your rumps and fix such a simple thing then I guess it's time to start looking at dropping PRTG for a product that doesn't completely fail for no reason.

For me, the issue was with the device being monitored, rather than a PRTG issue. I was able to resolve the issue by running the following commands in under an elevated cmd session:

```
cd c:\windows\system32
lodctr /R
cd c:\windows\sysWOW64
lodctr /R
WINMGMT.EXE /RESYNCPERF
net stop pla
net start pla
```

thank you, JohnLBevan, will pass your suggestion to my IT Colleagues. And hope, it could help with similar "Performance Counter error 0x800007D5" too

I think this is linked to a security permission accessing a COM server component, however I cant seem to identify which COM Server component to adjust.

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{D63B10C5-BB46-4990-A94F-E40B9D520160}
and APPID
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
to the user ROSEG3CACHE\Administrator SID (S-1-5-21-249241378-2394087663-1034666275-500) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

Hi folks,

I have an update on this:

We also having this error code: Leistungsindikator-Fehler 0xC0000BDB

It started after activating SMB signing for SMB2/3 with this Powershell command:

Set-SmbServerConfiguration -RequireSecuritySignature $true

If this is activated, no guest or anonymous logins are accepted anymore for SMB protocol. I have no idea how SMB signing is involved with the App pool sensor. But I can reproduce this error by switching RequireSecuritySignature on and off.

NM is running on a Windows Server 2019 with latest patches.

Sensor does not immediately switch to error, if SMB signing is activated. But it switches quite fast to green, after deactivating SMB signing.

@Paessler Support: please investigate how SMB signing and App pool sensor are connected.

Cheers