Additional Technical Detail

The following sections provide detail that was too long to fit into the body of the white paper. 

Agentless Data Snapshots

An agentless backup and recovery solution uses either the default Windows volume snapshot driver, or temporarily injects a custom driver during the backup process; removing it afterward. Either of these options lead to less-than-optimal results.

  • When using VolSnap (the default Microsoft snapshot provider available on Windows XP or later) the incremental backups are unacceptably slow. This is because VolSnap does not expose a mapping of the blocks which have changed from one snapshot to the next. Because of this, backup applications that use VolSnap.sys must perform differential comparison operations each time a snapshot is created in order to determine what has changed. Differential comparison operations are very time consuming and resource intensive, and should be avoided if possible.
  • Injecting a custom driver without rebooting, using a technique known as IRP Dispatch Table Hooking, can destabilize the system, resulting in system crashes, unrecoverable data corruption, and full system deadlocks. It risks system stability and data integrity. (See the NT Kernel development forums at osronline.com)

Filtering

Both agent-based and agentless solutions must leverage volume snapshot capability (provided by a snapshot driver in the Windows kernel) in order to provide efficient and reliable backups. Vendors can rely on VolSnap.sys or provide a custom snapshot driver. As previously mentioned, using VolSnap.sys results in slow and resource intensive incremental backups. Using a custom snapshot driver can solve this problem, but the method used to install that driver becomes an issue.  The Windows operating system must reboot to properly install a snapshot driver.

Drivers in the Windows kernel interact in layers, forming a storage driver stack that consists of the following (from highest level of abstraction to lowest):

  • File System drivers
  • Logical Volume drivers
  • Disk drivers
  • Port/Miniport drivers
  • Host Bus Adapter (or storage controller)

It is possible to insert kernel drivers into the storage driver stack at any layer except the port/miniport driver, the lowest level). These custom drivers exist to add functionality not provided by the base storage driver stack. For example, Microsoft inserts its snapshot driver (VolSnap) into the storage stack between the File System drivers and the Logical Volume drivers.

IRP Dispatch Table Hooking – More In-Depth

IRP Dispatch Table Hooking is a method used by some software vendors to inject drivers into an existing operating system driver stack. In the context of backup and recovery, it allows a vendor to claim and "agentless" solution by injecting the driver when it is needed, then removing it. Unfortunately, this practice regularly leads to system instability, and because of this it is specifically discouraged by Microsoft.

How does IRP Dispatch Table Hooking Work?

Windows loads a kernel-mode driver and initializes it by making a one-time call to the DriverEntry initialization routine in that driver.  The system passes the MajorFunction dispatch table/array to DriverEntry.

A hooking driver intercepts the I/O of another driver by modifying its dispatch table with memory addresses for code that resides in the hooking driver. This results in the operating system sending I/O requests to the hooking driver instead of to the original driver. Minor change for grammar DriverEntryration by the kernel, which then initializes the driver by calling the driver'ginal driver.

IRP Dispatch Table Process Steps

See the IRP Dispatch Table Process Flowchart below.

The hook/filter injection (using IRP Dispatch Table Hooking) follows these steps in this order:

  1. The Windows OS kernel loads the Hooking driver and calls the its initialization routine (called DriverEntry).
  2. The Hooking driver locates the MajorFunction dispatch table of the Hooked driver, which table contains memory addresses (called “function pointers”) of routines within the Hooked driver that handle I/O requests.
  3. The Hooking driver copies the original (unaltered) function pointer values of the Hooked driver’s MajorFunction dispatch table to a duplicate table owned by the Hooking driver.
  4. The Hooking driver alters the function pointer values of the Hooked driver’s MajorFunction dispatch table with memory address values (function pointers) of routines within the Hooking driver.
  5. The operating system now calls routines in the Hooking driver when it attempts to send I/O operations to the Hooked driver.  When the Hooking driver receives an I/O request, it can do what it likes with the request, after which it may forward it on to the Hooked driver’s routine using the copy of the Hooked driver’s dispatch table.

 

Terms and Conditions of Use - Privacy Policy - Cookies