Well, today’s post isn’t a fix per se. It isn’t even a tutorial, but I think that the information contained herein is invaluable for understanding disks and troubleshooting disk management issues.
A lot of us have a real rudimentary understanding of how disks and volumes are managed in Windows. Most of this comes from the overly simplistic and dumbed down models that we are given when studying for the A+ designation or it is an understanding that we gained long ago when FAT32 was the predominant file system in use.
A lot has changed since then, and I want to take you on the journey to understanding what is actually happening behind the Disk Management MMC.
So let’s begin at the root of disk management in modern versions of Windows. That swanky mmc that we all know and shown below is actually loaded through a Windows dll named dmdskmgr.dll. The functionality of this dll is simple. When it is loaded into memory it will in turn scan disks attached to the system looking for a LDM database. If it finds disks from the local computer, it will simply report the volumes that are present, however, if it happens to find an LDM from a foreigner computer it will then execute the import disk mgr which essentially just copies the foreign LDM and adds it to dmdskmgr.dll’s in memory copy of the database. Should you choose to import the disk, then it is essentially just committing the database write operation to the foreign disk which is actually done through a kernel mode dll called volmgrx.sys. Volmgrx.sys is actually the workhorse behind dmdskmgr.dll as it control the access to disk objects such as the LDM and the resident volumes.
Understanding this process alone goes a long way in troubleshooting why a disk might not be recognized or importable etc. While entirely out of the scope of this article, one could actually write a tool to manipulated the LDM itself and allow you to fix issues on a disk at a very low level.
Now, how does volmgrx.sys actually work. This is actually fairly straightforward in most cases. Disks all contain disk relative offsets which are essentially a number of sectors from the start of a partition table to the actual partition itself. The job of volmgrx.sys is to simply add the volume-relative offsets to the disk-relative offsets and allow the operating system to map I/O to the underlying partitions themselves.
On a multi-partition disk setup using spanned, mirrored, or some other flavour of RAID, thsi naturally becomes more complex. It is NTFS iself that allows us to create these types of volumes.
NTFS creates a bitmap file that can be added to or reduced at will. It is this file that tells the volmgrx.sys kernel mode dll where a logical volume begins and ends. Thus, to the OS itself the drive appears to be just a normal drive. In the days of FAT this was not possible as the whole partion table would have needed to be moved and thereby dislocating the data on one partition from the other. Then the volmgrx.sys will keep referring to the bitmap created to determine where free clusters are located and will logically write to these as necessary.
This process is virtually identical for all of the multi-partitioned types except for RAID 5 arrays where obviously the parity bit is also striped across the drives.
One last area that I would like to touch on is mirrored volumes. Some people have asked me why Windows cannot boot from spanned drives, Raid 5 arrays etc., but yet can boot from a mirrored volume which is a multi-partitioned volume. The answer to this is simple. The Master Boot Record code sees the disk as one volume and only boots from half of the mirror which is marked as the boot volume.
Anyway, I hope this goes a long way toward helping you understand at a deeper level how Windows manages disks. I also want to give proper credit to Mark Russinovich et al. for the inspiration to write this article. Most of the material comes from his Windows Internals fifth edition book and I highly recommend this book for anyone who wants to understand Windows at a Engineering level.