Explorer.exe leaking handle on deleted folder. Prevents folder being re-created. RRS feed

  • Question

  • I've been suffering from an intermittent problem with folders that get deleted as part of a nightly scheduled task but aren't being completely deleted, causing subsequent "mkdir" or "xcopy" commands to fail because the folder is still locked.

    I have a folder that has many sub-folders. Each night a scheduled task may decide that one or two folders need to be deleted and recreated by copying them from a master location on the same machine. The scheduled task is running a simple .bat script that contains just a series of "rmdir /s /q" followed by either a xcopy or a mkdir and copy. The scheduled task runs as myself and I have admin privileges. The folder lives in a normal location on the C drive that belongs to me, i.e. not a special system folder.

    The bat script fails in the mkdir or xcopy commands, i.e. when trying to recreate the folder that rmdir has just deleted. When it fails the .bat script just outputs lots of "Access denied" messages.

    I have several explorer windows open but none looking at the location of the folder being accessed. When I hit this failure I can navigate explorer to the folder and i still see the "deleted" folder listed. Pressing F5 to refresh the view still shows it. In a new CMD window a DIR also shows it, but trying to cd in to it fails with access denied.

    Now here's the strange bit. In the explorer window showing the deleted folder I select the folder and hit the Delete key. I get the usual "Are you sure dialog?", say Yes, then get an error dialog that says something like "Could not find this item - This is no longer located in..." At this dialog I hit Cancel and see that the folder is still shown in the explorer view. NOW if I hit F5 to refresh the explorer view the folder disappears and the problem too, i.e. I can now mkdir the same folder and it works.

    When I've hit this problem I've used Process Explorer (PE) to hunt to open handles on the deleted folder, and find that only explorer.exe has 2 open handles. If if forcibly close these via PE then folder goes away and can be recreated again, no real surprise there.

    So something in/under explorer.exe is opening handles to the deleted folder but not closing them. I've been trying to track this down using Process Monitor (PM) on explorer.exe. I've watched the PM log during the sequence where I select the deleted folder, delete it again, cancel the error dialog and then F5. What this shows is a lot of these:

    Explorer.EXE CreateFile C:\mainland\d4\dv\dev\tcl DELETE PENDING Desired Access: Read Attributes, Read Control, Disnbsp;

    Further down the PM log, i'm guessing corresponding to when I hit the Delete key and get the error dialog, I then see a flurry of pairs of CloseFile calls, one pair for each sub-folder in the folder, including one pair for the deleted folder. After this CloseFile call the deleted folder can now be recreated, again not surprise.

    I know that lots of 3rd party stuff can hook itself in to explorer.exe so maybe one of these managed to open the handle and failed to close it. However looking at the call stack for the CloseFile call that closed the deleted folder handles (see below) I don't see any 3rd party dlls involved, it all looks like internal Windows dlls being called.

    This is an intermittent problem. Most nights the folders gets deleted and recreated with no problems so it sounds like some timing issue where something (another thread in explorer.exe?) is occasionally getting the chance to open a handle on a folder that is in the process of being deleted.

    Apologies for the length of the question but I've been battling this annoying issue for months and have explored lots of avenues but have now come to the conclusion that it could be something inside explorer.exe itself.

    Thanks for any help with this.

    (below is the call stack from PM on the CloseFile that finally closes the handle on the deleted folder, i suspect as part of the failed delete action I do from within explorer itself.)

    0 fltmgr.sys FltpPerformPreCallbacks + 0x2f7 0xfffff88001446067 C:\Windows\system32\drivers\fltmgr.sys
    1 fltmgr.sys FltpPassThrough + 0x2d9 0xfffff88001447329 C:\Windows\system32\drivers\fltmgr.sys
    2 fltmgr.sys FltpDispatch + 0xb7 0xfffff880014456c7 C:\Windows\system32\drivers\fltmgr.sys
    3 ntoskrnl.exe IopCloseFile + 0x11f 0xfffff800033df69f C:\Windows\system32\ntoskrnl.exe
    4 ntoskrnl.exe ObpDecrementHandleCount + 0xb4 0xfffff800033cedc4 C:\Windows\system32\ntoskrnl.exe
    5 ntoskrnl.exe ObpCloseHandleTableEntry + 0xb1 0xfffff800033ceb81 C:\Windows\system32\ntoskrnl.exe
    6 ntoskrnl.exe ObpCloseHandle + 0x94 0xfffff800033cf144 C:\Windows\system32\ntoskrnl.exe
    7 ntoskrnl.exe KiSystemServiceCopyEnd + 0x13 0xfffff800030db453 C:\Windows\system32\ntoskrnl.exe
    8 ntdll.dll NtClose + 0xa 0x770d140a C:\Windows\SYSTEM32\ntdll.dll
    9 KERNELBASE.dll CloseHandle + 0x13 0x7fefd7a1863 C:\Windows\system32\KERNELBASE.dll
    10 kernel32.dll CloseHandleImplementation + 0x3d 0x76cd2f61 C:\Windows\system32\kernel32.dll
    11 SHELL32.dll CLocalInterruptSource::v_CloseHandle + 0xa0 0x7fefdc440b4 C:\Windows\system32\SHELL32.dll
    12 SHELL32.dll CFSInterruptSource::Suspend + 0x2e 0x7fefdd6786c C:\Windows\system32\SHELL32.dll
    13 SHELL32.dll CChangeNotify::SuspendResume + 0x68 0x7fefdc0c276 C:\Windows\system32\SHELL32.dll
    14 SHELL32.dll CChangeNotify::_OnSuspendResume + 0xa5 0x7fefdc0c485 C:\Windows\system32\SHELL32.dll
    15 SHELL32.dll CChangeNotify::s_WndProc + 0x1b7 0x7fefdc0bc60 C:\Windows\system32\SHELL32.dll
    16 USER32.dll UserCallWinProcCheckWow + 0x1ad 0x76bc9bd1 C:\Windows\system32\USER32.dll
    17 USER32.dll DispatchClientMessage + 0xc3 0x76bc72cb C:\Windows\system32\USER32.dll
    18 USER32.dll _fnDWORD + 0x2d 0x76bc6829 C:\Windows\system32\USER32.dll
    19 ntdll.dll KiUserCallbackDispatcherContinue 0x770d1225 C:\Windows\SYSTEM32\ntdll.dll
    20 ntoskrnl.exe KeUserModeCallback + 0xe6 0xfffff800033c3772 C:\Windows\system32\ntoskrnl.exe
    21 win32k.sys SfnDWORD + 0x10e 0xfffff9600014f576 C:\Windows\System32\win32k.sys
    22 win32k.sys xxxSendMessageToClient + 0x113 0xfffff9600014c227 C:\Windows\System32\win32k.sys
    23 win32k.sys xxxReceiveMessage + 0x61f 0xfffff96000102acb C:\Windows\System32\win32k.sys
    24 win32k.sys xxxRealInternalGetMessage + 0x339 0xfffff9600014ac3d C:\Windows\System32\win32k.sys
    25 win32k.sys xxxInternalGetMessage + 0x35 0xfffff9600014b1e5 C:\Windows\System32\win32k.sys
    26 win32k.sys NtUserPeekMessage + 0x77 0xfffff96000143bef C:\Windows\System32\win32k.sys
    27 ntoskrnl.exe KiSystemServiceCopyEnd + 0x13 0xfffff800030db453 C:\Windows\system32\ntoskrnl.exe
    28 USER32.dll ZwUserPeekMessage + 0xa 0x76bc908a C:\Windows\system32\USER32.dll
    29 USER32.dll PeekMessage + 0x92 0x76bc50fe C:\Windows\system32\USER32.dll
    30 USER32.dll PeekMessageA + 0x13f 0x76bc3a6f C:\Windows\system32\USER32.dll
    31 SHLWAPI.dll SHWaitForSendMessageThread + 0x63 0x7feff233e03 C:\Windows\system32\SHLWAPI.dll
    32 SHELL32.dll CShellTaskScheduler::_MT_WaitOnRunningTasks + 0xf4 0x7fefdeccf30 C:\Windows\system32\SHELL32.dll
    33 SHELL32.dll CShellTaskScheduler::RemoveTasks + 0xac 0x7fefdd9138b C:\Windows\system32\SHELL32.dll
    34 SHELL32.dll CMsgWaitForManyObjects::Wait + 0x13a 0x7fefddc3354 C:\Windows\system32\SHELL32.dll
    35 SHELL32.dll CChangeNotify::_MessagePump + 0xb0 0x7fefdc482b2 C:\Windows\system32\SHELL32.dll
    36 SHELL32.dll CChangeNotify::s_ThreadProc + 0xc7 0x7fefdbb307f C:\Windows\system32\SHELL32.dll
    37 SHLWAPI.dll WrapperThreadProc + 0x19b 0x7feff23c71e C:\Windows\system32\SHLWAPI.dll
    38 kernel32.dll BaseThreadInitThunk + 0xd 0x76cc652d C:\Windows\system32\kernel32.dll
    39 ntdll.dll RtlUserThreadStart + 0x1d 0x770ac521 C:\Windows\SYSTEM32\ntdll.dll

    • Edited by mrg67 Thursday, May 17, 2012 8:28 AM
    Thursday, May 17, 2012 8:18 AM

All replies

  • Do you by any chance use the Navigation pane in Explorer to access these folders? I have an open thread discussing a problem with explorer.exe not releasing file handles to folders that I have visited through the navigation pane. The thread is located here: http://social.technet.microsoft.com/Forums/en-AU/w7itproui/thread/f0a3f758-f74b-49b6-9c8d-28ed57ea2dd6
    Friday, May 18, 2012 10:11 AM
  • Yes, I use the navigation pane on all my Explorer windows. Typically have 5-10 explorer windows open at a time. I have suspected that visiting the folder to be deleted "some time" during the day may be related to why its still locked during the overnight task. When I finish work at end of day I typically make sure no explorer window is left looking directly at the folders to be deleted. However, the navigation panes in the windows MAY still have a folder tree that is left open down as far as the folders to be deleted. I hadn't realised that explorer could still be showing the troublesome folders in the navigation pane. Good clue, thanks! I'll also try to close up the navigation panes at end of day too and see if that has any effect.

    Bottom line is that it still looks like an explorer.exe bug.

    Friday, May 18, 2012 11:05 AM
  • During my testing I've seen that visiting a folder ONCE via the Navigation pane is enough for Explorer to leave the handle open. Navigating away from the folder is not enough, you have to close the Explorer window for the handles to be released. This is checked easy with the handle.exe utility from Sysinternals.

    Just out of curiosity: Do you get any error message when you do "rmdir /q /s" in your bat script? I bet you get "The Directory is not empty" with the result that only the child folder is deleted.

    Would be nice to see if this behavior can be looked at from MS staff.

    Friday, May 18, 2012 11:28 AM
  • Hi,

    To isolate the 3rd party problem, we can check if the issue persists after performing a clean boot.

    How to perform a clean boot

    1) Log on to the computer by using an account that has administrator rights.

    2) Run "msconfig.exe" in the Start Search box, and then press ENTER to start the System Configuration Utility.

    3) On the General tab, click Selective Startup, and then click to clear the Load startup items check box. (The Use Original Boot.ini check box is unavailable.)

    4) On the Services tab, click to select the Hide all Microsoft services check box, and then click Disable all.

    5) Click OK, and then click Restart.

    Best Regards,

    Ruby Cheng

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Saturday, May 19, 2012 8:51 AM
  • I've manually played with doing the "rmdir /q /s" in a DOS terminal and you are correct, with an explorer navigation window viewing the folder, or having viewed it in the past, then rmdir deletes all the files and sub-folders in the folder BUT it fails to delete the actual folder itself and I get "The directory is not empty." . This is contrary to what rmdir says about the /S option:

        /S     Removes all directories and files in the specified directory
                in addition to the directory itself.  Used to remove a directory

    What's also curious is that if I quickly repeat the same rmdir command straight after this "directory not empty" message then it DOES delete the folder!?! Here's the proof:

    rmdir /s /q m:\d4\dv\dev\px
    The directory is not empty.

    dir  m:\d4\dv\dev\px
     Volume in drive M is OS
     Volume Serial Number is 6675-D15F

     Directory of m:\d4\dv\dev\px

    19-May-2012  11:32    <DIR>          .
    19-May-2012  11:32    <DIR>          ..
                   0 File(s)              0 bytes
                   2 Dir(s)  271,206,494,208 bytes free

    rmdir /s /q m:\d4\dv\dev\px

    dir  m:\d4\dv\dev\px
     Volume in drive M is OS
     Volume Serial Number is 6675-D15F

     Directory of m:\d4\dv\dev

    File Not Found

    rmdir /s /q m:\d4\dv\dev\px
    The system cannot find the file specified.

    In the above the m:\ is a local folder on my c:\ drive that I've mapped to a local drive using SUBST, but I've seen this problem with deleting folders directly on the c:\ drive too.

    I've repeated the above under a newly made folder where an explorer window has never been and the first rmdir deletes everything. I get no "directory not empty" message. However if I start a new Explorer window and navigate to this new location and browse in to the folders and then repeat the above test it also works as expected. To me this looks like maybe some search indexing thing needs time to spot the new location and then after that it will start to cause the rmdir to fail. Just a hunch. Repeating the test with a new sub-folder that I create alongside the original one, i.e. they are in the same parent folder DOES fail in the same way. Still looks like something in Explorer is not right.

    I have the feeling that my nightly scheduled task gets in to the locked DELETE_PENDING failure mode because its rmdir and xcopy/mkdir are done very quickly after each other, and this failure of rmdir to fully delete the folder on first call (but deletes OK on a second call) says there is a window where the "deleted" folder is in some sort of zombie state and that if something opens a handle on it at this point then it fails to close it, causing the lock-out.

    At least this has given me a something new to try in my nightly .bat scripts: do every rmdir twice! I'll see if that helps or not.

    I'll also try the clean boot scenario and see if the "directory not empty" failure happens here too.

    One more thing I've just remembered. When I started working on Windows 7 I wanted the old navigation pane behaviour so under the Folder Options settings in the Navigation pane section I have switched on "Show all folders" and "Automatically expand to current folder". Might be relevant now it looks like the problem is related to the navigation pane.

    • Edited by mrg67 Saturday, May 19, 2012 10:43 AM
    Saturday, May 19, 2012 10:39 AM
  • Hi,

    I understand that you'll try clean boot to check the result. If the issue didn't occur when performing a clean boot, then we can easily find the third party culprit by continue using clean boot as below:

    a.  Click Start, type "MSCONFIG" (without the quotations) in the Search Bar and Press "Enter" to start the System Configuration Utility.

    b.  Click the "Services" tab, check the "Hide All Microsoft Services" box and click "Disable All" (if it is not gray).

    c.  Click the "Startup" tab, click "Disable All" and click "OK".

    d.  Restart the computer and check the issue still persists.

    e.  If the errors did not come back. Then re-enabled 1/2 of them. If the problem still did not come back, continue in this fashion until we may found a culprit.

    Best Regards,

    Ruby Cheng

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, May 22, 2012 11:29 AM
  • I've spent a couple of hours with my machine rebooted in a "clean" config now and have managed to reproduce the rmdir problem but not my initial problem of handles to deleted folders being held by explorer.exe.

    The rmdir problem reproduces very easily. Opened an explorer window, navigated down to some sub-folder such that the navigation pane showed the folder tree. then in a new DOS terminal tried to delete a parent folder withrmdir /s /q. Hit the same problem as before in that the rmdir reports "The directory is not empty" and DOESN'T delete it (as it clearly should), but repeating the rmdir command again DOES delete the folder. This seems like a pretty clear bug in explorer.exe to me.

    I'm not surprised I was not able to reproduce my initial problem with handles held on deleted folders. As I said its an intermittent problem and I can go days or sometimes weeks with never hitting it.

    What still seems strange to me is that the CloseHandle call that I trigger by using an explorer window to "delete" the deleted folder again, happens in a call stack (see above) that shows no third party dlls at all. So doesn't this rule out the problem being a third party thing?

    Looking at the stack again I see the top of it contains calls that look like they are clearing up stuff from the task scheduler? As I'm running my night jobs as a scheduled task that makes sense, except why is the clean-up only being done as a side-effect of trying to delete the deleted folder again? Again looks like something internal to explorer or the task scheduler.

    Monday, May 28, 2012 9:49 AM
  • This is reproducible on a fresh VM downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=11575 so we can safely say that this is not caused by any 3rd party applications.

    My thread regarding the same issue is located here: http://social.technet.microsoft.com/Forums/en-AU/w7itproui/thread/f0a3f758-f74b-49b6-9c8d-28ed57ea2dd6. A video describing the exact steps to reproduce can be seen here: http://www.youtube.com/watch?v=o5OXjk9unkY

    Tuesday, May 29, 2012 10:01 AM
  • Hi,

    I understand that the issue occurs randomly. So we cannot be sure if the issue are not occurs when performing the clean boot. If you suspect a Explorer.exe problem, please ensure you have a latest version Explorer.exe.

    Here I would like to provide an KB which fix known issue on Explorer.exe:

    Applications may crash in Windows 7 or in Windows Server 2008 R2


    Best regards,
    Ruby Cheng

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Proposed as answer by Kim Zhou Wednesday, June 6, 2012 2:26 AM
    • Marked as answer by Cloud_TS Wednesday, June 6, 2012 2:28 AM
    • Unmarked as answer by mrg67 Wednesday, June 6, 2012 7:58 AM
    • Unproposed as answer by mrg67 Wednesday, June 6, 2012 7:59 AM
    Saturday, June 2, 2012 8:08 AM
  • That's a bit hasty to assume this vaguely related hotfix has solved my problem! I only installed it 2 days ago so hardly had any time to verify its cured the problem.

    I'll update this case after I'm convinced I no longer see the locked deleted folder problem...

    As for the other issue (from Olle Lindburg) where rmdir needs to be executed twice to delete a folder displayed in the navigation pane, are you also saying this hotfix will cure that problem too?

    Wednesday, June 6, 2012 8:02 AM
  • I tried the hotfix, the problem still occurs.
    Monday, October 15, 2012 1:15 PM
  • Use http://explorerplusplus.com/

    forget about Windows Craplorer.

    Wednesday, October 2, 2013 8:15 AM