Typically, stand-alone (or monolithic) file system drivers are loaded from an AutoLoad key in the storage manager registry. However, using this mechanism is not always an option, especially for ISVs. An alternative approach to loading a monolithic FSD is to get the FSD manager to load it in response to a “dummy” block driver. Once loaded, the block driver doesn’t actually perform any function—it is simply required to initially boot-strap the loading of the FSD.
The simplest way to implement a dummy block driver is to add stream driver exports to your exiting FSD DLL and add a BuiltIn driver registry key so device.exe will load it when the system boots.
; Dummy Block Driver key used to install “MyFileSystem”
Next, you’ll need a storage profile registry key so that storage manager loads your file system in response to the dummy block device starting.
; Empty partition table indicates that storage manager
; should use the file system key referenced by
; “DefaultFileSystem” under the profile key.
; Profile key for the dummy block driver. No partition
; driver should be used, and we always want to mount
; “MyFileSystem” on this device.
Finally, you’ll need a file system registry key so that storage manager knows what FSD DLL to load.
; Key for “MyFileSystem”
In addition to the registry changes, you’ll also need to support two IOCTLs in the DSK_IoControl function of the dummy block driver:
IOCTL_DISK_GETINFO: it doesn’t matter what they return in the DISK_INFO structure, just return TRUE.
IOCTL_DISK_DEVICE_INFO: report the profile name, DummyProfile in this case, in the STORAGEDEVICEINFO structure returned and return TRUE.
Once of the great benefits of loading your FSD using a dummy block driver is that you can programmatically load and unload the FSD using the ActivateDevice and DeactivateDevice APIs. This means, you can install your file system without rebooting the OS, and you can programmatically mount or un-mount in response to system events.