ManagementOperationObserver and Get( observer )

[Guest]

The following illustrates a problem I have in another program ... however it
only occurs on one in 5,000 remote machines. I suspect the cause of the
problem lies with the remote machine ... but why doesn't my client time out
with an exception ?

The Get() method that initialises the asynchronous operation blocks for way
too long (I've not seen it give up).

Most of the time one will get an error of some sort, RPC not available,
Access Denied, COM is stuffed, etc ... but when it hangs it's gone ... and
it's repeatable against the machine ... but you have to find the right
machine.

Needless to say I've got a hugely multithreaded scanner trying to do all
this scanning for real ... but when one of the remote machines block this
initialisation ... then I'm stuffed.

I've unsatisfactorily tried to set up another thread to maintain a timeout
and abort the thread if it hangs too long during this method.

Note this method doesn't retrieve the data ... merely set's up the operation
.... so I believe.

I've not verified that the problem occurs in synchronous mode ... but
wbemtest.exe does have the same issue ... which isn't a .Net app ... so I
suspect this is a COM or WMI server issue.

Can anyone shed any light ?

class Console
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
System.Management.ManagementPath lWMIPath = null ;
System.Management.ManagementScope lWMIScope = null ;
System.Management.ObjectQuery lWMIWQL = null ;
System.Management.ManagementOperationObserver lWMIObserver =
null ;

lWMIPath = new System.Management.ManagementPath(
"\\\\remote-machine\\root\\cimv2" ) ;
lWMIScope = new System.Management.ManagementScope() ;

lWMIScope.Path = lWMIPath ;
lWMIScope.Options.Timeout = new System.TimeSpan( 0, 0, 0, 30 ) ;

lWMIObserver = new
System.Management.ManagementOperationObserver() ;

lWMIObserver.ObjectReady += new
System.Management.ObjectReadyEventHandler( ObjectReady ) ;
lWMIObserver.Completed += new
System.Management.CompletedEventHandler( Completed ) ;

lWMIWQL = new System.Management.ObjectQuery();

lWMIScope.Options.Authentication =
System.Management.AuthenticationLevel.Connect ;

using( System.Management.ManagementObjectSearcher lWMISearcher =
new System.Management.ManagementObjectSearcher( lWMIScope, lWMIWQL ) )
{
lWMISearcher.Query.QueryLanguage = "WQL" ;
lWMISearcher.Query.QueryString = "SELECT Name from
Win32_ComputerSystem" ;

lWMISearcher.Options.ReturnImmediately = true ;
lWMISearcher.Options.Timeout = new System.TimeSpan( 0,0,0,4 ) ;

lWMISearcher.Get( lWMIObserver ) ; // this line hangs forever ...
}
}

internal static void ObjectReady( object aSender,
System.Management.ObjectReadyEventArgs aArgs )
{
}

internal static void Completed( object aSender,
System.Management.CompletedEventArgs aArgs )
{
}
}

Using v1.1 .Net on 2k3 Server

 

[Luke Zhang [MSFT]]

Hello,

If these code are just run on the remote computer, will it get correct
result? The remote computer may have a "dirty" installation, protected by
some firewall, proxy or antivius staffs.

Luke Zhang
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Guest]

Hi Luke,

Thanks for the suggestion ... I haven't tried that ... and it kind of misses
the issue that I have ... I don't care if the machine is going to do that ...
I could flag that for someone to sort out ... but only if I can actually do
something other than sit and wait for it

My wmi scanner hangs permanently because the thread that is doing this
'asynchronous' Get( obs ) ... the only solution I have is to abort the
thread. I'm using this method of using System.ManagementSearcher as I
considered it was more efficient with resources .. but for each Get call I
make I have to launch a thread to monitor it and kill it if it takes too long
to respond.

These pairs of threads (well a QueueUserWorkItem and a 'monitor' Thread)
cause a gross inefficiency in the system as they have to synchronise with
each other to ensure it doesn't kill a thread that succeeded ... nor kill a
thread that hasn't started yet ... there just isn't a satisfactory solution
.... and killing threads on this level just goes against my upbringing ... but
I don't see any alternative.

I always have to create the thread, for each query (45 of them) per machine
(5000) just in case one of them decides it's going to hang. There's no way to
predetermine this effect.

Hope this helps clarify things ?

Richard.

 

[Luke Zhang [MSFT]]

Hello Richard,

Maybe you don't need to raise a monitor thread for each of
QueueUserWorkItem. Is it possible to have only one monitor thread in your
system, which will loop all QueueUserWorkItems, and kill the dead one?

Since only one computer failed with the problem, and
ManagementObjectSearcher has TIMEOUT parameter, I think it is better to
invest how the particular computer didn't work with your code, than adding
threads to monitor all QueueUserWorkItem.

Luke Zhang
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Guest]

Hello Richard,

Hi Luke

Maybe you don't need to raise a monitor thread for each of
QueueUserWorkItem. Is it possible to have only one monitor thread in your
system, which will loop all QueueUserWorkItems, and kill the dead one?

I thought about this yesterday ... it has some mileage and could help me
recover.

... I think it is better to
invest how the particular computer didn't work with your code, than adding
threads to monitor all QueueUserWorkItem.

As to sorting out the problem ... yes ultimately we do need to do that ...
but I need to be able to tell the sys admins which machine it is ... if I'm
locked in a black hole then I can't do anything.

But I really do feel that there is a serious flaw in the WMI or DCOM code
somewhere that is only encountered in very strange circumstances ... why does
this occur ... unfortunately I don't have time to invest working it out ...
SEP ... my scanner needs to cope with it.

 

[rm041284]

I know this is an old thread, but I was curious if you ever figured anything out on it. I have the exact same problem. I had thought it was coming from something else, but when i set ReturnImmediately = False then it changed to hanging at the Get command instead of when i tried to return the data.