This problem is caused by a bug in the GetVolumeNameForVolumeMountPoint Win32 API function on the products listed in the "Applies to" section of this article. It occurs only for volumes that have been assigned multiple unique volume names (GUIDs).
The problem has been corrected in the following products:
- Windows Server 2008 -- All versions
- Windows Vista Service Pack 1
Applications that must run on the affected products can work around this bug in one of two ways. The first is to open the volume with the CreateFile Win32 function and then calling the DeviceIoControl function to issue the IOCTL_MOUNTMGR_QUERY_POINTS command.
The second way is by calling GetVolumeNameForVolumeMountPoint twice. In the first call, pass the target volume name as documented (usually as a the drive letter in the format X:\) in the lpszVolumeMountPoint parameter. This call will return one of the assigned unique volume names in the lpszVolumeName parameter. In the second call, pass the volume name returned by the first call in the lpszVolumeMountPoint parameter. This will cause GetVolumeNameForVolumeMountPoint to return the expected volume name.
The sample below to see how you might call GetVolumeNameForVolumeMountPoint() twice to get the expected results.
int _tmain(int argc, TCHAR* argv)
TCHAR szGUID1 [MAX_PATH];
TCHAR szGUID2 [MAX_PATH];
if (argc != 2)
wprintf(L"%s <x:\\> \n\n", argv);
_tprintf(TEXT("Calling GetVolumeNameForVolumeMountPoint for %s\n"), argv);
// On the first call to GetVolumeNameForVolumeMountPoint
// pass in whatever you would normally pass in
if (GetVolumeNameForVolumeMountPoint(argv, szGUID1, MAX_PATH))
_tprintf(TEXT(" GUID1: %s\n\n"), szGUID1);
// On the second call, pass in the Volume Name received from the first
// call to GetVolumeNameForVolumeMountPoint
if (GetVolumeNameForVolumeMountPoint(szGUID1, szGUID2, MAX_PATH))
_tprintf(TEXT(" GUID2: %s\n\n"), szGUID2);
CreateFile, DeviceIoControl, and IOCTL_MOUNTMGR_QUERY_POINTS are documented in the MSDN Library on http://msdn.microsoft.com.
A volume can be multiple unique volume names (and thus multiple GUIDs) when it is used by multiple running installations of Windows. This could happen in the following scenarios and in similar scenarios where multiple installations of Windows have accessed the volume:
- Dual booting two or more copies of Windows which access the drive.
- Using a volume on a shared disk in a cluster where multiple nodes have accessed the volume.
- Moving the disk which hosts the volume from one computer to another.
- In a SAN environment where the volume was assigned to multiple instances of Windows.
In these situations, each running instance of Windows will assign its own GUID to the volume. Furthermore, each instance will enumerate all of the volume names and mount points assigned to the volume and thus will see multiple GUIDs. However, not all GUIDs may be used by the specific instance of Windows that is currently running. This is why the volume name returned by GetVolumeNameForVolumeMountPoint may be "incorrect."
The MOUNTVOL.EXE tool always returns the correct volume name.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.
Article ID: 959573 - Last Review: Nov 4, 2008 - Revision: 1