Dynamic monitoring of resources using snapshots of system states

One embodiment of the invention is a method for dynamically monitoring resources. A request of a user to monitor at least one specified resource is sent to a monitor request module. Using the monitor request module, at least one monitor is created to monitor the specified resource.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates in general to the field of monitoring system resources, and in particular to methods and systems for monitoring system resources in real-time in an object-oriented environment.

2. Description of Related Art

With increasing complexity of administering computer systems today, it is desirable to detect changes in system states of a complex computer system in real-time and log the changes. System state is defined as a run-time state of system resources at a particular instant in time.

The resources of a computer system that may be of interest at run-time are its hardware, file systems, processes running on the system and its registry. The term hardware of a computer system refers to objects that are tangible such as disks, disk drives, display screens, keyboards, printers, boards, and chips. File subsystem refers to a system that an operating system or a program uses to organize and keep track of files. For example, a hierarchical file subsystem is one that uses directories to organize files into a tree structure. A process is a program being executed by a computer system and the term is also used as a synonym for a task. A process performs some useful operations on data. Typically, an operating system is capable of running several processes at the same time. Hence, at any given time there could be one or more processes running on a computer system. A registry is a database used by an operating system to store configuration information. For Windows operating system, the Registry comprises the following major sections:HKEY_Classes_Root—file associations and OLE informationHKEY_Current_User—all preferences set for current userHKEY_User—all the current user information for each user of the systemHKEY_Local_Machine—settings for hardware, operating system, and installed applicationsHKEY_Current_Configuration—settings for the display and printers

Most Windows applications write data to the Registry, at least during installation. A registry can be edited directly by using the Registry Editor provided with the operating system. However, great care must be taken during editing the Registry because errors in the Registry could disable a computer system.

Changes to any of these components can result in a change in system state.

As the Windows NT operating system is increasingly becoming an enterprise wide operating system, a larger number of system administrators need methods that can held them diagnose and solve problems in a shorter period of time. In particular, there is a need for a method that can monitor in real-time specified resources of a computer system.

SUMMARY OF THE INVENTION

An embodiment of the invention is a method for dynamically monitoring resources. A request of a user to monitor at least one specified resource is sent to a monitor request module. Using the monitor request module, at least one monitor is created to monitor the specified resource.

DETAILED DESCRIPTION

For ease of understanding and clarity, the terms that will be used hereinafter are defined as follows.

An object represents an entity. An object has properties which include all the attributes of the entity represented by the object, and may also have procedures (also called methods). Procedures may be implemented as executable code.

A snapshot is a collection of objects representing the system states at a point in time. A snapshot may comprise several collections of objects, with the objects belonging to the same collection being of the same type. The collections of objects may include a collection of file objects, a collection of registry objects, a collection of process objects, a collection of hardware objects, and a collection of certification objects.

A file object is an object representing a state of a file at a point in time. The state of a file includes all the attributes of the file.

A registry object is an object representing a registry key value. A registry object has attributes that include the two attributes of a registry key, which are the value name and the actual value.

A process object is an object representing a process.

A hardware object is an object representing a hardware item.

A certification object is an object representing a system resource that has a certification status (such as version). The collection of certification objects provides information regarding certification status of the system.

There are two main embodiments of the Resource Monitor of the present invention. The first embodiment can be used as a stand-alone system for real-time monitoring of specified system resources using snapshots of the specified system resources. The second embodiment of the Resource Monitor is used in conjunction with the Contrast Manager system of the present invention for real-time monitoring of specified system resources. In the second embodiment, the snapshots are created by an instantiation of the Contrast Manager.

FIG. 1is a diagram illustrating a computer system100in which one embodiment of the invention can be practiced. The system100includes a processor100, a processor bus120, a memory control hub (MCH)130, a system memory140, an input/output control hub (ICH)150, a peripheral bus155, a mass storage device170, and input/output devices1801to180K. Note that the system100may include more or less elements than these elements.

The processor110represents a central processing unit of any type of architecture, such as embedded processors, mobile processors, micro-controllers, digital signal processors, superscalar computers, vector processors, single instruction multiple data (SIMD) computers, complex instruction set computers (CISC), reduced instruction set computers (RISC), very long instruction word (VLIW), or hybrid architecture.

The processor bus120provides interface signals to allow the processor110to communicate with other processors or devices, e.g., the MCH130. The host bus120may support a uni-processor or multiprocessor configuration. The host bus120may be parallel, sequential, pipelined, asynchronous, synchronous, or any combination thereof.

The MCH130provides control and configuration of memory and input/output devices such as the system memory140and the ICH150. The MCH130may be integrated into a chipset that integrates multiple functionalities such as the isolated execution mode, host-to-peripheral bus interface, memory control. The MCH130interfaces to the peripheral bus155. For clarity, not all the peripheral buses are shown. It is contemplated that the system100may also include peripheral buses such as Peripheral Component Interconnect (PCI), accelerated graphics port (AGP), Industry Standard Architecture (ISA) bus, and Universal Serial Bus (USB), etc.

The system memory140stores system code and data. The system memory140is typically implemented with dynamic random access memory (DRAM) or static random access memory (SRAM). The system memory140may include program code or code segments implementing one embodiment of the invention. In the first embodiment, the system memory140includes a Resource Monitor system145. In a second embodiment, the system memory140includes a Resource Monitor system1210and a Contrast Manager system1202. Any one of the elements of the Resource Monitor system145, or Resource Monitor system1210and a Contrast Manager system1202, may be implemented by hardware, software, firmware, microcode, or any combination thereof. The system memory140may also include other programs or data which are not shown, such as an operating system. The Resource Monitor system145, or Resource Monitor system1210and Contrast Manager system1202, may implement all or part of the resource monitoring functions. The Resource Monitor system145, or Resource Monitor system1210and a Contrast Manager system1202, may also simulate the resource monitoring functions. The Resource Monitor system145, or Resource Monitor system1210and a Contrast Manager system1202, contains instructions that, when executed by the processor110, causes the processor to perform the tasks or operations as described in the following.

The ICH150has a number of functionalities that are designed to support I/O functions. The ICH150may also be integrated into a chipset together or separate from the MCH130to perform I/O functions. The ICH150may include a number of interface and I/O functions such as PCI bus interface to interface to the peripheral bus155, processor interface, interrupt controller, direct memory access (DMA) controller, power management logic, timer, system management bus (SMBus), universal serial bus (USB) interface, mass storage interface, low pin count (LPC) interface, etc.

The mass storage device170stores archive information such as code, programs, files, data, databases, applications, and operating systems. The mass storage device170may include compact disk (CD) ROM172, a digital video/versatile disc (DVD)173, floppy drive174, and hard drive176, and any other magnetic or optic storage devices such as tape drive, tape library, redundant arrays of inexpensive disks (RAIDs), etc. The mass storage device170provides a mechanism to read machine-accessible media. The machine-accessible media may contain computer readable program code to perform tasks as described in the following.

The I/O devices1801to180Kmay include any I/O devices to perform I/O functions. Examples of I/O devices1801to180Kinclude controller for input devices (e.g., keyboard, mouse, trackball, pointing device), media card (e.g., audio, video, graphics), network card such as institute of Electrical and Electronics Engineers (IEEE) 802.3, IEEE-1394, IEEE-802.11x, Bluetooth, and any other peripheral controllers.

Elements of one embodiment of the invention may be implemented by hardware, firmware, software or any combination thereof. The term hardware generally refers to an element having a physical structure such as electronic, electromagnetic, optical, electro-optical, mechanical, electro-mechanical parts, etc. The term software generally refers to a logic structure, a method, a procedure, a program, a routine, a process, an algorithm, a formula, a function, an expression, etc. The term firmware generally refers to a logical structure, a method, a procedure, a program, a routine, a process, an algorithm, a formula, a function, an expression, etc. that is implemented or embodied in a hardware structure (e.g., flash memory, ROM, EROM). Examples of firmware may include microcode, writable control store, micro-programmed structure. When implemented in software or firmware, the elements of an embodiment of the present invention are essentially the code segments to perform the necessary tasks. The software/firmware may include the actual code to carry out the operations described in one embodiment of the invention, or code that emulates or simulates the operations. The program or code segments can be stored in a processor or machine accessible medium or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium. The “processor readable or accessible medium” or “machine readable or accessible medium” may include any medium that can store, transmit, or transfer information. Examples of the processor readable or machine accessible medium include an electronic circuit, a semiconductor memory device, a read only memory (ROM), a flash memory, an erasable ROM (EROM), a floppy diskette, a compact disk (CD) ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, Intranet, etc. The machine accessible medium may be embodied in an article of manufacture. The machine accessible medium may include data that, when accessed by a machine, cause the machine to perform the operations described in the following. The machine accessible medium may also include program code embedded therein. The program code may include machine readable code to perform the operations described in the following. The term “data” here refers to any type of information that is encoded for machine-readable purposes. Therefore, it may include program, code, data, file, etc.

All or part of an embodiment of the invention may be implemented by hardware, software, or firmware, or any combination thereof. The hardware, software, or firmware element may have several modules coupled to one another. A hardware module is coupled to another module by mechanical, electrical, optical, electromagnetic or any physical connections. A software module is coupled to another module by a function, procedure, method, subprogram, or subroutine call, a jump, a link, a parameter, variable, and argument passing, a function return, etc. A software module is coupled to another module to receive variables, parameters, arguments, pointers, etc. and/or to generate or pass results, updated variables, pointers, etc. A firmware module is coupled to another module by any combination of hardware and software coupling methods above. A hardware, software, or firmware module may be coupled to any one of another hardware, software, or firmware module. A module may also be a software driver or interface to interact with the operating system running on the platform. A module may also be a hardware driver to configure, set up, initialize, send and receive data to and from a hardware device. An apparatus may include any combination of hardware, software, and firmware modules.

One embodiment of the invention may be described as a process which is usually depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed. A process may correspond to a method, a program, a procedure, etc.

FIG. 2is a block diagram illustrating a first embodiment of the Resource Monitor system of the present invention. Embodiment200comprises a MonitorRequest module204, a user interface206, a monitor208, and an optional Resource Monitor Service202. The MonitorRequest module204may be manually started by a user via the user interface206, or automatically started by the Resource Monitor Service202upon reboot of the computer system that includes the Resource Monitor system200.

In one embodiment, there is actually only one MonitorRequest module. If the MonitorRequest module is already active, any attempt to start it will result in a reference to the existing MonitorRequest module being returned to the initiator.

A user can designate a monitor as restartable monitor by setting a monitor property called AutoRestart. Necessary information of a restartable monitor is saved so that it can be restarted upon start-up of the Resource Monitor Service202.

The MonitorRequest module204interfaces with a user via the user interface206. Upon receipt of a user request from the user interface206to monitor specified resources, the MonitorRequest module204creates at least one monitor208.

The monitor may be implemented as a COM object or a thread or a process.

If the specified resources are of the same type, the monitor208creates a collection of monitored objects2101. . .201k, corresponding to the specified resources to monitor the specified resources. For example, if the specified resources are of the type “file object” that is, an object representing a file stored in a storage device, then the monitored objects correspond one-to-one to the specified files and each of the monitor objects represent a snapshot of the corresponding specified file at that point in time. If the specified resources are of the type “registry object”, that is, an object representing a key value in a registry, then the monitored objects correspond one-to-one to the specified registry key values and each of the monitored objects represents a snapshot of the corresponding specified registry key value at that point in time. It is noted that a complete registry key may have several values, and each value is represented by a separate registry object.

If the specified resource is the set of all the processes that are active during the time the monitor208is active, then the monitor208keeps track of all such processes. The monitor208obtains data on any process that starts or ends, and logs the process starting time and ending time. In this case of process monitoring, no monitor object210iis created because no snapshot of a process is needed.

FIG. 3is a flowchart illustrating one embodiment of the method of the present invention. Upon Start, process300initializes the MonitorRequest module204(block302). The MonitorRequest module204receives a user request with parameters of specified resources, from user interface206(block304). The monitorRequest module204creates a monitor208to monitor the specified resources (block306). The MonitorRequest module208provides to the user interface a link, i.e., a reference, to the monitor208(block308). Parameters of specified resources are loaded into the monitor208(block310). It is noted that these parameters may be loaded either from the user interface206or from the MonitorRequest module204. The monitor208creates a collection of monitored objects210i, i=1, . . . , k, each of the monitored objects representing a snapshot of the corresponding specified resource taken at that point in time (block312). The monitor208monitors the specified resources and maintains the collection of monitored objects (block314).

FIG. 4AandFIG. 4Bare a flowchart illustrating an embodiment of the method to be practiced with the first embodiment of the Resource Monitor system.

Upon Start, the user request calls the Monitor procedure in the User interface206(block402). The Monitor procedure in the User Interface206calls the CreateMonitor procedure in MonitorRequest module204(block404). The CreateMonitor procedure in MonitorRequest module204creates a Monitor208(which is just an object having no attributes of the specified resources at this point), and returns to User Interface206the reference to the newly created Monitor208(block406). The Monitor procedure in User Interface206transfers all parameters of specified resources to the new Monitor208(block408). User Interface206calls the Monitor procedure in MonitorRequest module204(block410), which then calls the Monitor procedure in the new Monitor (block412). The Monitor procedure in the new Monitor208creates an initialization thread A, and waits for error result or event from initialization thread A (block414). An event indicates successful initialization of the Monitor208. An error result indicates an error encountered during the initialization of the Monitor208.

Thread A creates a snapshot of specified resources based on the parameters already received from the User Interface. In other words, thread A creates a collection of monitored objects corresponding to the specified resources (block416).

If there is an error in creating the snapshot (block418), thread A sets the currently created monitor status to “error”, and exits (block420).

If there is no error in creating the snapshot, thread A sets up internal logic and makes request to receive notification of change regarding the monitored objects from the operating system (block422). If there is any error at this point (block424), thread A sets Monitor status to “error” and exits (block426). For example, an error is encountered if a specified resource is already being monitored by an existing active monitor created prior to the new monitor. If there is no error, thread A creates at least one thread B to do the monitoring (block428). Depending on the type of monitor and the numbered of monitored objects, more than one thread B may be needed. The monitoring function of thread B will be discussed inFIG. 4CandFIG. 4D.

After creating thread B (block428), thread A causes the event indicating completion of the initialization of the Monitor, then thread A becomes the control thread for the Monitor208(block430). By becoming the control thread for the Monitor, thread A allows control of the Monitor208by the user via a user request to the MonitorRequest module204. User requests include “Stop” to stop the Monitor208from monitoring. “Start” to restart the Monitor208, and “Quit” to terminate the Monitor208.

The Monitor procedure in the Monitor208sees the event caused by thread A (in block430) or the monitor status “error” set by thread A (in block420or block426) and returns result to MonitorRequest module204(block432). MonitorRequest module returns result to the User Interface206(block434).

Thread B, created by thread A (FIG. 4B, block428) does the monitoring, which includes waiting for notification of any changes to the monitored objects. The monitored objects associated with one Monitor may be files or registry key values, but not both. If there are both types of monitored objects in one user request, then two different Monitors2081,2082are created to separately monitor each type of monitored objects. In other words, one Monitor2081would monitor the file objects, while the other Monitor2082would monitor the registry objects. It is noted that each Monitor208iincludes procedures, i.e., program code, to handle either type of monitored objects, but for efficiency reasons, can only maintain a collection of monitored objects of the same type.

FIG. 4CandFIG. 4Dare a flowchart illustrating one embodiment of the process of monitoring file objects.

After being created by thread A (FIG. 4B, block428, orFIG. 13B, block1328), thread B waits for notification of change from the operating system regarding the specified resources (block436). If there is no notification of change (block438), thread B stays in the waiting loop (block436).

If a notification of change is received, and if the change is a deletion, thread B locates the corresponding file object (representing a previous state of the identified file) in the collection of file objects maintained by the Monitor208(block446). Thread B logs the deletion (block448), and deletes the corresponding file object in the collection (block450). Thread B then waits for a new notification of change (block436).

If a notification of change is received, and if it is not a deletion (block439) then thread B calls the procedure CreateAndCompareSingleObject in the Monitor208and passes to the procedure the identification of the file that has changed (block440). The procedure requests to locate the identified file in the file subsystem (block442).

The CreateAndCompareSingleObject procedure creates a new file object representing the current state of the identified file (block452). The procedure then locates the corresponding file object, representing a previous state of the identified file, in the collection of file objects maintained by the Monitor208(block454).

If the corresponding file object is not found in the collection of file objects (block456), indicating that the identified file is recently added to the file subsystem, then thread B logs the addition (block458), and adds the new file object to the collection of file objects maintained by the Monitor208(block460). Thread B then waits for a new notification of change (block436).

If the corresponding file object is found in the collection of file objects, then the newly created file object is compared to this corresponding file object in the collection to determine what has been changed (block462). The change, that is, information pertaining to previous state and current state of identified file, is logged for the records (block464) and the corresponding file object in the collection is updated (block466). The file object may be updated either directly or by being swapped with the newly created file object. Thread B then waits for a new notification of change (block436).

The monitoring process of registry objects in similar to the monitoring process of file objects shown inFIG. 4CandFIG. 4D, with a few differences due to the fact that a complete registry key may have several values.

When thread B gets notification of a change to a registry key, thread B calls the procedure CreateAndCompareMultipleObjects in Monitor, passes to this procedure the identification of the registry key that has the change. If the identified registry key has multiple values, the CreateAndCompareMultipleObjects procedures creates multiple objects, each representing the current state of a corresponding value of the identified registry key.

If the collection of registry objects maintained by Monitor includes a registry object representing a previous state of a value of the identified key, when the newly created registry object associated with this registry key value is compared to the corresponding registry object in the collection to determine what has been changed. The corresponding registry object in the collection of registry objects maintained by Monitor208is updated, and the change is logged for the records. If the change is deletion of that value of the identified registry key, then the deletion is logged for the records. Once the information data associated with this registry object with “deleted” status is logged, this registry object may be removed from the collection of registry objects maintained by Monitor.

If the collection of registry objects maintained by Monitor does not include any registry object corresponding to a value of the identified key, then the addition is logged for the records, and the newly created registry object is added to the collection of registry objects maintained by Monitor.

In another embodiment of the system of the present invention, the Resource Manager1210(FIG. 1) instantiates a Contrast Manager1202to obtain snapshots of specified resources.

FIG. 5is a block diagram illustrating an embodiment of the Contrast Manager system500. The Contrast Manager500comprises a Snapshot module502and a plurality of Map objects including at least a RegistryMap504and a FileMap506. Contrast Manager500may also include other map objects such as a ProcessMap508, a HardwareMap510and a CertificationMap512. A user can interface with the Snapshot module502using a User Interface501which may be a scripting Application Programming Interface (API) or a snap-in to a management console (such as the Microsoft Management Console of Windows, owned by Microsoft Corporation). Upon being instantiated, the Snapshot module502instantiates the collection of Map objects504,506,508,510,512. Each of the Map objects maintains a collection of objects of the same type. The RegistryMap maintains a collection of registry objects5141, . . . ,514j. The FileMap maintains a collection of registry objects5161, . . . ,516k. The ProcessMap maintains a collection of registry objects5181, . . . ,518l. The HardwareMap maintains a collection of hardware objects5201, . . . ,520m. The CertificationMap maintains a collection of certification objects5221, . . . ,522n.

FIG. 6is a flow chart illustrating an embodiment of the process of creating a process snapshot. Upon Start, process600receives a user request to create a process snapshot (block602). Process600uses Application Programming Interface (API) calls to collect process information for each process and adds the information to a list of process items (block604). Process600steps through the list of process items, creates a process object for each list item, gets attributes of that process item and stores the attributes into the newly created process object. Process600adds the newly created process objects to a collection of process objects (block606) and terminates.

FIG. 7is a flow chart illustrating the process of creating a file snapshot. Upon Start, process700creates the path map from the paths and masks supplied by the user (block702). Process700checks whether there is any entry in the path map (block704). If there is no entry in the path map, then the process700terminates.

If there is an entry in the path map, then process700uses the path and mask values in API calls to collect file information and adds the file information to to a file list (block706). Process700checks whether the path map has an additional entry (block708). If the path map has additional entry, process700goes to the block706to collect file information for the additional entry. If there are no more entries, then process700creates a file object for each file in the list, gets attributes of that file and stores the attributes in the newly created file object. Process700adds the newly created file objects to a collection of file objects (block710) and terminates.

FIG. 8is a flow chart illustrating the process of creating a hardware snapshot. Upon Start, process800uses API calls to collect hardware information and added the information to a list. Each different type of hardware is maintained in a separate list (block802). Process800steps through the list and creates a hardware object for each item in the list, gets attributes of that list item and stores the attributes in the newly created hardware object. Process800adds the newly created hardware objects to a collection of hardware objects (block804) and terminates.

FIG. 9AandFIG. 9Bis a flow chart of an embodiment of the process of creating a registry snapshot. Upon Start, process900creates a keymap from the path keys and searchkeys supplied by the user (block902). Process900checks whether there are any registry paths in the keymap to be searched (block904). If there is none, then process900terminates.

If there is a registry path in the keymap to be searched, then process900enumerates the registry keys and subkeys of the selected registry path, that is, using API calls to traverse the selected registry path (block904). Process900then checks whether the search_key_names is set to true (block908).

If the search_key_names is not set to true, the process900checks whether the search_key_values is set to true (block914).

If the search_key_names is set to true, the process900checks whether there is any key or subkey that matches a search key (block910).

If there is any key or subkey that matches a search key, process900sets the key match to true (block912), then enumerates the registry values of the selected registry path (block916), skipping block914(no need to check for value of the search_key_values).

If there is no such key or subkey, then process900checks whether the search_key_values is set to true (block914).

If the search_key_values is not set to true, then process900goes back to block904to check whether there is any other registry path to be searched.

If the search_key_values is set to true, then process900enumerates the registry values of the selected registry path (block916), using API calls. Process900then checks whether the key match is set to true (block918).

If the key match is set to true (this means that process900arrives here from the Yes branch of block910), process900adds the path and value to the snapshot (block922), then goes back to block904to check whether there is any other registry path to be searched.

If the key match is not set to true (this means that process900did not get here from the Yes branch of block910), process900checks whether there is any value names that match a search key (block920).

If there is no such value name, then process900goes back to block904to check whether there is any other registry path to be searched.

If there is value name that match a search key, process900adds the path and value to the snapshot (block922), then goes back to block904to check whether there is any other registry path to be searched.

FIG. 10AandFIG. 10Bare a flowchart that illustrates an embodiment of the process of comparing a previously stored snapshot with a current snapshot.

Upon Start, process1000loads the snapshot2from a storage device to compare it with the current snapshot1in memory (block1002). Process1000checks whether there are objects in both snapshots (block1004). If there are no objects in both snapshots, i.e., both snapshots are empty, then process1000terminates.

If there are objects in both snapshots, then, for each object in snapshot2, process1000locates the corresponding object in current snapshot1. A check is made as to whether any map properties have been set that would affect the comparison of the file and process objects (block1006). Some of these map properties (such as CompareDrives, ComparePath properties of FileMap, and ComparePID and ComparePath properties of ProcessMap) are discussed later in relation inFIG. 11.

Process1000checks whether an object in snapshot2has a corresponding object in current snapshot1(block1008). If there is no such corresponding object in snapshot1, this means the object has been deleted.

If there is a corresponding object in current snapshot1, then process1000compares the attributes of the two objects (block1012). Process1000checks whether the attributes have the same values (block1014).

If the attributes are the same, process1000sets Compare Status to “Unchanged” (block1016) and go to block1020. If the attributes do not have the same values, process1000sets Compare Status to “Changed” (block1018).

Process1000then checks whether there are more objects to compare in the snapshot2(block1020). If there is no more object in snapshot2to compare to, process1000traverses through the entire current snapshot1and mark as “Added” any object that is not marked “Deleted”, “Unchanged”, “Changed” (block1022). Process1000then terminates.

If an object in snapshot2does not have a corresponding object in current snapshot1, then process1000marks the object Compare Status as “Deleted” and adds the “Deleted” object to the current snapshot1(block1010). Adding the object means adding a reference to it. Process1000then terminates.

FIG. 11shows exemplary lists of methods (i.e., procedures) and properties of the Snapshot module and of the various Map objects. These methods and properties are visible to the user. These lists are only exemplary, and are not complete.

The Snapshot module provides a common user interface with a set of properties and methods, through which the functionality of the present invention can be accessed.

The Create method (within group1104) can be used to create a snapshot of specified resources. A user can specify which type of resources can be included in a snapshot by selecting the properties File, Process, Hardware, or Registry (within group1108) of the Snapshot module and setting the selected properties to TRUE. The Create method of the snapshot module in turn calls a Create method in each one of the Map objects, that is, File Map, ProcessMap, HardwareMap, and RegistryMap. These map objects then hold a collection of the file, process, hardware, or registry objects, respectively. These map objects, i.e., the File Map, the Process Map, the Hardware Map and the Registry Map have their own special properties and methods, which can be accessed via the Snapshot module.

The properties and methods of the map objects provide the functionality needed to create and compare the individual types of System State objects that they hold. For example, Path and Mask properties (within properties group1114) of the FileMap, are a means for specifying the path and mask combination of the location of the file system that needs to be recorded by the snapshot. Similarly, Path_Key (within properties group1120) is a property of the Registry Map and specifies a particular part of the registry. A Path_Count property (within the properties group1114) provides a means for counting the number of path entries specified. Similarly, a Key_Count property (within the properties group1120) of the Registry Map, provides a means to count the number of Path_Keys specified.

Some properties or methods of the map objects are common to all map objects. These are Count, Item and Remove properties or methods which are standard properties and methods of all collections. The Count property returns the number of objects in the collection of objects held by any map object. The Item method allows access to a single object in the collection of objects held by a map object by specifying the name or index of the desired object. The Remove method removes a user specified object from the collection of objects held by the map objects. These common properties of the map object as well as the individual system objects can be accessed through the common interface of the Snapshot module by using the methods and properties from group1110.

A Compare method in group1104of the Snapshot module can be used to compare snapshots of system states taken at different times. A Compare method is preceded by a Load method (within group1106), which is used to load a previously taken snapshot from the disk and load it into memory. Subsequently, Compare calls the Compare methods in each of the individual map objects to compare the collection of the currently held System State objects in the map objects with the System State objects of the snapshot loaded into the memory. The result of this compare operation is that any changes, additions or deletions of objects and their values between the two snapshots is marked out in the snapshot currently held by the map objects. Thus, after the Compare operation, the collection of System State objects held by the map objects reflect the changes, if any, between the two snapshots. These changes can be restored, so that the current snapshot is returned to its original state by using a Restore method (within group1106). Also, a SaveAs method72can be used to save any snapshot into the disk.

There are properties in the individual map objects that can be used to define what attributes of the System State objects should be considered or ignored while performing the compare method. For example, the property Compare Drives (within the properties1114) and the property Compare Path (within the properties1114) in the FileMap can be set to false, which would indicate to the Compare method that any differences in drive names, or path names between the two snapshots should be ignored. It would indicate to the compare method that only the values defined by the particular drive and path combination should be compared. Similarly, Compare PID and Compare Path properties (within the properties1116) of the ProcessMap can be used to ignore comparisons on the basis of PID's and paths when comparing processes running on the system. Also, a Search Key property (within the properties1120) of the RegistryMap can be used to specify a particular value that needs to be searched in a part of the registry specified by the Path Key.

The set of properties within group1112provide query information about the snapshots. Compare Status holds information as to whether a snapshot has been compared with another snapshot. Compare File Name provides the name of the snapshot against which the current snapshot was compared Storage Name provides the name of the file or the storage pointer of the current snapshot. Timestamp provides the time when the current snapshot was created.

FIG. 12is a block diagram illustrating a system1200comprising a second embodiment1210of the Resource Monitor system and a Contrast Manager system1202.

Embodiment1210of the Resource Monitor system comprises a MonitorRequest module1212, a monitor1214, and an optional Resource Monitor Service1211. The MonitorRequest module1212may be started by the Snapshot module1204, or automatically started by the Resource Monitor Service1211upon reboot of the computer system that includes the Resource Monitor system1210.

The Contrast Manager1202comprises a Snapshot module1204and a plurality of Map objects including at least a RegistryMap1206and a FileMap1208. Contrast Manager1202may also include other map objects such as a ProcessMap, a HardwareMap and a CertificationMap. A user can interface with the Snapshot module1204using a User Interface1201which may be a scripting Application Program Interface (API) or a snap-in to a management console. Upon being instantiated, the Snapshot module1204instantiates the collection of Map objects1206,1208.

Embodiment1210of the Resource Monitor system comprises a MonitorRequest module1212, a monitor1214, and an optional Resource Monitor Service1211. The MonitorRequest module1212may be started by the Snapshot module1204, or automatically started by the Resource Monitor Service1211upon reboot of the computer system that includes the Resource Monitor system1210.

A user defines the parameters for the specified resources to be monitored the same way as in the case of defining parameters for a standard static snapshot of the specified resources. But instead of calling the Create procedure in the Snapshot module1204, the Monitor procedure is called. Upon receipt of a user request from the user interface1201to monitor specified resources, the Monitor procedure in the Snapshot module1204calls the Monitor procedure in FileMap1208. The Monitor procedure in FileMap1208then calls the CreateMonitor procedure in MonitorRequest module1212. The CreateMonitor procedure in MonitorRequest module creates a Monitor1214(which is just an empty object at this point), and returns to FileMap1208the reference to the newly created Monitor1214. The Monitor procedure in FileMap1208transfers all parameters of specified resources, i.e., the snapshot parameters defined by the user, to the new Monitor1214. FileMap1208calls the Monitor procedure in MonitorRequest module1212, which then calls the Monitor procedure in the new Monitor1214.

Monitor1214instantiates the Snapshot module1218to create monitored objects corresponding to states of the specified resources at that point in time. Upon being instantiated, the Snapshot module1218instantiates RegistryMap1220and FileMap1222, and creates the monitored objects shown as file objects12241through1224k. The Snapshot module1218, the map objects1220,1222, and the monitored objects12241, . . . ,1224kconstitute the Contrast Manager1216. The Monitor1214maintains links to the snapshot module1218and the Map objects1220,1222of the instantiated Contrast Manager1216. The Monitor1214maintains a link to a unique instantiation1216of the Contrast Manager.

It is noted that, in general, there are more than one Monitors at any given time, each maintaining a link to its unique instantiation of the Contrast Manager.

The Contrast Manager is implemented as a dll which runs in the process space of the initiator. Contrast Manager1202runs in process space1of the User Interface1201which is a snap-in, or script, or another exe. The Resource Monitor1210is a service, that is an exe, that runs in its own process space2. Contrast Manager1216runs in the same process space2of the Resource Monitor1210. One advantage of having an instantiation1216of the Contrast Manager running in same process space as the Resource Monitor1210is that low overhead is achieved since, once initiated, monitoring processes are running in a common process space. Overhead caused by communication between two different process spaces can be expensive in terms of time and usage of resources. Another advantage is that, with this scheme, only Snapshot module1204is used to create many monitors.

FIG. 13is a flowchart illustrating an embodiment of the method to be practiced with the system1200ofFIG. 12. For clarity reasons, the flowchart pertains to the case where the monitored objects are file objects.

The user request calls the Monitor procedure in the Snapshot module1204and passes the parameters of the specified resources (block1301). The Monitor procedure in the Snapshot module1204calls the Monitor procedure in FileMap1208(block1302). The Monitor procedure in FileMap1208then calls the CreateMonitor procedure in MonitorRequest module1212(block1304). The CreateMonitor procedure in MonitorRequest module creates a Monitor1214(which is just an object having no attributes of the specified resources at this point), and returns to FileMap1208the reference to the newly created Monitor1214(block1306). The Monitor procedure in FileMap1208transfers all parameters of specified resources to the new Monitor1214(block1308). FileMap1208calls the Monitor procedure in MonitorRequest module1212(block1310), which then calls the Monitor procedure in the new Monitor1214(block1312).

The Monitor procedure in the new Monitor1214creates an initialization thread A, and waits for error result or event from initialization thread A (block1314). An event indicates successful initialization of the Monitor1214. An error result indicates an error encountered during the initialization of the Monitor1214.

Thread A creates a snapshot of specified resources based on the parameters already received from the FileMap1208. In other words, thread A creates a collection of monitored objects corresponding to the specified resources (block1316).

If there is an error in creating the snapshot (block1318), thread A sets the currently created monitor status to “error”, and exits (block1320).

If there is no error in creating the snapshot, thread A sets up internal logic and makes request to receive notification of change regarding the monitored objects from the operating system (block1322). If there is any error at this point (block1324), thread A sets Monitor status to “error” and exits (block1326). For example, an error is encountered if a specified resource is already being monitored by an existing active monitor created prior to the new monitor. If there is no error, thread A creates at least one thread B to do the monitoring (block1328). Depending on the type of monitor and the number of monitored objects, more than one thread B may be needed. The monitoring function of thread B in this embodiment is the same as the one discussed inFIG. 4CandFIG. 4Dfor the first embodiment of the Resource Monitor.

After creating thread B (block1328), thread A causes the event indicating completion of the initialization of the Monitor, then thread A becomes the control thread for the Monitor1214(block1330). By becoming the control thread for the Monitor1214, thread A allows the user to have control of the Monitor1214via a user request to the Monitor1214. User requests include “Stop” to stop the Monitor1214from monitoring, “Start” to restart the Monitor1214, and “Quit” to terminate the Monitor1214.

The Monitor procedure in the Monitor1214sees the event caused by thread A (in block1330) or the monitor status “error” set by thread A (in block1320or block1326) and returns result to MonitorRequest module1212(block1332). MonitorRequest module returns result to the FileMap1208(block1334).

Thread B, created by thread A (FIG. 13, block1328) does the monitoring, which includes waiting for notification of any changes to the monitored objects. The monitored objects associated with one Monitor may be files or registry key values, but not both. If there are both types of monitored objects in one user request, then two different Monitors12141,12142are created to separately monitor each type of monitored objects. In other words, one Monitor12141would monitor the file objects, while the other Monitor12142would monitor the registry objects. It is noted that each Monitor1214iincludes procedures, i.e., program code, to handle either type of monitored objects, but for efficiency reasons, can only maintain a collection of monitored objects of the same type.

The monitoring function of thread B in this second embodiment is the same as the one discussed in reference toFIG. 4CandFIG. 4Dfor the first embodiment of the Resource Monitor.