Disconnect the old network volume and remap a new network volume to the same local drive letter (for example, D:), the drive label continues to display the disconnected/old volume name

Question

Problem: When a user disconnects an existing network volume (for eg: \server\VOL_1) and maps a new network volume(\server\VOL_2) to the same local drive letter (for example, D:), the drive label continues to display the old volume name (VOL_1), while the contents belong to the new volume(VOL_2). This results in an incorrect drive label being shown.

Workaround: If the user restarts Windows Explorer (explorer.exe) from task manager, the correct drive label is displayed. This indicates that the issue is related to Windows Explorer’s in-memory UI data structures not being refreshed.

Steps we are doing as a part of mapping the new network volume:

step1) First we disconnect the old network volume and then map the new network volume. After mapping the new network volume, we start a new Explorer UI window, not a new explorer.exe process.

ShellExecute(hDialog, NULL, m_szLocalName, NULL, NULL, SW_SHOWNORMAL);

Here, m_szLocalName is D:.

Since this launches a new Explorer UI window within the existing Explorer process, it continues to use the same in-memory cached drive metadata. As a result, the old drive label is still displayed.

step2) Shell notification attempts We attempted to refresh the Explorer state by invoking SHChangeNotify with multiple notification types after step (1), but the behavior remained unchanged.

SHChangeNotify(SHCNE_DRIVEADD, SHCNF_PATH, L"D:\“, NULL); SHChangeNotify(SHCNE_UPDATEDIR, SHCNF_PATH, L"D:\”, NULL); SHChangeNotify(SHCNE_UPDATEITEM, SHCNF_PATH, L"D:", NULL); SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, NULL, NULL); These notifications did not cause Explorer to refresh the cached drive label.

step3) Filesystem access attempts prior to launching new Explorer UI window (step1). We also tried performing filesystem operations on the newly mapped drive (D:) before launching the Explorer UI window, using APIs such as: CreateFile, FindFirstFile Even with these operations, the Explorer UI continued to display the old drive label.

VOL_1Mapping.png VOL_2Mapping.png

VOL_2Mapping.png VOL_1Mapping.png

Implemented Solution: As users are not agreeable to restarting Windows Explorer, we are addressing the issue by starting a new Windows Explorer instance (Explorer instance 1) for this use case. In the new Explorer instance, the drive label is displayed correctly. If a user remaps a network drive to the same local drive letter, a new Windows Explorer instance will be started.

Limitation of the Solution: The original Windows Explorer instance (Explorer instance 0) continues to show the old drive label. This happens because Windows Explorer synchronizes all loaded Explorer instances when a network drive/volume is mapped, and the in-memory data for the existing instance is not refreshed.

Request you to share your suggestions, comments. Thank you very much

Answer 1

Hi @Aditya Borah ,

Thanks for reaching out.

In this case, I would also agree that starting a new Explorer instance after remapping the drive is a practical way to help users see the updated label, without requiring a full Explorer or system restart. While it doesn’t update existing windows, it avoids disrupting the rest of the user session.

Since this problem relates to how Windows works internally, I would suggest sharing feedback directly with the Windows team via Feedback Hub. You can open it by pressing Win + F, or by searching for “Feedback Hub” from the Start menu. Including your repro steps and screenshots can help the team better understand the scenario.

Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.