How to stop Windows Explorer closing for removable Disks!

Page 3 of 3 FirstFirst 123

  1. Posts : 3
    Windows 7 64Bit
       #21

    Oh, and before replying, I have no desire to get into a contest with any of you. If you can not lend useful input to this issue, being dignified and respectful while you do so, then please move along...
    Last edited by TypeR; 19 Mar 2012 at 11:22.
      My Computer


  2. Posts : 1,814
    XP / Win7 x64 Pro
       #22

    lexluthermieste said:
    @FliGi7 and unifex;

    Again senior members or not; it is very clear from reading your posts that, in fact, YOU two don't seem to understand the problem either nor have offered any real help. IJustWantItToGo was entirely correct about this problem being related to the "autorun" features of windows vista/7 as much[if not all] of that code originates from explorer.exe. Calls/queries the os makes to drive/folder states are always compared against the autorun routines. Since MS removed the checks that determine the owner/originator of the instance of explorer in question, windows acts according to it's coded and non-configurable[I would LOVE to be wrong about that if someone wants to rise to the challenge] default; if device/folder = not present, close explorer instance. And had you known this information, you could have saved yourselves some embarrassment.
    Again, the closing of window doesn't have to do with Autoplay. Autoplay has to do with insertion of a device, not removal of a device. Have you ever seen Autoplay come up when you remove a device? No, because it wouldn't make sense to run Autoplay rules/options upon removal of a device. The reason the window closes is due to explorer's rules, not Autoplay's rules, just as you said, " if device/folder = not present, close explorer instance.". This is the reason the window will still close if you're in the removable drive's folder when you remove it even if Autoplay is turned off. So, I'm not really sure what fallacies you think were stated or embarrassment you're referring to here. You're certainly entitled to your opinion, but you should really make sure you know what you're talking about before you accuse others of doing the same.

    Hopefully if you read back through the thread you will see that the animosity didn't only stem from all "senior members" you keep referring to. It's been very much a two way street. Certainly it could have been handled differently but we're all human and it's easy to get roped into arguments online.

    Regardless of this thread, I hope you continue to participate on the forum, despite your initial impressions. It does have a lot to offer and no forum is free of diverging threads like this. I think this one's run its course as there's obviously no fix and this is just an inherent feature of Windows explorer. Perhaps someone can come up with a tweak in the future to prevent it.
      My Computer


  3. Posts : 3
    Windows 7 64Bit
       #23

    @FliGi7

    All autoplay functions run through two main system processes. The plug&play service[which runs by way of DCOM via svchost.exe] and explorer.exe. Each time the os detects a change in hardware status, it calls the autoplay functions from explorer.exe, obeys user settings[if applicable], and carries out it's instructions[such as to mount the volume]. It has been this way since XP. In the case of a drive being removed from vista/7, calls are made to explorer to query the type of drive/volume being removed and in the case of removable drives or optical discs, shuts down that instance of explorer. This is it's default non-configurable function. All of these routines are a part of the autoplay portion of explorer.exe and svchost.exe's code. But unlike XP, svchost now closes the window instead of shifting to the next item down the list. This is our complaint.

    Does that now make sense? ALL plug & play related events make calls to autoplay even if the event turns out to be a non-mountable device[such as a mouse being plugged in]. ALL of them! This is why the os opens an instance of explorer when a new volume is mounted[the user has set things thus] or closes an instance of explorer if the volume mounted is removable and ceases to be present in the hardware table. It's a little more complicated than that and involves a few more system processes, but you should get the basic idea.

    As for the poor behavior, the way it comes off is that he was being attacked first and became frustrated[understandably]. Had I been attacked in such a way, my reactions would have been different but would have likewise been strongly worded.

    Has anyone thought of finding the calls in explorer.exe and modding them? Explorer has been modded to kingdom come so I figure there's got to be a way. I'd do it myself and share the work if my understanding of coding and whatnot was better...
      My Computer


  4. Posts : 1,814
    XP / Win7 x64 Pro
       #24

    lexluthermieste said:
    @FliGi7

    This is why the os opens an instance of explorer when a new volume is mounted[the user has set things thus] or closes an instance of explorer if the volume mounted is removable and ceases to be present in the hardware table.
    With Autoplay disabled, an instance of explorer does not open when a volume is mounted but it will still close the explorer instance when it is removed. Thus, the explorer window behavior is completely separate of Autoplay. Per my original statement, "Autorun has nothing to do with closing an explorer window when the drive is removed.", regardless of what calls are or aren't made to/from/by Autoplay and what other system processes may be involved. Autoplay has been erroneously related to the closing of the explorer window (stating that they would expect the window to stay open if Autoplay wasn't involved), thus my posts informing otherwise. It may be related somehow system call-wise or something equally obscure but for all intents and purposes of fixing the window-closing problem, it has nothing to do with it.

    I do agree with you that this might be fixable based on tracking down and intercepting/changing whatever calls are made to perform the checks and close the window. That seems like the only way to address this.
      My Computer


  5. Posts : 2
    Windows 7 Pro x64
       #25

    With apologies for resurrecting an old thread...

    This behaviour is a problem for me too. I am posting now to add that it also happens whenever you format a drive, i.e. if that drive currently has the focus in Windows Explorer and you format it using right click > format (in the left hand "drive tree" pane) then the Windows Explorer instance closes as soon as the format commences, leaving you with just the "format" dialog.

    I don't understand why some people are having difficulty recognising this as a usability issue, when it is clear that such behaviour is not desirable.
    Last edited by blackworx; 29 Mar 2013 at 11:31.
      My Computer


  6. Posts : 1
    windows 7
       #26

    Click on the C: drive before removing the USB
      My Computer


  7. Posts : 2
    Windows 7 Pro x64
       #27

    mickeyme, that is what's known as a workaround. It doesn't change the fact of Explorer's undesirable behaviour.
      My Computer


  8. Posts : 3
    Windows 7 Pro 64 bit
       #28

    Anybody found the answer for this annoyance? A plug-in for windows explorer maybe?
      My Computer


  9. Posts : 469
    Win 7 home premium 32 bit
       #29

    try WDE window double explorer its free

    Windows Double Explorer - Home

    it will not close the explorer when u eject removable media

    plus it has 2 tabs open at any one time so you can easily copy & paste from one folder to another

    you also can open more than 2 tabs for example 5 or 6 or as much you like

    however only two tabs will be displayed at anytime

    you can drag your favorite folder to top if you like that for easily viewing your favorite folder
      My Computer


 
Page 3 of 3 FirstFirst 123

  Related Discussions
Our Sites
Site Links
About Us
Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 21:36.
Find Us