none
Impossible to remove a persistent network drive mapping when logged on disconnected RRS feed

  • Question

  • Initial situation (tested with Windows 10, 8.1, 7 and XP):
    1. Create a persistent (!) network drive mapping (a.k.a. "Reconnect at logon") using the integrated/official "Map Network Drive" dialog .
    2. Now physically disconnect from the network folder (unplug the cable or shut down the target system)
    3. Log off and on again. A balloon message will tell "Could not reconnect all network drives", but the drive will still be visible in the Explorer (with a red cross). The balloon message is the best indication that you've reproduced the steps correctly.

    At this point I'd like to remove that network drive using my software.

    There are multiple ways to do this.
    - Probably the easiest way to reproduce it is by command line: net use X: /delete
    - API: WNetCancelConnection2 or WNetDisconnectDialog1
    - Disconnect dialog: Explorer main menu > Tools > Disconnect network drive (7/XP) or the submenu "Disconnect network drive" (10/8.1) while no drive is selected when the click is performed
    and a couple of others.

    All of them result in the problem that the drive letter icon remains in the Explorer although the network drive has been disconnected.

    Some details that indicate that this is a bug and not feature:

    - Although the drive letter icon is shown in the Explorer it's not visible in any other software and not accessible through Windows API
    - The drive letter can be used for a new network drive connection. If done so, the new path is mapped to it, but the old name/path remains in the Explorer.
    - The drive letter can be used to be assigned to a local drive in the Disk Management dialog. For example after changing the drive letter of a DVD drive to the disconnected network drive letter the drive is still shown as a network drive in the Explorer but leads to the content of the DVD drive.

    To solve this problem at this point the user has either to log off and on again or kill explorer.exe and run it again. This shows that it's some kind of orphaned drive in some internal Explorer cache or object list that is not removed correctly.

    There is one way to remove the drive correctly in the first place:
    Right-click on the drive and choose "Disconnect". This works flawlessly! The network drive is disconnected and immediately removed. Notice: this only works if done in the first place. If the drive has already been disconnected using one of the other methods, this option will only show "This network connection does not exist."

    I've discussed this problem with many experts already and there doesn't seem to be a workaround for this. At the moment if you want to programmatically disconnect a persistent network drive that wasn't available during logon you'll end up with an orphaned drive.

    This applies to all Windows versions from XP to 10, x64 and x86. (older versions not tested)

    Is there any chance this could be solved by patching Windows?






    • Edited by [JackJack] Monday, August 24, 2015 11:44 AM
    Sunday, August 23, 2015 10:12 PM

All replies

  • Hi,

    Based on my Windows 10 Enterprise lab machine test, it's the different with your result.

    Step 1: Create mapped drive using the  "Map Network Drive" dialog in the Explorer.

    Step 2: Shut down the target system.

    Step 3: Log off and log on again. The mapped drive is visible in the Explorer with the red cross.

    And then, I click the disconnect network drive below. The mapped drive icon disappear, nothing remained as you said.


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, August 24, 2015 6:51 AM
    Moderator
  • The option you're pointing out does indeed work correctly, but it's basically the same as right-clicking the drive and selectiong "Disconnect", and it doesn't solve the problem that the options I've listed have that problem. Maybe you interpreted this option from my description "Tools > Disconnect network drive", which however is a different one, because the Tools menu is only available in Windows 7, Vista and XP. It openes up a new dialog that allows to select and disconnect a network drive.

    Maybe I should've pointed it out better: My intention is to disconnect the drive programmatically, i.e. from my software. Therefore some interface is required.

    I've mentioned the official APIs that result in that problem. But I also mentioned net.exe which uses the official APIs as well. So without writing any code your easiest way to reproduce it is to open the command line and execure (replace X: by the drive letter you've used):

    net use X: /delete

    Edit: I just noticed, that you can reproduce that problem with the option you've pointed out in Windows 10 as well: Before you click the "Disconnect network drive" menu item make sure that no network drive letter is selected in that view (either deselect or select a local drive). Then use the option you've highlighted in your screenshot. Instead of directly disconnecting a dialog will pop up (the same as in Windows 7). Here you can select the network drive and click OK. This will result in the problematic situation as I've described as well.

    • Edited by [JackJack] Monday, August 24, 2015 11:34 AM
    Monday, August 24, 2015 8:46 AM
  • Karen, have you been able to reproduce the problem with my additional remarks?
    Tuesday, August 25, 2015 9:15 AM
  • Please remember to mark the replies as answers if they help

    I'd love to mark a reply as an answer, but I'm still waiting for a reply for a week now.

    Karen, please confirm that you've been able to reproduce the problem with my additional remarks and advise how to address this bug so it can be solved.

    Monday, August 31, 2015 1:07 PM
  • Karen, have you been able to reproduce the problem with my additional remarks?

    Hi Jack,

    Sorry for my delay.

    There are multiple ways to do this.
    - Probably the easiest way to reproduce it is by command line: net use X: /delete
    - API: WNetCancelConnection2 or WNetDisconnectDialog1
    - Disconnect dialog: Explorer main menu > Tools > Disconnect network drive (7/XP) or the submenu "Disconnect network drive" (10/8.1) while no drive is selected when the click is performed
    and a couple of others.

    All of them result in the problem that the drive letter icon remains in the Explorer although the network drive has been disconnected.

    I cannot reproduce your issue on my Windows 10 lab machine. Let's make clear your issue.

    Which software were you used to disconnect the mapped drive? If you goal is to disconnect the network drive, follow my guide to use the GUI method to click to disconnect the network drive.

    If you cannot, please check if that's drive in this registry entry:

    HKEY_CURRENT_USER\Network

    Here you could see all your mapped drives.

    I suspect if there is some security software prevent you deleting them, disable them to check the result again.

    Meanwhile, locate to this registry entry:

    HKU\youruseraccountSID\Network\networkdrive(such as Z: Y: X etc)

    Delete this key and sign out.

    Please remember to sign out and sign in to apply the changes.


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.


    Wednesday, September 2, 2015 8:49 AM
    Moderator
  • Thank you for getting back to this issue!

    > Let's make clear your issue.
    Well, as I've described my intention is to disconnect the drive programmatically (= from my own software or from a script). Therefore using the mouse to manually click menu items is no solution.

    I'm very surprised to read that you weren't able to reproduce it. You quoted only part of my instructions, but the first 3 steps are very important. Did you follow them carefully? Did you see the balloon message "Could not reconnect all network drives" after logging on? Only then you've set yourself in the position to reproduce the bug. Now use one of the possibilities that I've described to disconnect the drive and end up in that buggy situation.

    I've listed those multiple options to show that I've tried them all. But to make it more clear we can reduce it to one so there's no misunderstanding:

    1. Create a persistent (!) network drive mapping (a.k.a. "Reconnect at logon") using the integrated/official "Map Network Drive" dialog .
    2. Now physically disconnect from the network folder (unplug the cable or shut down the target system)
    3. Log off and on again (or reboot). A balloon message will tell "Could not reconnect all network drives", but the drive will still be visible in the Explorer (with a red cross). The balloon message is the best indication that you've reproduced the steps correctly.
    4. Run cmd.exe and type "net use X: /disconnect" (replace X by the drive letter you've used)
    5. Open Explorer to see that the drive is still there, although it's disconnected now. Now you can verify the erroneous behavior of that orphaned drive that I've described (mount a new network drive to that letter, assign a local drive to that letter, etc.)

    In this case you're disconnecting the drive from a script using net.exe that's integrated in all Windows versions. It uses the official API like I'm using in my software as well. This API does disconnect the network drive. And in most cases the result is as expected. Only in that specific case (where the user logs on without network access to the network path of the mounted network drive) the bug occurs. The API still correctly disconnects the network drive and that drive is removed everywhere EXCEPT in the Explorer. This is also not about the API since the problem can also be reproduced using the "Disconnect network drive" dialog as I've described in my last posting.

    To make it clear: This bug is not a wild assumption of mine. I've reproduced it myself on many systems: XP (x86), 7 (x86, x64), 8.1 (x86, x64), 10 (x64). I've asked several colleagues and friends who all reproduced it on their systems (different devices, different Windows versions). I've also discussed this issue in two forums on the Internet where they were able to reproduce it but didn't find a solution as well.

    Karen, please retry the test but please don't leave out any of the steps.

    Wednesday, September 2, 2015 10:31 PM
  • Restart explorer.exe.

    Thanks for looking into this problem! Yes, restarting explorer.exe removes the orphaned icons in the Explorer as I've described in my initial posting: "To solve this problem at this point the user has either to log off and on again or kill explorer.exe and run it again". The problem with this workaround is that it results in many other problems: all Explorer windows are closed, some tray icons aren't visible anymore, etc.

    This is only a workaround with side-effects for a bug in Windows (basically confirming that it's a bug).

    Thursday, September 3, 2015 3:05 PM
  • This seems specifically an issue with explorer. FSUTIL nor WMIC see the drive letter as being present. I was not able to find the handle to which Explorer is using to display the icon. Neither of these show my test Z: drive as being present after following your steps:

    wmic logicaldisk get caption
    fsutil fsinfo drives

    Take a look at these and see if they are helpful in any way:
    https://chentiangemalc.wordpress.com/2013/02/11/case-of-the-disconnected-drive-that-wouldnt-go-away/

    http://titlerequired.com/2011/08/05/quick-fix-removing-a-disconnected-network-drive/


    • Edited by Tripredacus Friday, September 4, 2015 3:10 PM
    Friday, September 4, 2015 3:10 PM
  • Thanks for your confirmation! I fully agree that it's an Explorer bug.

    I've been working on this issue for about two weeks already. First trying to find out if I'm doing something wrong, then trying to find workarounds. Both of your links describe ways that I've already played around with, but their situations aren't the exactly same as described here.

    To give some more background information regarding this bug: When creating this "orphaned network drive" situation that drive is practicly nowhere to find on the system. All registry paths related to that network drive are removed correctly. No API call can reach this drive. It's fully gone (as expected). Only the Explorer refuses to update it's view. In my understanding there's some internal object list that's simply not updated. And there seems to be no way to externaly get to this list or trigger it to be refreshed. As I've described you can even map a local drive (like DVD drive) to that drive letter without problems and in the Explorer you have then to click on that orphaned network drive icon to get to the DVD content. By restarting explorer.exe all internal lists are of course recreated so the problem disappears.

    What really baffles me is that it works completely fine with the right-click option. Apparently the context menu item "Disconnect" not only calls the official API but also internally removes that object from an internal list. I've assumed that a workaround might be to use the IContextMenu API to get to the context menu and execute that one item programmatically ... but that didn't work either. Is it executed in a different context? I don't know.

    I've even analysed the Explorer with an API Monitor. It also simply uses the normal API calls like WNetDisconnectDialog1, WNetCancelConnection2 and WNetGetConnection. Nothing special.

    After two weeks I came to the conclusion that I won't be able to find a workaround by myself. So my only hope is that Microsoft can either fix that bug for all Windows versions or present some kind of undocumented API call to tell the Explorer to update its drives list.


    • Edited by [JackJack] Friday, September 4, 2015 5:47 PM
    Friday, September 4, 2015 5:46 PM
  • Hi,

    Based on my test, if I use the command below, the icon remained there as you said no matter if you shutdown the target system.  Even if there is no red cross, the connection icon still be there after run this command.

    You must sign out and sign in again to take effect.

    If I use the UI design like my previous, it works immediately.

    And I don't think this is bug. You could add a script to restart the Explorer.exe process.

    If you indeed feel it's a bug, I would like to suggest you submit this feedback via the Feedback App.


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, September 7, 2015 9:08 AM
    Moderator
  • You're saying it's not a bug because the problem goes away by restarting explorer.exe? I'm speechless...
    Solely by suggesting to restart the Explorer you're implicitly confirming that it's a bug.

    Having spent weeks on this problem now I was under the impression that Technet would be the right way to address this problem to the right people at Microsoft.

    Now you're basically giving me two options:

    1. Pretend the problem doesn't exist.
    2. Go search somewhere else for help.

    How is this helpful? I don't know what possibilities "Microsoft Contingent Staff" really have, but I guess you know who to turn to with a bug directly.

    Using the Feedback App is like starting all over again. Also it only exists in Windows 10, while this problem exists in older Windows versions as well.

    Could you please forward this issue to somebody who could take a closer look at it?

    Tuesday, September 8, 2015 11:32 AM
  • Jack, read here to find out what MSFT CSG is:
    https://msdn.microsoft.com/en-us/gg602412.aspx

    Tuesday, September 8, 2015 4:38 PM
  • Thanks, I've already read that part, but in my understanding "contracted or assigned to Microsoft for specific services, deliverables or positions" includes both everything and nothing.

    When I posted this problem here, I wasn't addressing to a specific person, but was hoping the right person would read this and after confirming that this problem exists forward it to a person or department that can take care of it.

    I'm really thankful that Karen and you took the time to reproduce the problem. But if it leads to no solution, but only to the suggestion to ask somewhere else, then it's a big disappointment for me.

    At the beginning after one week without a reply I've contacted tnmff@microsoft.com and got the response: "I have assigned our experienced engineer to handle this case. If there is anything update, we will sync-up in the thread. In addition, if it is regarded as a potential bug, we will report it to fix it as soon as possible."

    So if Karen is that expert, then in my understanding she can "report it to fix it as soon as possible", can't she?


    • Edited by [JackJack] Tuesday, September 8, 2015 7:33 PM
    Tuesday, September 8, 2015 7:31 PM
  • Hi Jack,

    Some more Windows configuration need to sign out and sign in again to take effect. This is a normal behavior.

    GUI and command is two different approaches, so they would need different ways. GUI would directly reset its new icon handle, command cannot.


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Thursday, September 10, 2015 8:34 AM
    Moderator
  • Karen, explaining a bug does not solve it. If it would, no patches would be required ever again. There’s always a reason for a bug.

    Logging off and on again is sometimes indeed required (like switching the domain) for a reason (user token, locked files, etc.). Here there is no reason. It is not a “normal behavior” if you have a broken network drive in the Explorer where (if you use that freed drive letter somewhere else) you can access local drives or wrong network locations through.

    Also I’ve already explained that you can reproduce it by GUI only as well:

    Windows 7, Vista and XP:
    Select the network drive, then use the Explorer main menu > Tools > Disconnect network drive
    A “Disconnect Network Drives” dialog will show up. Select the network drive and click OK.

    Windows 10 and 8(.1):
    Before you click the "Disconnect network drive" menu item make sure that no network drive letter is selected in that view (either deselect or select a local drive). Then use that option from the main menu. Instead of directly disconnecting a dialog will pop up (the same as in Windows 7). Here you can select the network drive and click OK.

    This will result in the problematic situation as I've described as well.
    -> Bug reproduced using GUI only.

    Can you now please report it so it can be fixed!?


    • Edited by [JackJack] Thursday, September 10, 2015 10:49 AM
    Thursday, September 10, 2015 9:25 AM
  • Well, this problem isn't going away all by itself.

    I showed you how to reproduce the bug. I've pointed out that this orphaned drive remains only in the Explorer but nowhere else. I've showed you additionally how to reproduce the bug by GUI only.

    And still your reaction is "Let's pretend it isn't there". I've now waited for 3 weeks waiting for your reaction. Nothing.

    Karen, are you that "experienced engineer" tnmff@microsoft.com promised or not?

    Wednesday, September 30, 2015 6:18 PM
  • As a technical user (of Windows 7) who is experiencing this defect as a result of my normal use of the Disconnect Network Drive GUI functionality rather than an API call, I completely agree with [JackJack]. This is a defect in Windows and needs to be resolved by Microsoft.

    Forcing the user to sign out and back in may be a viable workaround in some situations, such as mine, but it is really not an acceptable solution for a programmatic interface. Clearly this is an implementation issue since this particular problem is exposed when disconnecting network drives using one code path, while using a different code path does not.

    Giving a developer, who is trying to write software for your platform which will attract and retain more users, the runaround is completely unacceptable. Fix your sh!t, Microsoft! Don't give your developers & users one more reason to switch to Linux. I already did so personally long ago (2001), but I'm stuck with Microsoft at work... for now.

    Paul M Edwards
    Sr Software Test Engineer

    Wednesday, October 7, 2015 9:00 PM
  • Hello to everyone on this thread,

    In my condition of simple Windows user, I may absolutely confirm the presence of this bug with all the symptoms described by JackJack and the other users here.

    I have discovered this page by searching an answer to this issue that appears daily on my two computers.

    This is really disappointing to see that 10 months after this thread was created, Microsoft have still not taken in account a such major issue in a basic functionnality of Windows 10 .... :(

    I hope seriously I'll get some good news about it in the following months !

    Saturday, May 14, 2016 5:29 PM
  • Good to hear that other people care about this as well. Actually, I believe many people experience this bug, but most of them don't realize how it occurs and even less people care to report bugs like that.

    I don't think Microsoft cares at all fixing this bug. Their whole point of this conversation here was to explain that there is no bug, then after a lot of convincing simply completely ignoring the whole topic. In reaction, I've sent several emails to the Technet support. First, they promised to assign an “experienced engineer”. Since only Karen Hu replied here, I think sadly she’s the most experienced engineer they have to offer...

    After some more insisting emails this is the last reply I’ve received:

    I checked our bug database and found some similar bugs, but there is not the same one as you submitted. What's more, we have submitted this potential bug with our channel, as you know, it needs time to verify.

    In addition, you can also report this potential bug using the https://support.microsoft.com/en-us channel to submit a case, for example, for Windows 10, the Get help link is https://partner.support.services.microsoft.com/en-us/contact/menu/software/windows/ts/ . What should be remind is you may need to pay firstly, and if the potensial bug is verified to be a real bug, the mony will be returned back. You can get detailed information during the contact.

    Thank you very much for your attention to Microsoft and Windows. Please believe Microsoft is always to reserve a chair for customer.

    Regards, Lany Zhang

    They seriously ask for “mony” to be allowed to send this bug report. Even if they admit this bug at some point and refund, why the heck would I want to pay something to make THEIR product better? This is ridiculous. I’ve invested already a lot of time in this and believe I already did enough to describe and explain this bug.

    Maybe your posting will remind them to have another look at it. But, just to improve chances, I recommend to upvote my first message here to support this bug report and then submit a bug report through the built-in bug report tool in Windows 10. Maybe if enough people do this, they start to care.

    Saturday, May 14, 2016 6:15 PM
  • Maybe its in this thread but I missed it.  JackJack, does your bug occur when you are logged into a domain, a workgroup or both?

    Bill

    Saturday, May 14, 2016 8:02 PM
  • Bill, is there a special reason why you're asking this? I did all the detailed testing in a workgroup, but I believe I had this problem in a domain as well (can't tell for sure though, because this was a long time ago - and since I'm aware of this problem, I'm not using persistent network drives anymore). After all, the bug has already been reproduced and confirmed here in this thread, so I'm not sure why you're asking this detail. Why don't you give it a try in your own constellation?

    Sunday, May 15, 2016 12:15 PM
  • I have noticed some mapping oddities on the Domain at work.  I have not tried to see how they relate to your problem and I don't remember the details. I have not seen similar issues at home on my workgroup but at home I seldom map drives.  No need.

    I don't think, since the but is already confirmed, that I will try to reproduce it.  Knowing its there may keep me from chasing my tail some afternoon, however!

    thanks,

    Bill

    Sunday, May 15, 2016 7:44 PM
  • I've now tested it within a domain and would like to confirm that this bug affects both workgroup and domain sessions in exactly the same way.
    Wednesday, May 18, 2016 5:36 PM
  • I've now tested it within a domain and would like to confirm that this bug affects both workgroup and domain sessions in exactly the same way.

    Yes I can confirm that this is an issue with my Windows 10 on a domain. -  Searched for

    I agree that Microsoft should utilize these freely given bug reports as a valuable contribution to the future development of their products, after all if "Normal Users" like myself can replicate this BUG "Proven" Then we are essentially unpaid development and testing consultants to Microsoft.

    1) The least they could do is to acknowledge this thread correctly, and move the report upwards for "correction"

    2) Then even more importantly is the follow through (integrity) and feed back, that will confirm support for the "Unpaid" Consultants and concerned Users - Confirming that the Expectation that was Created by Microsoft that -""Please believe Microsoft is always to reserve a chair for customer. "" (as posted above) - Is not just a superficial statement, but has substance and commitment to it. If it is superficial ? Then Microsoft would loose the support of these people, and that cannot be a good thing in our modern ERA of Software.

    Friday, August 5, 2016 6:20 AM
  • I can confirm that, to date, this issue remains in Windows 10. I disconnect a mapped drive in explorer and the drive remains. But perform the 'net use' command in cmd.exe and you see the drive is now disconnected. A restart of explorer.exe is required to resolve the issue, indicating a bug in explorer.exe.

    OS Name Microsoft Windows 10 Enterprise
    Version 10.0.10586 Build 10586


    Patrick Burwell, Sr. Systems Engineer
    Axelon, Inc.

    I do not represent any organization I have worked for, all the opinions expressed here are my own. 
    ANY posting is provided "AS IS" with no warranties or guarantees and confers no rights



    Monday, November 28, 2016 5:23 PM
  • This worked for me thank you 
    Tuesday, November 29, 2016 4:08 AM
  • If you cannot, please check if that's drive in this registry entry:

    HKEY_CURRENT_USER\Network

    Here you could see all your mapped drives.

    I am currently having the bug on a windows 10 with my app. After some testing I was able to fix "programatically" this issue in my app by deleting the reg key for the problematic drive under HKEY_CURRENT_USER\Network\z (for the Z: drive)

    (the WNetCancelConnection2 api wasn't able to erase the drive and another use of the letter Z: was impossible)

    I hope this will help some people to bypass this BUG because it is one! I'm 100% with you [JackJack] on this one. 

    Wednesday, July 12, 2017 9:15 PM
  • I'm afraid, but the path isn't listed under HKCU\Network\... anymore after it was removed with WNetCancelConnection2 or WNetDisconnectDialog1 (or manually through the UI as I've described above). It is gone everywhere, except for the Explorer. Your observation might be for a different constellation, but not for the one described above (-> a persistent network drive is unavailable when the user logs on).

    Monday, July 17, 2017 11:35 PM
  • I SOLVED IT BECause I am an old man (wrote my first program for money on an IBM 360) and years ago I used a DOS command assign which was changed when Windows came around to SUBST (itute).  If after you NET USE K: /delete you provide the Command SUBST K: /D your problem will go away at least it did for me on Windows 10 (I suspect this is the solution for previous windows versions (In fact I think I used it with Windows XT because some of my users used substitute to assign a drive letter to a directory (now called folders)  yes Kwai Chang, grasshopper, the old master is still sometimes useful :-)
    Tuesday, August 29, 2017 8:28 PM
  • BTW  you can issue the SUBST command on the drive anytime they do not have to be issued in sequence so if you have some orphan drives out there you can get rid of them

    happy computing

    Charlie

    Tuesday, August 29, 2017 8:48 PM
  • I tried your suggestion out on Windows 7 and 10. Unfortunately, it does not work.

    > net use Z: /delete
    > Z: was deleted successfully.
    > subst Z: /D
    > Invalid parameter - Z:

    subst only works with virtual drives. A mapped network drive is not a virtual drive in that definition. subst doesn't work for any kind of network drives (neither broken nor properly mapped). I don't know how you could experience it differently. Sorry.

    Tuesday, August 29, 2017 9:07 PM
  • How I came across using the subst command is after I issued the net use delete and tried to remap the drive using net use the error I got was "local drive in use" 

    I wonder what you get if you delete using net use and then use net use to map the drive to someplace else?  I am gonna try this again.

    Alright I tried it again... I mapped the drive using Explorer.  I went to the command prompt and got your results.  However, I then rebooted.  The drive was now listed in Explorer with a red X.  I then went to the command prompt and issued the subst and the command completed successfully.  So it appears a batch procedure to create a new "share" might look something like this:

    net use Z: /delete         -->an error will be generated if Z is not mapped but the batch procedure will

                                              continue to run

    subst Z: /D                   -->an error will be generated if there is nothing to delete and the procedure will

                                              continue to run...but if there is an assignment the assignment will be deleted

    net use Z: \\........         -->now you can use Z: again

    Does this help?  I am gonna mess around with this a little more

    Wednesday, August 30, 2017 6:14 PM
  • As I've described in a previous post: You can do whatever you want with a drive letter that is broken in the described way. You can even go to the hard drives management and map a partition to the drive letter, because the drive is available. It's just that the File Explorer doesn't realize that. In that case the result would be that you see the broken drive in the Explorer and when you bouble click it you'll see the content of the mapped partition.
    Thursday, September 7, 2017 7:43 PM
  • I am so sorry, I forgot one "little" thing.  Once you cannot do anything and you have that disconnected drive line that won't go away in the explorer window, RENAME IT, I renamed it to zzzzzzzz then believe it or not you can use the SUBST command to delete it.  I have not tried to write a batch procedure to do this but I guarantee if you rename it (to anything) then go to the command window and SUBST the drive letter /D it will go away.  No registry fixes etc.  I have run this test many times sometimes I had to reboot other times I simply had to close explorer and reopen it.

    Any questions please ask.

    Charlie

    Saturday, September 16, 2017 1:26 AM
  • "subst /d Z:" doesn't work for mapped network drives at all. Neither for functional, nor for broken or renamed network drives. I always get "Invalid paramter - Z:" as a reply and the network drive is still there. If you experience it differently, please create a video of your process with the result.
    Saturday, September 16, 2017 10:39 AM
  • JackJack,

    I'm on to something with "mountvol Z: /D" in combination with "net use Z: /D /y"
    Further testing needed...

    ... needs and elevated command prompt ... that is a problem for me.


    • Edited by cozie_nest Monday, September 18, 2017 4:22 PM
    Monday, September 18, 2017 4:16 PM
  • I have exactly the same issues as JackJack. The password that I used to map network drive can only last for hours so I have to map it everyday. I haven't restart/logout/login for a couple of days so I have 3 mapped drives (F:, I:, J:) pointing to the same location. Right click and choose "Disconnected" each time and the drives are still shown in explorer but are not accessible anymore.  

    Using "mountvol F: /D" and "mountvol J: /D" with admin rights does make F: drive and J: drive go away immediately in explorer. But "mountvol I: /D" doesn't work. Error shows "The system cannot find the file specified". I: drive still appears in explorer with red X but not accessible. So it works somehow but not always for some reason. BTW this is domain situation, not workgroup.

    Wednesday, September 27, 2017 1:32 AM
  • Thank you for your patience and thoughtful responses to MS, JackJack.  Many, including myself, have little patience for the off-putting attitudes and responses from this company.  I only wish to add my name to the (growing) list of users and developers that are experiencing this clear **BUG** issue in the hopes it will attract the attention of someone at MS.
    Friday, December 8, 2017 7:35 PM
  • Exactly the same issue for me on a Win10 machine. It appears to be a bug and a bit of help from MS would be greatly appreciated.
    Wednesday, January 10, 2018 8:32 AM
  • Hi!

    Got the same issue here.

    The only real solution for me (don't even want to talk about such ridiculous "solutions" as killing/restarting explorer.exe, logoff/logon, restart etc) was using "mountvol F: /D" even without admin rights.

    Verified on W7, W2K8R2. Seems to work fine so far.

    So basically I came down to the following solution:

    if WNetCancelConnection2() returns ERROR_NOT_CONNECTION for dangling mount , I issue "mountvol" cmd.

    If it fails to purge this mount too I'll show error(warning) message which contains the URL pointing to this thread with many thanks to Microsoft for such a beautiful tech support and fast problem solving.

    JackJack, thank you, mate,  for bringing up this topic and your patience.

    cozie_nest, Grajon, thank you for proposed solution with mountvol cmd.

    Monday, January 15, 2018 9:23 AM
  • Hi All,

    Thanks to alexz2600 and others.

    The fix for this seems to be the following combination from an Administrative Command Prompt.

    net use x: /delete

    mountvol x: /D

    This seems to resolve the issue. It also solves the problem you may get when running PowerShell commands remotely where you receive the message:

    "Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed."

    When using an Invoke-Command -Computername script block.

    I am hoping this helps anyone who has a problem with this and your favourite search engine finds you here!

    This has been tested on Windows Server 2012 R2, Windows 7 and Windows 10.


    Thursday, May 10, 2018 3:59 PM
  • Hi!

    Got the same issue here.

    The only real solution for me (don't even want to talk about such ridiculous "solutions" as killing/restarting explorer.exe, logoff/logon, restart etc) was using "mountvol F: /D" even without admin rights.

    Verified on W7, W2K8R2. Seems to work fine so far.

    So basically I came down to the following solution:

    if WNetCancelConnection2() returns ERROR_NOT_CONNECTION for dangling mount , I issue "mountvol" cmd.

    If it fails to purge this mount too I'll show error(warning) message which contains the URL pointing to this thread with many thanks to Microsoft for such a beautiful tech support and fast problem solving.

    JackJack, thank you, mate,  for bringing up this topic and your patience.

    cozie_nest, Grajon, thank you for proposed solution with mountvol cmd.

    A question but did these network drives originally get generated by a GPO? As it may not have been removed when the GPO was no longer applied.
    Thursday, May 10, 2018 4:01 PM
  • I have the same issue but in my case i mapped a drive with net use y: \\192.168.1.112.  that IP address changed and I mapped a new one but can't get rid of Y: in File Explorer - has a red x and i get the balloon about not connecting to network drives noted inthe original problem statement. I have tried net use y: /delete and mountvol y: /D - net use yields the error "then network connection could not be found" and mountvol "the system cannot find the file specified.  so None of the above solutions work for me. How can I get rid of this drive?
    Sunday, May 27, 2018 2:56 AM
  • So here we are literally years later on this thread and still no solution.... It make one speculate what in hell do the product managers at MS do to earn their very large salaries....but I guess there is no glory in fixing a bug or for that matter any bugs....
    Friday, November 16, 2018 8:51 PM
  • This worked for me in Win10 (also virtual drives):

    net use e: /delete
    
    taskkill /f /IM explorer.exe
    
    explorer.exe

    Good luck.

    ps. My best experience after Win7 was migrating to Linux, never thought an OS could be so complete and powerful (running Win10 as a virtual machine on top)

    Tuesday, November 27, 2018 9:43 AM
  • I too have this symptom/issue repeatedly on Windows 10. EXPLORER shows a drive mapping, which is not connected, and it will not remove it from Explorer.=--so you can't remap it.

    My Windows 7 does not.  With Win 7 the mapped drives are restored when the network storage returns. 

    Now I've run into this zombie drive in Explorer from MULTIPLE CAUSES.

    When ... Windows 10 says the network name does not exist. Once in this state, not only can I NOT disconnect the drive--in that it continues to exist in Explorer, but I've also been unable to create any connections to that host. All the other hosts on my network are happy, only Win10 breaks.  Win7, Linux, Mac OS, the SANs--everyone is fine.  I have had to bring the entire network down with Win10 to get past this recently.  So here the problem is caused by what I can only guess is some SMB problem with the master--which is probably Win 7 when win10 shuts down. And yet, nothing else is broken. 

    Today ... Win 10 boots without the drive available, it shows disconnected. (This is a workgroup). Win 7 also booted with this issue.  I click on the drives and they refresh and pop up as working.  I attempt the same on Windows 10 and it says it cannot be found.  It will not Disconnect, and <g class="gr_ gr_2429 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar multiReplace" data-gr-id="2429" id="2429">I'm left</g> with a zombie drive again. Unlike the problem <g class="gr_ gr_2501 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling multiReplace" data-gr-id="2501" id="2501">i've</g> had before, I could connect another drive letter to the SAN.  So I knew that despite triggering the same bug where Explorer hangs onto this zombie drive, the conditions were slightly different.

    RESTARTing Explorer.exe did get rid of the zombie mapped <g class="gr_ gr_6119 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins doubleReplace replaceWithoutSep" data-gr-id="6119" id="6119">drive</g>. 

    I figured out that Win10 bumped my Bluray (normally R:) to F: (I don't know <g class="gr_ gr_6174 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation only-del replaceWithoutSep" data-gr-id="6174" id="6174">why,</g> it has been there for months) which was the mapped network drive.  (facepalm)  Has Windows still not grow enough intelligence in assigning drive letters to stop mapping USB drives on top of mapped drive letters?  Or has this behavior been re-introduced by the Win7 rewrite/Win 8 metros or newly broken in Win10 (like the fact that basics like SHOW WINDOW SIDE BY SIDE doesn't work anymore or that MS TASK MANAGER is now an App that MS Windows just can't figure out how to close when shutting down.)  Once I freed the drive letter I could remap.

    Thursday, January 24, 2019 1:54 AM
  • Thanks for point out this bug.   I do hope MS issue a fix soon.  This problem is so obvious and easy to duplicate.  There is no excuses not to fix it.
    Thursday, February 7, 2019 6:00 PM
  • So I have had a similar problem on all my workstations. i.e. Mapped drives with a red X indicating that they are no longer connected; however the drive mapping are still present when clicked on AND you  are unable to remove the drive maps.

    1. I tried using the net use command prompts...but as stated this results in an error saying there are no mapped drives.

    2. net use : shows no mapped drives

    3. Searching and deletiang every registrty reference to the drive maps in the mapoints2 and network registry entries

    4. Restarting explorer

    Bottom line: nothing worked EXCEPT for creating a GPO on the server  that 'created' new drive map entries.

    This worked perfectly and removed all the phantom drive maps !!


    jawsurgeon

    Wednesday, February 20, 2019 7:14 PM