How to remove the driver - the procedure and caveats

Most products of Callback Technologies include a kernel-mode driver or two installed in the system. This article covers the products for developers (class libraries).

The installation and deinstallation of the driver(s) are performed using the calls to the product API. These can be the Install() and Uninstall() methods of the corresponding main class or classes of the product, or these can be the functions exported by the dedicated installer DLL, shipped with the product. The functionality of the main methods and the installer DLL is the same, so below, the methods are referenced but the information is equally applicable to the functions of the installer DLL.

Each kernel-mode driver installed by the products of Callback Technologies is a shared resource, i.e., it can be installed by more than one application. Each installation is defined by the product GUID, which uniquely identifies the master application for the driver. An application may need to install the driver several times with different GUIDs. One way or another, each driver is usually present in the system once - as a .sys file in the \Windows\System32\Drivers directory - and is referenced by a registry key. However, each separate installation made with a distinct GUID is recorded in the Windows registry; all recorded GUIDs work as an installation counter. There exists a separate case when a driver is installed to a different location in the system, in which case it makes another .sys file somewhere within the filesystem, and there's another dedicated record made in the registry.

When the driver is uninstalled using the Uninstall() method, the method's code first checks if the driver may be uninstalled. If the driver is busy (serves a virtual filesystem, has active filter rules, etc.), deinstallation is aborted, and an error is returned.

The Uninstall method receives a product GUID from the application, and this GUID is removed from the registry. An attempt to delete the driver file from the filesystem is made only when the removed GUID is the last in the registry, i.e., when no other applications need the driver. If there exist other applications that may need the driver, the Uninstall method reports success, but the driver file remains.

Now, even when the deinstallation process continues, the driver file may still be locked. If this happens, the deinstallation code schedules a file deletion operation until reboot, and the Uninstall() method returns the result that indicates that reboot is required. After the system is restarted, the driver file should be gone.

If the system is restarted and the file remains, there are several reasons possible. The main reason is that there are other application GUIDs in the registry that tell the uninstaller code that the driver is used by other applications. The secondary, albeit very rare, reason is that something has corrupted the information about the scheduled deletion (this information is stored in the registry, and it is not impossible to alter it in the wrong way).

The driver that resides in the Windows' Drivers directory is not loaded by Windows unless there is a registry record that tells the OS to load this specific driver. So, if you want to investigate why the file remains, you need to look into the Registry. All drivers are registered in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services key, and each driver has its own subkey there. Drivers of Callback Technologies use the subkeys that start with "cb" and end with the version's last two digits, e.g., "cbfs24", "cbfilter22", and so on. You need to inspect the contents of the corresponding key and its subkeys. If you see unexpected GUIDs there, this is the reason for the driver not being uninstalled. If you find no GUIDs there, then it is safe to delete the main driver's key from the registry - this will prevent the driver file from being loaded upon the next system start, and so, after rebooting the system, you will be able to manually delete the driver. If there are extra GUIDs there, then it makes sense to keep the record intact and figure out which other software may be using the driver.

If the driver cannot be deleted manually after reboot, this can mean one of two reasons - either the system has found a registry entry and loaded the driver, or you are trying to delete the driver file from a regular (non-elevated) account. The Drivers directory is protected, and you need to run the command line interface or a file manager that you are using with elevated privileges in order to be able to delete the driver file.

Important: don't try to delete the driver file without removing a registry entry first. Doing this will lead to the situation upon reboot when the system cannot find the removed driver and crashes with a BSOD. A remedy for this is to boot in the safe mode and use the Registry Editor to remove the record from the Windows registry.