Some of my computers don't seem to ever get their WMI columns filled out when I "update registered computer status"...I can't seem to figure out a pattern. WMI Query works on those systems, and I've tried adjusting the timeout setting in my prefs, but still no luck.

Hi Andrew,
the timeout value is not used when WMI scanning is perfomed, so there is no need to adjust that value.

Can you please perform a WMI scan and capture VNC Manager's output using dbmon.exe or procmon .exe (from Sysinternals)?
If VNC Manager encountered an exception while running the scan, the output may contain the exception details.

Please email the output to support@


Regards,

This is what I get with DebugView:

[5416] FetchCustomWmiPropertiesWithFiltering: Invalid query  

With procmon, I see a few buffer overflows doing a RegQueryValue of:

HKLM\System\CurrentControlSet\services\NetBT\Linkage\Export

What OS is installed on the remote computer and what WMI class and properties you are trying to query?

Just to double check, the properties that appear to be missing in the VNC Manager can be queried via other WMI applications?


Regards,

Non of my WMI fields are being filled out for those that aren't working. Here's what I'm trying to get:




If I use your "WMI Query Manager", I can view most of the data....but some are not available on certain operating systems (like OSArchitecture, and the WinSAT stuff).

Andrew,
I think I might know the reason (I'll need to test it tomorrow, but I want to share it with you now).

To minimize amount of WMI queries and reduce the scan time, if there is more than one property that belongs to the same WMI calls, those properties get fetched vis single WMI query.

The problem is if one of the properties is not supported by the remote computer OS, the query will fail and of course none of the other properties will be fetched. You are seeing "Invalid query" error in the log.

Does it sound plausible?


Regards,

That absolutely sounds like the case...This explains why only my Windows 7 systems show up!

Good. There is no easy solution to this problem. One way to do it is to query all the properties one by one. It wouldn't be a problem if a customer uses one or two WMI column.
But like in your case, with 10+ different properties, a scan on your system would take much much longer to complete.

Another way, is to query the remote computer and check which properties it supports. This will also slow down the query. But may be less so as the first solution.

So what to do what to do?!!   What do you think?


Regards,

Yes, that's a tricky one...I can think of a couple of sort-of solutions, but nothing that'd be particularly elegant.

1) Create a new preference allowing users to specify that upon WMI query failure (of a computer that's actually responding in some way), you could choose to query the individual items. At least that way, the fix would only affect people who opt in, and even then only kick in if the WMI query fails.

2) Always scan for the OS, or look for OSArchitecture or something no matter what the WMI query string looks like. Basically, you could say that if the OS was not Windows 7, and the query was failing, then you'd have to query individual results. Of course, this means one additional query each time.

3) Lastly - the slightly more crazy option...Scan for the OS, compare that to a list of when new WMI keys were added, and decide what to do based on that. This isn't really a very realistic option, I don't think...just a thought.

Maybe some combination of #1 and #2?

Just wondering if you've had a chance to put any thought into this...