Can't use WBEM_FLAG_CONNECT_USE_MAX_WAIT on Win2K

[Ross Bellinger]

I have a Visual C++ project for extracting WMI information from machines
across the network. Using the IWbemLocator::ConnectServer method I'm having
the occasional issue where the ConnectServer hangs indefinitely. In my
readings I find that using the WBEM_FLAG_CONNECT_USE_MAX_WAIT flag on the
iSecurity property should alleviate the problem. Unfortunately that flag is
not implemented on Windows2000 machines and results in ConnectServer always
failing.

I can't deliver a solution which doesn't work on Windows 2000. Is there any
way to get this to work on Windows 2000, and if not is there a published
work around or suggested method of dealing with the issue?

[Torgeir Bakken (MVP)]

Post by Ross Bellinger
I have a Visual C++ project for extracting WMI information from machines
across the network. Using the IWbemLocator::ConnectServer method I'm having
the occasional issue where the ConnectServer hangs indefinitely. In my
readings I find that using the WBEM_FLAG_CONNECT_USE_MAX_WAIT flag on the
iSecurity property should alleviate the problem. Unfortunately that flag is
not implemented on Windows2000 machines and results in ConnectServer always
failing.
I can't deliver a solution which doesn't work on Windows 2000. Is there any
way to get this to work on Windows 2000, and if not is there a published
work around or suggested method of dealing with the issue?

Hi,

One common way to at least avoid trying to connect to offline computers
is to ping the computer first, and only do a WMI connection if it is
alive.

[Ross Bellinger]

Torgeir,
The machine in question is online and does respond to pings. The issue
is a shortcomming (I believe) in either DCOM or WMI whereby a deadlock can
occurr on the ConnectServer method if the WMI Server on the target machine
is broken. Sadly, in this instance (and I see it on roughly 5 out of 900
machines I scan) there is no way to predict for the condition before
communicating with the target.

What I truly need is either a way for the ConnectServer method on
Windows 2000 to support a timeout, or a method to monitor the call and
cancel it if the call takes too long to complete. I suspect I'll have to
place the call to ConnectServer into a separate thread and monitor the
thread, killing it if it doesn't respond within X amount of time. I'm
uncertain of the repurcussions of doing this though as I'm not sure what
resources will be left consumed if I just kill the thread with the hanging
ConnectServer call.

Regards,
Ross

Post by Torgeir Bakken (MVP)

Post by Ross Bellinger
I have a Visual C++ project for extracting WMI information from machines
across the network. Using the IWbemLocator::ConnectServer method I'm having
the occasional issue where the ConnectServer hangs indefinitely. In my
readings I find that using the WBEM_FLAG_CONNECT_USE_MAX_WAIT flag on the
iSecurity property should alleviate the problem. Unfortunately that flag is
not implemented on Windows2000 machines and results in ConnectServer always
failing.
I can't deliver a solution which doesn't work on Windows 2000. Is there any
way to get this to work on Windows 2000, and if not is there a published
work around or suggested method of dealing with the issue?

Hi,
One common way to at least avoid trying to connect to offline computers
is to ping the computer first, and only do a WMI connection if it is
alive.
--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
http://www.microsoft.com/technet/scriptcenter/default.mspx

[Severian [MVP]]

On Fri, 29 Apr 2005 12:15:57 -0700, "Ross Bellinger"

Post by Ross Bellinger
Torgeir,
The machine in question is online and does respond to pings. The issue
is a shortcomming (I believe) in either DCOM or WMI whereby a deadlock can
occurr on the ConnectServer method if the WMI Server on the target machine
is broken. Sadly, in this instance (and I see it on roughly 5 out of 900
machines I scan) there is no way to predict for the condition before
communicating with the target.
What I truly need is either a way for the ConnectServer method on
Windows 2000 to support a timeout, or a method to monitor the call and
cancel it if the call takes too long to complete. I suspect I'll have to
place the call to ConnectServer into a separate thread and monitor the
thread, killing it if it doesn't respond within X amount of time. I'm
uncertain of the repurcussions of doing this though as I'm not sure what
resources will be left consumed if I just kill the thread with the hanging
ConnectServer call.

You could avoid resource problems by creating a separate process for
each machine and retrieving the data by IPC.

Then, killing the process if it takes too long would release the
resources.

You could also send machine requests a single worker process; if it
hangs, kill and restart it.

--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real, but please post replies on the newsgroup.

[Dhrubojyoti Biswas]

This post seems to be a very old one... But is the problem of ConnectServer
hanging up on WIN2k remote machine WMI calls resolved.

I am writing a WMI based solution and I have a similar problem. I am running
my WMI scans from a Windows XP Professional Box and the ConnectServer Hangs
forever on a Win2k Box. I tried the WBEM_FLAG_CONNECT_USE_MAX_WAIT flag...
but it does not solve the problem.

Any help on this would be greatly appreciated.

url:http://www.ureader.com/msg/1486180.aspx