To prove that the volume GUIDs really are the “true” path to the volume, copy one of the strings and past it into Explorer or the Run dialog. Running mountvol.exe without any arguments will show you help for the utility, but also the current Volume GUID to drive letter/mount point relationships. So how do we find the Volume GUID? The easiest way I have discovered is by the use of the mountvol.exe utility. When configuring highly available virtual servers in Hyper-V with Windows Failover Clustering, for example. This is actually the recommended practice in some situations. You can work around this by using mount points e.g., but you can also reference the volume by its GUID directly. On systems with a lot of storage you will often run out of drive letters for your partitions and volumes. This ensures that Windows can always uniquely identify a volume, even though its drive letter has changed. The Volume GUID is assigned the first time the OS encounters a volume and it does not change. (Windows Home Server, which is actually a custom version of Windows Server 2003 has done away with the use of drive letters completely.)This GUID is called the Volume GUID or the Unique Volume Name. Instead Windows uses a GUID to identify each volume or partition. However, the Windows operating system does not depend on them. Drive letters are still used today due to their ubiquity and for compatibility. The use of letters to identity volumes and partitions in Windows is something we have inherited from MS-DOS.

Windows 10 on volume 2