Nagios Support Forum

We've been having some issues with wmi checks on Windows 2008 boxes, its happened across different servers.
A check will timeout or give a Windows error and then the next check it will check fine.

I've looked into it as much as I can and found mention of a possible memory leak in WMI on Windows 2008 boxes but the suggested hotfix has already been applied to our Windows 2008 boxes as part of our regular updates.

Just wondered if anyone else has encountered this and if they found out what the issue was.

I think maybe its the Windows boxes being under load and not enough resources available to answer the request.
But I've no way of proving this or debugging it as it happens to random servers throughout the day.

Thanks
Tony

A lot of the default check_wmi_plus queries use the LIKE conditional which can (though certainly not as a rule) be significantly more expensive than the = conditional. These queries exist in your check_wmi_plus.ini file and the plugin is fairly liberal with allowing you to modify/alter/create them (just back the file up before you mess with it). Not sure if that will solve your problem, but in the case of checking processes/services the change might be meaningful as those classes can get quite bloated. I'm guessing if you're aggressively monitoring a couple dozen processes/services on a given 2008 machine that using = in the queries could save some time.

You might also fiddle around with the -d flag for check_wmi_plus and get some additional output to better identify bottlenecks. All of the above assumes the bottleneck is with the remote WMI system rather than the local check_wmi_plus execution environment.

Thanks, @mcapra! @delboy1966, Let us know if you have more questions regarding this issue. Also, have you considered increasing the -t timeout value inside the check command?

Tried all that was suggested and still no different.
I think it must just be the Windows boxes being a pain.

Thanks anyway

So you used the "-d" flag to enable debugging, but you didn't find any clues in the output of what could be causing the timeouts?

I believe we found the issue with the timeouts.
It was a network issue.
Thanks for your help.

Thread can be closed.