Connection failed Internal Redgate Monitor errors Connection failed Internal Redgate Monitor errors

Connection failed Internal Redgate Monitor errors

Redgate Monitor reports "Connection failed internal Redgate Monitor error" and Show log has "invalid class" or "unknown error". A common example is "0x80041010 (WBEM_E_INVALID_CLASS) Invalid class". Often the "invalid" WMI class is disabled but sometimes these classes become corrupt and need to be rebuilt. You may see related errors with variations of the 0x800410xx error number or 0x800440xx.

NOTE: These problems are Windows WMI connection errors, not Redgate Monitor errors. You will be able to reproduce the error by running connection tests externally to Redgate Monitor, using wbemtest or PowerShell. The guidance that follows summarizes our previous experiences with these problems, typical underlying causes, and possible resolutions that have worked for other customers. Beyond this, Redgate cannot provide further support for these environmental issues. Once you fix the external problem, the connection error will be resolved in Redgate Monitor.

0x80041010 Resolution Steps

These errors arise because one of the Windows WMI classes to which Redgate Monitor needs access, on the remote machine, is unavailable or inaccessible, for some reason. Redgate Monitor needs to query WMI classes, on the remote server, to gather monitoring data about this server, and the instances and databases it hosts (see How Redgate Monitor connects to monitored servers in the documentation, for more details).

It is often reported as an "internal Redgate Monitor error" because when it can't reach the class it needs for sampling data, it causes an error inside Redgate Monitor. However, it is in fact an external WMI error. It may be reported as a "CIMException" because CIM cmdlets are used for accessing remote WMI objects.

The following checks and actions have helped other customers resolve these problems but may not be the correct solution in your case. Please share them with your own system administration team, along with the detailed error messages and WBEMtest results, and act on their advice.

1. Search the Redgate Monitor logs for the exact error

(Configuration - Diagnostics - Retrieve log files)

Using the affected server name as reference. You will see WMI errors for "invalid class", with terms such as "cimv2" (the default WMI namespace) followed by the query attempted on the 'invalid' WMI counter, such as "Win32_PerfRawData_PerfDisk_LogicalDisk" or "Win32_PerfRawData_PerfProc_Process".

You will be able to reproduce this error externally by querying the same counters from WBEMTest (see the Verifying the error externally using WBEMTest section at the end of this article).

2. Check to see if the class is disabled

If you see the error when querying the PerfDisk or PerfProc class, for example, then the most common reason is that it is disabled. Redgate Monitor needs access to these classes to collect data from the performance counters they contain. There are a couple of ways to do this.

a. From the commandline

On the machine to which you're trying to connect, run the following command from an elevated command prompt run to find any disabled counters:

lodctr /q | findstr Disabled

This will show something like this for the PerfDisk counter being disabled (or possibly just the first line):

[PerfDisk] Performance Counters (Disabled)
DLL Name: %SystemRoot%\System32\perfdisk.dll
Open Procedure: OpenDiskObject
Collect Procedure: CollectDiskObjectData
Close Procedure: CloseDiskObject

And run this to enable them (example for PerfDisk above):

lodctr /e:PerfDisk

b. Inspect the registry keys

Alternatively, you can inspect the relevant registry keys on the machine, such as:




Check there is a DWORD entry to the right of the key named "Disable Performance Counters". If it is set to 1, set it to 0 to enable the counters and allow the collections to proceed. If it is already set to zero, or there is no DWORD entry then disabled counters is not the problem.

3. Rebuilding the counters

If you see the error when querying the class but it is not disabled or missing, then it may be that the counters have become corrupt and need to be rebuilt. You can do this using the following command (again from an elevated command prompt). It uses lodctr /R to rebuild the counters and the final line re-syncs them with WMI. The example is for the performance counter classes (PerfDisk or PerfProc):

cd c:\windows\system32
lodctr /R
cd c:\windows\sysWOW64
lodctr /R

Note that rebuilding/resyncing the performance counters can take some time. Once complete, restart the Windows Management Instrumentation service and the base monitor service.

If you're using wbemtest, then you should now re-run the wbemtest query to see if it succeeds.

4. Recompiling the MOF file

If the problem persists, you may need to try using the MOFCOMP utility to recompile the underlying .MOF file (Managed Object Format file) that provides the classes.

For example, the WMIPERFINST.mof file supplies performance counter data dynamically to the WMI counters in the PerfDisk and PerfProc classes (and any other classes that contain performance counters).

From an elevated command prompt run, at the at the C:\Windows\System32\Wbem directory:


Of course, it's not just classes that contain performance counters that become corrupt, and different classes have different MOF files associated with them. The WMIDiag tool may help you find which MOF file contains the corrupt class, or else try search terms such as "tutorial how to fix WMI corruption".

Resolving Related Errors

There are several related WMI errors with the 0x800410xx pattern, as well as others like 0x800440xx that all report as "internal Redgate Monitor errors. All of these indicate that a specific WMI operation failed, due insufficient privileges or to a WMI infrastructure issue.

0x80041017 – Invalid query

If the Redgate Monitor error logs shows queries like the ones shown earlier for the performance counter classes but the error is "invalid query" rather than invalid class, then in wbemtest, it's worth replacing IDProcess with ProcessID and rerunning the query. If this succeeds, then the problem is one we usually see in French editions of Windows Server, and the solution is simply to update Windows as this has corrected that behavior for other customers.

We have seen this error in other cases be resolved by rebuilding the performance counters (Step 3 above)

Missing or invalid WMI namespaces or providers

We've occasionally seen problems with missing or invalid namespaces or WMI providers. The following article lists the common ones and offers some guidance on dealing with missing classes or namespaces:

Verifying the error externally using WBEMTest

To reproduce the exact error externally, use the WBEMTest tool. Follow the steps described in the documentation for Testing a WMI Connection using WBEMTest (if connecting over DCOM, or PowerShell otherwise). However, instead of the general SELECT Name FROM Win32_Service query (step 7), issue the query for the counter corresponding to the error message in the logs, such as:

select ElapsedTime,IDProcess,Name,PercentPrivilegedTime,PercentUserTime,PrivateBytes,WorkingSet from Win32_PerfRawData_PerfProc_Process

If there is a problem, you get the WMI error number and message.