Where is the code that makes MOUNTDEV_UNIQUE_ID a disk signature + Partition offset?

[Terrydaktal]

When I looked at the mountmgr source code, I saw that it writes the unique ID to MountedDevices, which it takes from QueryDeviceInformation which gets it from IOCTL_MOUNTDEV_QUERY_UNIQUE_ID IRP, which im guessing is handled by partition.c which poses as volmgr, but when you go to case IOCTL_MOUNTDEV_QUERY_UNIQUE_ID, it gets the unique ID from partExt->VolumeInterfaceName.Buffer, which is taken only from IoRegisterDeviceInterface, which is always going to be a STORAGE#VOLUME STORAGE#REMOVABLEMEDIA or whatever string taken from InstancePath. There seems to be no check in partition.c as to whether disk is fixed, removable, superfloppy whatever, yet mysteriously my FAT C:\ volume has signature + offset in MountedDevices

[hbelusca]

I investigated a bit more the problem, you can find some details in this comment on CORE-15575.
It turns out that our partmgr (which also poses as part of volmgr functionality as you've noticed), didn't do the work of checking the nature of the volume/partition to build its unique ID in the expected format.
The PR #6926 in our GitHub repo aims at fixing (part?) of this.

[gbwadown]

That logic typically lives in the Windows storage stack, specifically within the volume manager (like `mountmgr.sys` or `volsnap.sys`). The `MOUNTDEV_UNIQUE_ID` is constructed to uniquely identify a volume, often using the disk signature (from the MBR) or GUID (from the GPT) combined with the partition offset to ensure uniqueness. You won't find this code easily in open source, as it's part of the closed-source Windows kernel. However, tools like WinDbg or reverse engineering techniques can help trace it if you're digging deep.