SHFileOperation: randomly raises exceptions when deleting files

Question

I am using SHFileOperation() to delete directories from a specific path. It is done in multiple threads and the directory that's deleted is always different.

From time to time, it throws exceptions:

Exception thrown at 0x00007FF8AF5D9D2A (ntdll.dll) in del.exe: 0xC0000008: An invalid handle was specified

and this one:

Exception thrown at 0x00007FF8ACC90A36 (shell32.dll) in del.exe: 0xC0000005: Access violation reading location 0x0000000000000001.

modules:

shell32.dll 00007FF8ACBD0000-00007FF8AE0D8000 
ntdll.dll   00007FF8AF530000-00007FF8AF701000

This is the code:

SHFILEOPSTRUCTW tFileOptions = { 0 };

/* Initialize the file options structure for the deletion process */
tFileOptions.pFrom = pwstrPath;
tFileOptions.wFunc = FO_DELETE;
tFileOptions.fFlags = FOF_NOCONFIRMATION | FOF_SILENT | FOF_NOERRORUI;

/* Execute the deletions with the Shell operation */
iResult = SHFileOperationW(&tFileOptions);
if (0 != iResult)
{
    printf("WTF\n");
    goto lbl_cleanup;
}

SHChangeNotify(SHCNE_RMDIR, SHCNF_PATHW, pwstrPath, NULL);

The pwstrPath has a double null terminator at the end.

What can be the reason for these exceptions?

EDIT

Stack trace:

be good if you how minimum paste stack trace with **symbols** — RbMm, May 17 '17 at 12:56
faster of all this is heap corruption, makes by your code. but without how minimum stack trace impossible say exactly — RbMm, May 17 '17 at 13:36
@Olaf about the c++ tag, do you see here something that's not compliant with c++? The "goto" is fine here because it exits the function cleanly and cleans up any necessary resources. — cydan, May 17 '17 at 14:31
@RbMm I will provide you with a full stack trace when it will happen to me again, but I don't think that there's a heap corruption because I tried putting a "HeapValidate" check before the main's exit, and saw that there were no corruptions — cydan, May 17 '17 at 14:33
@cydan - very hard say exactly what happens here without debug crash yourself. the stack trace with installed pdb symbols (without this trace almost useless) this is mandatory minimum. the `SHFileOperationW` is unbelievable heavy api - i look on win10 and inside this function was made - 76473 internal functions calls. yes! 76k and not instructions but functions !! — RbMm, May 17 '17 at 14:40
@cydan: Theat is not the point. As no [mcve] is give, it could very well make a difference. Identtical syntax does not imply identical semantics! Just don't spam tags! If you compile as C++ use the C++ tag, if C, use the C tag! They are different languages. — too honest for this site, May 17 '17 at 14:43
@RbMm I added the stack trace.. Couldn't get symbols for one of the DLLs though — cydan, May 17 '17 at 16:23
@cydan - from stack visible that error in `DragExt64.dll` which how i understand is not native windows dll (not exist in my system). so this error in plugin extension — RbMm, May 17 '17 at 16:33
and really - you have no **pdb symbols** ! i view only **exports** ! but have **pdb symbols** installed is critical for any system level debugging. you can not have symbols for `DragExt64.dll` but for `shell32.dll`, `windows.storage.dll` and another windows dlls - **must** have — RbMm, May 17 '17 at 16:35
"It is done in multiple threads". That's not good, a custom shell extension like the one used by WinSCP is not very likely to handle that correctly. You can arbitrarily uninstall it, but this is just as likely to go wrong on the user's machine. Do keep in mind that deleting files on more than one thread is never useful. It is actually *slower*, disks don't like to be jerked around by more than one thread. — Hans Passant, May 17 '17 at 17:06

RbMm · Accepted Answer · 2017-05-17T16:58:18.210

from stack trace (even without pdb symbols - with it will be much more better ) visible that exception not inside windows shell itself but in third party product - dragext64.dll (this is not native windows image) wich is implement Copy Hook Handler - i advise uninstall this or disable via registry key

HKEY_CLASSES_ROOT
   Directory
      shellex
         CopyHookHandlers
            MyCopyHandler
               (Default) = {MyCopyHandler CLSID GUID}

and test after this. think exceptions must go away.

also look like some another shell extensions have bugs here - search in google SHELL32_CallFileCopyHooks. for example bug TortoiseGit.dll - note here in stack trace shell32.dll!SHELL32_CallFileCopyHooks()

so all this bugs inside implementation of ICopyHook::CopyCallback method

Thanks! It seems that DragExt64.dll belongs to WinSCP.. I will try to disable it via the registry key and see if I can reproduce it — cydan, May 17 '17 at 17:09

SHFileOperation: randomly raises exceptions when deleting files

1 Answers1