2

I'm currently experimenting with my own backup software, and just wondered where the NTFS volume GUID (i.e. the one that appears as \?\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}) is actually stored, offset wise, on the partition? Is it always at a calculatable offset, or is it part of the $MFT or $Volume record or something like that?

squillman
  • 37,618
  • 10
  • 90
  • 145
PhilPotter1987
  • 141
  • 5
  • Does this help: http://www.ntfs.com/guid-part-table.htm – Ryan Ries Oct 14 '13 at 22:56
  • Or this: http://support.microsoft.com/kb/302873 – hookenz Oct 15 '13 at 03:58
  • These both seem to refer to GPT style partition tables, my machine is currently using MBR. – PhilPotter1987 Oct 15 '13 at 19:28
  • Not sure if it helps, but I found it in every sector from 360 to 395 in a mounted vhd.The ordering of the hex values was significantly rearranged and the first octet was different from the value in MountedDevices in the registry. Try using a hex editor like HxD to search for the last portion of the guid as that appears verbatim. – sahmeepee Oct 15 '13 at 22:33

2 Answers2

2

I spent hours in front of a partition with my hex editor and discovered that the $VOLUME_NAME attribute of the $Volume metafile is actually just that - the textual volume name seen in 'Computer' and the likes - i.e. "My Disk"

It turns out that the GUID style I asked about above is stored only in the mount manager database within the registry at MountedDevices. What finally led me to this is that the same disk (with the same serial number on its NTFS partition) will get a different GUID if you plug it into a different machine.

PhilPotter1987
  • 141
  • 5
  • Just to confirm: I made the same discovery using roughly the same process. Booting the computer between W7 and W10, I see different guids output from MountVol.exe for the same drives. – David Wohlferd Jun 02 '18 at 12:26
  • I was looking for the same and found some useful details at MS Site (search with following title in case MS link expires): [Supporting Mount Manager requests in a storage class driver](https://docs.microsoft.com/en-us/windows-hardware/drivers/storage/supporting-mount-manager-requests-in-a-storage-class-driver) – subdeveloper Nov 25 '20 at 09:01
1

I spent some time trying to answer that.

Eventually I found this for MBR disks:

Step 1
GUID is formed as {UUUUUUUU-0000-0000-PPPP-PPPPPPPPPPPP}, where

  • UUUUUUUU is disk's UNIQUEID (can be seen/changed in diskpart's uniqueid disk command)
  • 0000-0000 are always zeroes
  • PPPP-PPPPPPPPPPPP is partition's byte offset (can be seen in diskpart's detail partition command), hex-encoded with inverse byte order.

Step 2

  • If driver supports IOCTL_MOUNTDEV_QUERY_STABLE_GUID, then whatever GUID is returned will be used as volume GUID. Otherwise, ExUuidCreate() is used to create a new GUID.
  • Before Win10, IOCTL_MOUNTDEV_QUERY_STABLE_GUID is not supported for MBR disks.
  • Starting with Win10, for MBR disks, if it's not removable + some other unknown conditions, GUID from step 1 is used as volume GUID. As a result, it will have a lot of zeroes.

Step 3
The resulting GUID is stored in HKLM\SYSTEM\MountedDevices. It maps Volume GUID (value name) to volume's identifier (returned by IOCTL_MOUNTDEV_QUERY_UNIQUE_ID). For MBR disks, identifier matches GUID from step 1.

If disk's UNIQEID is changed, Windows will fail to boot (because it can no longer find boot volume). If boot configuration is fixed by running bootrec /rebuildbcd from recovery, windows boots and volume will have a new GUID, where only the first 4 bytes will change to match the new disk's UNIQUEID.

Some relevant locations in Windows code:

  • mountmgr!CreateNewVolumeName
  • mountmgr!QueryDeviceInformation
  • volmgr!VmpQueryStableGuid
Codeguard
  • 111
  • 3