Three Steps in a WMI Monitoring Script

Microsoft® Windows® 2000 Scripting Guide

Just as there are three primary steps in a WMI script that retrieves and displays the properties of a managed resource, there are three steps in a WMI monitoring script.

  1. A connection is made to a WMI namespace on a computer.

    The first step is the same as the first step in most WMI scripts. A connection is made to the namespace where the WMI class corresponding to the resource being monitored is located.

    strComputer = "."
    Set objSWbemServices = GetObject("winmgmts:" &_
    "{impersonationLevel=impersonate}!" &_
    "\\" & strComputer & "\root\cimv2")
  2. A notification query is issued.

    In the second step, a notification query is issued using WQL. The query looks similar to the WQL statements used previously in this chapter, although there are several new elements, such as WITHIN and ISA.

    Set objEventSource = objSWbemServices.ExecNotificationQuery( _
    "SELECT * FROM __InstanceModificationEvent " &_
    "WITHIN 10 " &_
    "WHERE TargetInstance " &_
    "ISA 'Win32_Service'  " &_
    "AND TargetInstance.Name = 'alerter'")
  3. The event is received and some action performed.

    In the third step, the NextEvent method is called, which causes the script to pause and wait for an event before proceeding to the next line. After the event is received, the script proceeds to the next line, which is a message that informs the user that a particular event occurred.

    Set objEventObject = objEventSource.NextEvent()
    Wscript.Echo "The status of the alerter service was just changed."

Despite the similarities, however, there are some important differences between a standard WMI query and an event notification query.

Event notification queries use event classes

Instead of selecting instances from a WMI class that represents a managed resource, the WQL event query selects instances from an event class. The __InstanceModificationEvent class, as its name makes clear, represents the event that occurs when an instance is modified. There are also event classes that represent the events that occur when an instance is created or deleted: __InstanceDeletionEvent and __InstanceModificationEvent. Each of these three classes derives from the more general __InstanceOperationEvent class, a class containing events generated whenever an instance is created, deleted, or modified.

Event notification queries use the WITHIN keyword

Because the Win32_Service class does not have a corresponding WMI event provider, the WITHIN keyword must be used to signify that the WMI polling mechanism should be used with a polling interval of 10 seconds. In other words, every 10 seconds the CIM repository is checked to see whether any new changes have been made to the Alerter service. At most, you are notified within 10 seconds if the Alerter service is modified.

Theoretically, some events can be missed, depending on the polling interval. For example, suppose you are checking every 30 seconds to see whether a new instance of Notepad has been created. If a user starts Notepad and then immediately closes it, this event will likely not be reported.

This is because of the way the polling mechanism works. Suppose you create an event subscription that checks every 30 seconds to see whether Notepad has been started. WMI will begin by taking a snapshot of the specified class; in this case, it will record the state of all the processes running on the computer. Thirty seconds later, WMI will take a second snapshot of the Win32_Process class and then compare this with the previous snapshot. Suppose the first snapshot had only two processes:


And suppose the second snapshot has three processes:


In this case, it is obvious that Notepad has been created. However, if Notepad was started and then immediately stopped, it would not appear in the second snapshot. As far as WMI is concerned, the event never occurred.

This snapshot approach also explains why it is not recommended that you use WMI to monitor changes to all the files on a hard disk: The resultant snapshots would be huge, and comparing the two snapshots would require considerable computer resources. Items such as processes and services can be more readily monitored because there are far fewer of them on a computer.


  • So why can you monitor changes to the event logs, even though event logs typically have thousands of events stored in them? You can do that because there is an event provider for event logs that will watch for and notify you of changes as they happen. WMI does not need to use the snapshot method to monitor event logs. However, no such event provider exists for files or folders.

If you do not include the WITHIN clause when the resource being monitored does not have a corresponding event provider, you will receive the following error message:

'WITHIN' clause must be used in this query due to lack of event providers

Event notification queries use the TargetInstance object

It is unlikely that you will find it useful to be notified of the creation of every instance of every WMI class. Instead, you need a way to request the specific instances you are interested in. Using TargetInstance provides a way to make reference to the instances you would like the query to return.

TargetInstance is an object, created in response to an event, that has the same properties (and values) of the object that triggered the event. For example, if the Alerter service is stopped, the TargetInstance object will be an instance of the Win32_Service class that has the name Alerter and the state Stopped (plus any other properties of the Alerter service).

In addition to TargetInstance, there is also a WMI object known as PreviousInstance. As the name suggests, this object maintains the properties and values of the object before the event occurred. In this example, PreviousInstance would be an instance of the Win32_Service class that has the name Alerter and the state Running.


  • Where did PreviousInstance come from? Remember that WMI is taking, and comparing, two snapshots of the specified class. PreviousInstance represents objects found in the previous snapshot; TargetInstance, objects found in the current snapshot.

Knowing both the current and the previous state of an instance allows you to tell what changed when an object was modified. As a very simple example, a script can echo the values of all of the PreviousInstance and all of the TargetInstance properties. You can then compare those values to see any and all changes that were made to an object.

Event notification queries use the ISA keyword

The ISA keyword enables you to check whether a particular instance belongs to a certain class. The ISA keyword is roughly equivalent to the equals sign. However, you cannot say that the TargetInstance equals the Win32_Service class; it does not. Instead, the TargetInstance is an instance of the Win32_Service class. Thus, it is a Win32_Service instance.