The object invoked has disconnected from its clients

Hello,

I'm very sorry, but "80010108: The object invoked has disconnected from its clients" is also a low-level error that PRTG gets from the DCOM on the target machine. We do not know why then, we only get this error-message. And if a scan fails, a sensor in PRTG will always go into warning and then error state if the next scan also fails. Because, then in terms of facts the sensor is not able to work, and this is actually a faulty state.

Best Regards.

We are getting this and a bit of research has identified the follwoing KB.

http://support.microsoft.com/kb/940466

Would this be a strong candidate? It works some of the time.

Thanks for this suggestion. As it's from Microsoft it's worth a try for sure!

we receive the same message, we monitor a mssql server2008 with a local tested sql script to check sql backup state on a windows 2008 server.

Did you try the Microsoft article posted above?

Best regards,

- Volker

Hello. Experiencing the exact same in a customer environment. I look on the server and everything appears fine. Is there a way to prevent this from occurring frequently? Thanks.

As this is a low-level error message from the DCOM parts of Windows you might try one of these: update Windows to the latest patch level, restart the PRTG probe service, restart the computer running the PRTG probe. If the problem persists, please try to install the PRTG probe on a different computer.

I am getting this error repeatedly on disk space monitor on a 2008 R2 SP1 server - so the MS KB is not relevant. It is happening every 20 mins and is followed immediately with the correct disk space alert so DCOM appears to be ok.

Has anyone seen this?

Unfortunately, such sporadic WMI errors are very hard to catch & fix. It should help to use longer (thus safer) scanning intervals. Did you try restarting the target systems? And also try restarting the Probe Service, or its underlying host machine. Maybe also remove any WMI sensors that are not "really necessary" (and only add them in certain debug-situations), or pause them. These two actions should help already. The next thing could then indeed be deploying Remote Probes, maybe if the targets are grouped in subnets, or similar, then put a Remote Probe in each of these subnets. The final last resort, would be considering using SNMP to monitor the Windows Hosts, with something like SNMP Informant, where the free version of it, already covers most basic WMI Counters.

Please also see our extensive WMI Troubleshooting Guide.