How to fix “Invalid Class” error when monitoring a process

Posted on October 18th, 2018

I recently had a customer have an error indicating “Invalid Class” when monitoring a process. This was a resource that worked perfectly until now. This is a known issue when Windows performance counters are unavailable or disabled. The primary culprit is a registry key that explicitly disables them. To fix this error, open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance\ in regedit. Check for “Disable Performance Counters” value in the right pane. If it’s there and set to 1, that’s the problem. Set it to 0 and reboot the computer. This should be done on both the Overseer computer and the computer being monitored. This fixed my customer issue, and it can fix yours. If it doesn’t, please contact us so we can work through a solution with you.



Overseer Network Monitor 5.0.163 has been released

Posted on October 5th, 2015

Today I released a new build of Overseer, 5.0.163. This version fixes a problem that some people experienced with the Overseer service not starting. This ended up being a Windows-system-level validation of the certificates used to sign Overseer which would time-out on some systems(particularly those without internet connections). This fix disables the automatic-validation of the certificate when starting the Overseer service.

Overseer 5.0.140 has been released

Posted on October 11th, 2013

I’ve just released a new version of Overseer. This version addresses a bug that I recently became aware of that affected some people trying to monitor event logs– an error regarding “unauthorized operation” was being reported. This is fixed in this version.

Additionally, I added the ability to drag and drop resources from one group to another, making it far easier to quickly organize your resources into resource groups.

Lastly, I added a simple version check upon Overseer start. Now, when you start the Overseer application, Overseer will check the website to determine the latest version of Overseer, and prompt to update if there’s a new version available.

Overseer 5.0.131 has been released

Posted on August 9th, 2013

I’ve just released another version of Overseer Network Monitor, 5.0.131. This fixes a couple bugs. First, was monitoring the local event log when Overseer is running on Windows 8. There was an error when testing the event log resource, “Attempted to perform an unauthorized operation.”  This has been fixed.

Additionally, a user reported a memory leak when Overseer has been running a long time. I eventually narrowed this down to event log monitoring using newer Windows OS’s(Vista/W2K8+)– on both the Overseer end, and the monitored computer end.  I was able to determine the problem and resolve this bug. If you’re experiencing it, please be sure to update to 5.0.131 or higher.

Overseer 5.0.114 has been released

Posted on February 20th, 2013

I’ve just released a new version of Overseer network monitoring software, 5.0.114. This version fixes a bug that could happen if a default was set under tools->options->defaults, and then that Schedule, Notification Group, Password, or Resource Group was subsequently deleted. Going back into the options screen and clicking save would throw an error.  This version fixes that problem.

This version also fixes a problem a specific customer had with OverseerSvc’s default TCP port assignment. The default has been tcp 12345 for years– even though this is a local port for communication between the Overseer and its own service– and nothing that needs to be passed through firewalls, etc… This customer had another product, “Trend Micro Common Client Communication Service”, that was listening on port 12345, which caused the Overseer service to crash trying to use this port.  I have changed the default port that OverseerSvc uses to 12344, and made this port customizable in the registry. Considering Overseer only uses this to communicate with itself via ‘localhost’, this shouldn’t cause anyone any issues, nor require any firewall changes, etc.

MSSQL Log file is too large

Posted on February 14th, 2013

When using MSSQL for Overseer’s database, sometimes the transaction log will grow way too large. This is due to the default setting in MSSQL of ‘Full’ recovery model, instead of ‘Simple’. Overseer should ideally be run with a “Simple” recovery model to keep this log file from getting out of hand. To do this, please follow these steps:


  1. Open Microsoft SQL Server Management Studio
  2. Expand ‘Databases’, and find your Overseer database, and right click->Properties
  3. Select  ‘Options’ on the left
  4. On the next screen, select “Simple” for the recovery model, and then click OK


Now, if your log file is already very large, you’re going to want to shrink it. You can do this through the SQL Management Studio GUI, as well. To do so, simply follow these steps:

  1. Open Microsoft SQL Server Management Studio
  2. Expand Databases, and find your Overseer database.
  3. Right click on the database, and go to Tasks->Shrink->Files
  4. Choose the ‘Log’ file type, and click OK
  5. Wait for the process to complete, and provided you’ve set the recovery model to ‘Simple’, you shouldn’t have to do this again.



Overseer 5.0.111 has been released

Posted on February 1st, 2013

I have just released a new version of Overseer, 5.0.111. When using Overseer to monitor a SQL Server, a user was experiencing an error, “Machine name may not contain backslashes”. This ended up being a problem when using the DBQuery resource type, monitoring MSSQL using a named instance(i.e. SERVER\instance) and Windows integrated authentication. This bug has now been fixed.

Overseer 5.0.106 has been released

Posted on December 13th, 2012

I just released a new version of Overseer Network Monitor, 5.0.106. This version adds a couple variables that can be used in custom texts– most notably, %SQLQUERY% and %SQLRESULT% for the DBQuery resource type. These were added at the request of a user– if you have variables that you’d like added, please let me know.

In addition in this release, I was able to re-create a rather complex bug that some users have had in certain environments. I was able to solve this issue, which was essentially a bug in the underlying .NET Framework. Fortunately, I was able to work around this problem and it should no longer be a problem for the users that operate in those environments.

Proxy auto-detection broken by recent Microsoft update

Posted on November 29th, 2012

Recently, Microsoft released a ‘security update’ for .NET Framework 3.51, to address KB2729452. Apparently someone, somewhere, was using proxy auto-detection scripts to somehow compromise a system. Reading the KB, this change doesn’t appear to be a problem for software developers. Unfortunately, this ‘security update’ actually broke legitimate usage for any software that uses HttpWebRequest, which is part of the .NET Framework, and is the normal way to check websites, connect to websites, etc. via code.

A customer recently brought this to my attention, and thankfully was aware that one of the new updates he installed caused the problem. I was able to work-around this problem for him by giving him a special file, but it became clear to me that other customers are likely to have this issue and it will appear as though Overseer simply doesn’t work. So, to work around this breaking change from Microsoft, I’ve added support in Overseer to specify proxy information. I left the option to ‘auto detect'(which used to be what Overseer did), but the default selection is now ‘no proxy’– this is the least problematic setting for most people. Those that have proxies can easily set their proxy information, or attempt auto-detection(which will likely work if this MS Update hasn’t been loaded).

Overseer 5.0.92 has been released

Posted on September 24th, 2012

I’ve just released another version, 5.0.92. This version fixes a bug affecting only users using MSSQL as the Overseer database. This fixes an error that occurred when adding a new resource when using MSSQL.