Some of my WMI sensors in PRTG are down. The displayed error messages do NOT begin with an error code in the format 800xxxxx, but have (code: PExxx) appended . What can I do?
Created on Feb 19, 2010 12:14:23 PM by
Last change on Apr 8, 2010 8:31:47 AM by
The following errors that do not show the usual 800xxxxx error codes are caused by erroneous behavior of the Windows WMI sub-system either on the target or the probe system affecting the processing of the monitoring data. Another reason for experiencing PRTG specific error messages is the use of improper WQL statements in WMI Custom Sensors.
Note: This list is work in progress.
This is not a timeout error per se, it means that probe computer and target system weren't able to establish a WMI communication at all. Please read more about that in this article:
What can I do about “Connection could not be established” errors on my WMI sensors?
The request sent to WMI takes a lot of time to be processed (by default more than 1.5x the scanning interval). It’s a recoverable error and can be countered by either increasing the scanning interval or specifying more limiting parameters for the WMI specific request (if applicable). This is directly controlled by the WMI timeout setting in the WMI Compatibility options and set to 1.5x the scanning interval if left empty or the specified amount in seconds. You might want to check the WMI timeout settings of the parent objects if several sensors run into this error.
PRTG’s probe didn’t succeed in sending the request to the WMI sub-system. (Timeout occurred while establishing a connection to WMI). This can be a temporary problem which can resolve itself. However, it also can mean that the probe or/and the target system needs a restart if the problem persists.
This means that PRTGs probe was able to send a request to the WMI subsystem but it didn’t return _at all_ which is about the worst thing that can happen. This error will be shown after five fails, so it is sure to assume the respective sensor is unusable and all WMI requests to that host are put on hold. Should the problem persist after a reboot of the target machine please reboot the probe computer. If this error continues to occur please consider installing a remote probe on the target computer.
This is only an interim message which leads to Sensor stopped due to WMI lockup above.
When the Windows WMI sub-system sends data to PRTG at least two consecutive times that leads to impossible results, such as unrealistic percent values, PRTG reports this fact as “inconsistent” and puts the sensor into an error state. Should the next data be ok again, the sensor goes up again. There's no way to change that behavior because the error is caused by WMI, not by PRTG. If this keeps on happening try to use the sensor’s “Alternative Query” in the WMI Compatibility options, if available.
PRTG relies upon many counters being 64 bit as it is taking a considerable amount of time until these counters are full and have to start counting from 0 again (which is called “overflow”). However, sometimes WMI (falsely, dependant on patch levels) uses only 32 bit for these counters, starting from 0 much more often than it should and PRTG reports this fact as “too many 32 bit overflows” or “Device sends 64 bit counters as 32 bit values”.
One way to adapt to this is to decrease the scanning interval, as this measure lowers the probability that an overflow occurs during the interval. Another way would be to use the sensor’s “Alternative Query” in the WMI Compatibility options, if available.
One of the WMI counters this sensor uses returned a value that prevents PRTG from calculating the correct result e.g, a negative value when only positive ones are expected or a 0 for a denominator. If this error is persistent we recommend to reboot the target system.
Some of the WMI sensors need their previous data for calculating their correct results. So when WMI sent unusable values during the scan before you'll see this message. This should be very sporadic - if it's not we recommend that you reboot the target system.
PRTG needs the total Memory in order to calculate the percentage of free memory, but WMI doesn't deliver a valid value (usually 0). Try using the Alternative Query or refer to The Repair List for WMI problems for further suggestions.
WMI Network sensor only. The WMI query for network traffic knows only one way to identify a network adapter: by its name. Unfortunately this name is altered by Windows now and then. At the moment the only thing you can do is to create a new sensor with the new name.
WMI Process sensor only. This means that either the process name wasn't specified correctly in the sensor settings or the process isn't running on the target machine.
The WMI query came back empty while PRTG expected a result. This indicates that there's a problem with the host's WMI system. Please refer to The Repair List for WMI problems for suggestions what to do.
w.i.p.
w.i.p.
w.i.p.
w.i.p.
w.i.p.
w.i.p.
w.i.p.
w.i.p.
w.i.p.
Created on Feb 19, 2010 12:55:08 PM by
Last change on Apr 27, 2010 9:57:18 AM by
Please log in or register to enter your reply.
Add comment