Monitoring Drivers and Devices
Drivers and devices selectable for monitoring are displayed in a tree structure on the left half of the window. The right section of the window allows specifying types of IRP and fast I/O operation reported for given drivers and devices. To monitor certain driver and/or device, the user has to right click to the corresponding node and indicate what types of operations should be monitored.
Figure 1: The Select Driver / Device window
Drivers are represented by root nodes, whereas devices form their children. Each driver includes its devices as children of its node (but not necessarily its direct children). Also, devices that do not belong to the driver but are present within a stack with at least one of its devices are also made children of the driver node. Names of such nodes contain either LOW, or UPP prefix indicating whether they are placed below or above driver's device within the stack. Requests travel from stack´s top (upper devices) to its bottom (lower devices).
Figure 2 shows how the disk driver, disk.sys, and its devices are displayed in the tree structure. The driver is named \Driver\disk and owns two devices: \Device\Harddisk0\DR0 and \Device\Harddisk1\DR1. Both are placed in the middle of device stacks – the former one is attached to a device belonging to \Driver\atapi, the latter one lies above a device from \Driver\USBSTOR. The partition manager driver, partmgr.sys, places its devices into both stacks, above the disk ones.
Figure 2: Disk driver, disk.sys, displayed in the tree structure
To monitor a driver or device, the user has to right click on the corresponding node and check one or more of the following options:
- Hooked.
- Device extensions.
- New devices.
- Data
- IRP.
- IRP completion.
- Fast I/O.
- Start I/O.
- AddDevice.
- Unload.
Some of the options (AddDevice, Unload, New devices) are specific to driver monitoring. When the user marks them for a device node, the change is propagated to the parent driver.
An extra amount of data may be associated with certain types of requests. IRPMon is capable of collecting these data for some IRP reqeust types, such as Read, Write, DeviceIoControl and PnP. Because collection of such data may be potentially dangerous (i.e. may crash the system), IRPMon does not perform the collection by default. The user needs to check the Data menu item to enable the collection for particular driver or device.
To monitor particular device, the user has to ensure that its driver is also being monitored. When the user checks the Hook option a device, the application attempts to propagate the change to device's driver.
To restrict the monitoring only to certain IRP and/or fast I/O requests, the may utilize the right area of the window. There is one checkbox for each IRP and fast I/O request type. These checkboxes reflect the monitoring state of the current node and their changes are immediately saved (however, they are propagated to the IRPMon driver after the user presses the Ok button).
The Device extensions menu item select the way of hooking the target driver. If not checked, the IRPMon driver rewrites target´s IRP and fast I/O dispatch handlers. This may, for some important system drivers, trigger Kernel patch Protection some time later, causing a CRITICAL_STRUCTURE_CORRUPTION bug check. TO avoid such an unpleasant situation, the IRPMon driver searches device extension of the device just above the target and overwrites all references to the target with address of a newly created proxy device. Since, device extensions are considered private for their devices, it is expected that htey are not protected by Patchguard.
Since this hacky method of hooking a device object requires to modify device extension of its immediate upper device, only devices not present on top of their stack can bee hooked. Additionaly, the IRPMon driver either uses the device extension hooking for all devices of a given driver, or not at all; it is not possible to hook some devices by modifying driver´s dispatch handlers and some by device extension modification.
To fool the driver handling the direct upper device, the proxy device created by the IRPMon driver shares many characteristics with the target device. Namely
- device type,
- device characteristics,
- reference to the next upper device,
- stack size,
- sector size,
- alignment requirements.
To set up logging of events that happen during the boot procedure of the computer. Use the GUI to set the drivers' startup to 'boot'. Use the command line tool to write the desired settings to the registry, that way when the driver is initialised early on in the boot process, it'll know what configuration to load and record events even before the desktop is started.