We are finding that deleting folders using SHFileOperation is very slow on systems that have been updated to 1709. It seems like there's something that's crept in related to Universal Windows apps that is causing this.
This code:
sFileOp.wFunc = FO_DELETE;
sFileOp.pFrom = buf;
sFileOp.fFlags = FOF_SILENT|FOF_NOCONFIRMATION|FOF_NOERRORUI;
if(SHFileOperation(&sFileOp))
passed a path like "C:\Jobs\Job1" (yes, doubly null terminated) with a small number of files in the folder -- say 2 or 3 - runs in milliseconds on Windows 7 and Windows 10 1511. On Windows 10 1709 it takes between 1 and 3 seconds.
What we notice in the Visual Studio 2013 Output window are 3 or 4 of these messages after SHFileOperation has been called and before it returns:
onecoreuap\shell\windows.storage\sharedstoragesources\util.cpp(2831)\windows.storage.dll!7650BF24: (caller: 765D88E4) ReturnHr(1) tid(1bb0) 80070490 Element not found.
This is a Win32, x86 app built with VS2013. This occurs on a release we've been shipping for over 18 months. To recap version runs as expected on 1511 and Windows 7, much too slowly on the last two Windows 10 updates. Somehow we've gotten tangled up with the Universal Windows app DLLs, it seems. How do we avoid this?