Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Blocking Direct Write Operations to Volumes and Disks

Some of the most compelling new features in Windows Vista are its guarantees regarding code and data integrity. To better protect Windows Vista from potentially malicious techniques, changes to the storage driver stack have been introduced to block direct write operations to volume and disk handles. If your application or driver writes directly to a volume that has a file system mounted on it, without first obtaining exclusive access to it, you could cause corruption or system instability, or both. This is because those writes might collide with other changes coming from the file system and leave the contents of the volume or file system, or both in an inconsistent state. To prevent this, we have made the following changes.

Write operations on a DASD volume handle will succeed if the file system is not mounted, or if:

  • The sectors being written to are the boot sectors.

  • The sectors being written to reside outside file system space.

  • The file system has been locked implicitly by requesting exclusive write access.

  • The file system has been locked explicitly by sending down a lock/dismount request.

  • The write request has been flagged by a kernel-mode driver that indicates that this check should be bypassed. The flag is called SL_FORCE_DIRECT_WRITE and it is in the IrpSp->flags field. This flag is checked by both the file system and storage drivers.

The changes that are mentioned previously will not apply if the file system on the volume is not mounted or the volume has no file system.

Write operations on a disk handle will succeed if:

  • The sectors being written to do not fall within a file system.

  • The sectors being written to fall within a mounted file system that is locked explicitly.

  • The sectors being written to fall within a file system that is not mounted or the volume has no file system.

In addition to the various Win32 File I/O API routines (such as WriteFile), there are device I/O control requests that can be used to issue write operations to a volume or disk. The changes mentioned previously will apply to the device I/O control requests as well. They include the following:

































The application needs to lock the volume, dismount the volume, or both, before it can issue DASD I/O. This is new to Windows Vista and was done to address potentially malicious techniques.

  1. The file system will block all write operations to reserved sections of the disk. In this case, those reserved sections include the MBR and the two FAT areas. To block these areas, you need to lock the volume by sending FSCTL_LOCK_VOLUME. You must issue this structure on the same volume handle that performs the actual write operations. This request can fail if there are open file handles. In this case, the application can force a dismount of the file system by issuing FSCTL_DISMOUNT_VOLUME. However, the volume is not actually dismounted until the file handle is closed. Until then, the application can continue to issue DASD I/O by using the same file handle that is currently open.

  2. There is an extended region beyond the volume space that is known to the file system where write operations will be blocked. To allow write operations to this region, you must issue FSCTL_ALLOW_EXTENDED_DASD_IO on the volume handle.

You can use the Win32 API routine DeviceIoControl to issue all the previous FSCTSs.

For more information, see INFO: Direct Drive Access Under Win32 and Changes to the file system and to the storage stack to restrict direct disk access and direct volume access in Windows Vista and in Windows Server 2008.



Send comments about this topic to Microsoft

© 2015 Microsoft