|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
ManagementOperationObserver and Get( observer )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 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.) 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. 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.) > Hello Richard, Hi Luke> Maybe you don't need to raise a monitor thread for each of I thought about this yesterday ... it has some mileage and could help me > QueueUserWorkItem. Is it possible to have only one monitor thread in your > system, which will loop all QueueUserWorkItems, and kill the dead one? recover. > ... I think it is better to As to sorting out the problem ... yes ultimately we do need to do that ... > invest how the particular computer didn't work with your code, than adding > threads to monitor all QueueUserWorkItem. 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. 8-) 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. |
|||||||||||||||||||||||