Driver installation and deinstallation

The driver to be deployed is rawdsk3.sys. Note, that the drivers are different for Win32, x64 (AMD 64-bit architecture) and IA64 (Itamium 64-bit architecture) platforms.

The debug versions of the drivers are located in "<CBFSDirect>\Drivers\Debug\32bit" or "<CBFSDirect>\Drivers\Debug\64bit" folders (for Win32 and Win64 platforms). The debug version should be used only during development of your application. It creates a log file on disk C:. If the driver is loaded and "chkdsk c:" is scheduled for boot time, the log file will prevent the disk from being checked. This is not a bug, but specifics of the debug version of the driver.

The release version of the driver is located in "<CBFSDirect>\Drivers\Release\32bit" or "<CBFSDirect>\Drivers\Release\64bit" folders (for Win32 and Win64 platforms). You can use the release version of the driver for both development and final deployment.

64-bit version of the driver is available for x64 (AMD64) processor architecture used by most modern 64-bit processors and IA64 (Itanium) processor architecture used by some Intel-produced server processors.

To install and/or uninstall the drivers during application deployment or deinstallation, use the functions exported by Installer DLL that is included within CBFS Direct package. This DLL can be freely distributed with your projects as long as it is used with the licensed version of CBFS Direct.

To install or uninstall the drivers from your main application use the calls in CBFS Direct API: InstallDriver and UninstallDriver.

Notes for 64-bit systems

CBFS Direct drivers are provided only unsigned (the reason is the policy of Certificate Authority companies regarding misuse of certificates, which can lead to revocation of certificate if the driver is misused). On 64-bit systems lack of driver signature prevents drivers from being loaded. You need to sign the provided driver using your driver-suitable code-signing certificate. Not any certificate will work. You need a certificate from the certificate authority, for which a cross-certificate exists and is available (see Microsoft site). Currently all major CAs have the corresponding cross-certificates.

Signing the driver (pre-Windows 10)

To sign the driver, use signtool.exe tool from Windows Driver Kit (freely available on Microsoft site).
Sample command line is:
"%DDKBASE%\7600.16385.0\bin\x86\signtool.exe" sign /T /ac "/path/to/cross-certificate.cer" /s MY /n "Subject name of the certificate" cbfsdirect2017.sys

Signing the driver (Windows 10)

To perform code signing of the drivers, you need to obtain the Extended validation (EV) code signing certificate and register it for kernel-mode signing. The procedure is described on

The files, needed for driver signing submission, can be found in "\Program Files\CBFS Direct\Drivers\release\" directory.

First you need to create a CAB file by running the following command in the above directory:

makecab.exe /V3 /D "ver"="2017" /F cbfsdirect2017.ddf

Next you need to sign the created CAB file with the EV certificate using this command:

"\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe" sign /T /n "Subject name of the certificate"

Next we create a driver signing submission on

The form fields on the page are to be filled as follows:

  • Name - The value for further identification of the particular submission.
  • Qualifications (checkboxes), all must be set.
  • All drivers are Universal - choose No
  • File - choose the created and signed file on your disk and press Upload button
Click Submit button.

The new page, titled "Manage Driver Signing submission #XXXXXXX" will be opened. You can refresh the page from time to time or wait until the email with the "Review Complete: Submission Number XXXXXXX" subject comes from .

After the signing is complete. the file will be available for downloading. This file will contain the signed drivers for x86 and x64.

Combining the signing procedure with "old-style" signing for versions of Windows prior to Windows 10

There are two ways to sign drivers in the way, compatible with Windows 10 and with previous versions:

  1. First you sign the drivers in "old-style" way, then sign the already signed drivers in the way specified above. In this case, there will be an informational message shown when you install the drivers.
  2. Sign separate sets of files for Windows 10 and for previous versions of Windows. In this case, the drivers, signed for Windows 10, will be installed into Windows 10 without any messages, however you'll need "old-style" signed drivers to be installed to the previous versions of Windows.

Required Permissions

By default installation and deinstallation of the driver can be performed from the user account which belongs to Administrators group. This is a security measure of Windows operating system. You can change this behaviour on the target system by adjusting the list of users and groups who have the right to install and uninstall the drivers. This can be done in Control Panel -> Administrative tools -> Local Security Settings -> Local Policies \ User Rights Assignment (tree branch), there you need to change "Load and Unload device drivers" item. No need to say that by default you can change the security settings if you are system administrator.

Notes for Vista and Windows 7

If you have UAC (User Account Control) enabled, Vista and Windows 7 will run applications started by you with limited rights even when you are logged in as administrator or member of Administrators group.

If you install or uninstall the drivers by calling the above mentioned functions in your code, you need to elevate privileges of your application so that it's started with truly administrative rights.

To elevate privilages for your application, you must start it with Run As Administrator option. In Windows Explorer this is done using Run As Administrator command in context menu for the application. Alternatively you can set the corresponding option in the Properties window shown for your executable module.

One more option is to use the manifest. The manifest file can be placed next to the executable of your application or embedded into the executable. If you decide to keep the manifest in a separate file, it must be named <EXEName_with_extension>.manifest, eg. for MyApp.exe the manifest should be called MyApp.exe.manifest.

You can use the following manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity version=""
<description>elevate execution level</description>
   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
            <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>