WMI Programming with Visual Basic.NET: Trapping System Events - Watching the event
(Page 4 of 4 )
The above section defined only a simple query (instead of an Event Query). But we didn’t execute the query yet. And we cannot simply execute the query and leave off. We need to listen (or instead watch) for any events arriving based on that query. The query is not like a Data Query, which fetches existing information. It is like a query which waits (or watches) for certain information to arrive (which is nothing but the event).
So we need to attach the query to a “watcher”. This is where the “ManagementEventWatcher” class comes in. Let us consider the following statement:
DimwatcherAsNewManagementEventWatcher(query)
The above statement creates a “watcher” object based on the event query specified through an instance of ‘WqlEventQuery’. But make sure that it doesn’t start listening (or watching) yet. Let us consider the next statement.
DimevAsManagementBaseObject = watcher.WaitForNextEvent()
Within the above statement, we have “watcher.WaitForNextEvent”, which actually waits for the event to occur. Once the event notification arrives, the information gets collected through “ManagementBaseObject” reference (which is “ev”). The application hangs (or may be unresponsive) until it receives the event notification. It will not even properly repair itself (unless you implement an asynchronous way of programming style, which is beyond the scope of this series).
Me.TextBox1.Text &= ControlChars.NewLine & _
"Service’" &CType(ev("TargetInstance"), ManagementBaseObject)("DisplayName") & "’has changed, State is’" &CType(ev("TargetInstance"), ManagementBaseObject)("State") & "’"
In the previous section, I stated that “TargetInstance” is a property of “__InstanceModificationEvent”, which itself is an instance of the event fired. To get the information of the event fired, we need to extract the information from “TargetInstance” (which is actually a property containing object itself, not a value based property). So, we again convert the “TargetInstance” to “ManagementBaseObject” and then finally retrieve “DisplayName” and “State” properties of the generated event. The next statement is:
watcher.Stop()
I hope you can understand the above statement very easily. Every “Event Watcher” must be explicitly stopped (just like a database connection) or else it may eat up system resources.
Summary
I think this is the most typical article in this series. I strongly suggest you investigate thoroughly the above new classes introduced before going to the successive parts of this series. MSDN has plenty of information on all of the above classes, as well as examples.
The above example cannot be used for a production environment, as it still lacks some standards of implementation. It is provided just to help you learn a new concept for handling system events through WMI. Currently, I didn’t provide a very professional example (which requires knowledge of other concepts of .NET as well) by implementing permanent watchers or asynchronous model or Windows services or logging or other items. But will I try my best to provide some of those goodies in my upcoming articles. For any enhancements or suggestions to this part of series, I can be reached at jag_chat@yahoo.com.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
