{"id":43723,"date":"2014-10-31T07:00:00","date_gmt":"2014-10-31T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2014\/10\/31\/the-case-of-the-file-that-wont-copy-because-of-an-invalid-handle-error-message\/"},"modified":"2014-10-31T07:00:00","modified_gmt":"2014-10-31T07:00:00","slug":"the-case-of-the-file-that-wont-copy-because-of-an-invalid-handle-error-message","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20141031-00\/?p=43723","title":{"rendered":"The case of the file that won't copy because of an Invalid Handle error message"},"content":{"rendered":"

\nA customer reported that they had a file that was “haunted”\non their machine:\nExplorer was unable to copy the file.\nIf you did a copy\/paste, the copy dialog displayed an error.\n<\/p>\n\n\n\n
1 Interrupted Action<\/td>\n<\/tr>\n
\n

Invalid file handle<\/p>\n\n\n
⚿ <\/td>\nContract Proposal
\n Size: 110 KB
\n Date modified: 10\/31\/2013 7:00 AM<\/td>\n<\/tr>\n<\/table>\n<\/td>\n<\/tr>\n<\/table>\n

\nOkay, time to roll up your sleeves and get to work.\nThis investigation took several hours, but you’ll be able to read\nit in ten minutes\nbecause I’m deleting all the dead ends and red herrings,\nand because I’m skipping over a lot of horrible grunt work,\nlike tracing a variable in memory backward in time to see where\nit came from.¹\n<\/p>\n

\nThe Invalid file handle<\/i> error was most likely coming from\nthe error code\nERROR_INVALID_HANDLE<\/code>.\nSome tracing of handle operations\nshowed that a call to\nGet­File­Information­By­Handle<\/code>\nwas being passed INVALID_FILE_HANDLE<\/code>\nas the file handle,\nand as you might expect,\nthat results in the invalid handle error code.\n<\/p>\n

\nOkay, but why was Explorer’s file copying code getting confused\nand trying to get information from an invalid handle?\n<\/p>\n

\nCode inspection showed that the handle in question is normally\nset to a valid handle during the file copying operation.\nSo the new question is,\n“Why wasn’t<\/i> this variable set to a valid handle?”\n<\/p>\n

\nDebugging why something didn’t happen is harder than debugging\nwhy it did<\/i> happen,\nbecause you can’t set a breakpoint of the form\n“Break when X doesn’t happen.”\nInstead\nyou have to set a breakpoint in the code that you’re\npretty sure is being executed,\nthen trace forward to see where execution strays from the intended path.\n<\/p>\n

\nThe heavy lifting of the file copy is done by the\nCopy­File2<\/code> function.\nExplorer uses the\nCopy­File2­Progress­Routine<\/code> callback\nto get information about the copy operation.\nIn particular, it gets a handle to the destination file by\nmaking a duplicate of the\nhDestination­File<\/code> in the\nCOPY­FILE2_MESSAGE<\/code> structure.\nThe question is now,\n“Why wasn’t Explorer told about the destination file that\nwas the destination of the file copy?”\n<\/p>\n

\nTracing through the file copy operation showed that the file\ncopy operation actually failed<\/i>\nbecause the destination file already exists.\nThe failure would normally be reported as\nERROR_FILE_EXISTS<\/code>,\nand the offending\nGet­File­Information­By­Handle<\/code>\nwould never have taken place.\nSomehow the file copy was being treated as having succeeded\neven though it failed.\nThat’s why we’re using an invalid handle.\n<\/p>\n

\nThe Copy­File2<\/code> function goes roughly like this:\n<\/p>\n

\nHRESULT CopyFile2()\n{\n BOOL fSuccess = FALSE;\n HANDLE hSource = OpenTheSourceFile(); \/\/ calls SetLastError() on failure\n if (hSource != INVALID_HANDLE_VALUE)\n {\n  HANDLE hDest = CreateTheDestinationFile(); \/\/ calls SetLastError() on failure\n  if (m_hDest != INVALID_HANDLE_VALUE)\n  {\n   if (CopyTheStuff(hSource, hDest)) \/\/ calls SetLastError() on failure\n   {\n    fSuccess = TRUE;\n   }\n   CloseHandle(hDest);\n  }\n  CloseHandle(hSource);\n }\n return fSuccess ? S_OK : HRESULT_FROM_WIN32(GetLastError());\n}\n<\/pre>\n
\nNote<\/b>: This is not the actual code,\nso don’t go whining about the coding style or the inefficiencies.\nBut it gets the point across for the purpose of this story.\n<\/p>\n
\nThe Create­The­Destination­File<\/code> function\nfailed because the file already existed,\nand it called Set­Last­Error<\/code> to set the\nerror code to\nERROR_FILE_EXISTS<\/code>,\nexpecting the error code to be picked up when it returned to the\nCopy­File2<\/code> function.\n<\/p>\n
\nOn the way out,\nthe Copy­File2<\/code> function\nmakes two calls to Close­Handle<\/code>.\nClose­Handle<\/code> on a valid handle is not supposed\nto modify the thread error state,\nbut somehow stepping over the Close­Handle<\/code>\ncall showed that the error code set by\nCreate­The­Destination­File<\/code> was\nbeing reset back to ERROR_SUCCESS<\/code>.\n(Mind you, this was a poor design on the part of the\nCopy­File2<\/code> function to leave the error code\nlying around for an extended period,\nsince the error code is highly volatile, and you would be best\nserved to get it while it’s still there.)\n<\/p>\n
\nCloser inspection showed that the\nClose­Handle<\/code> function\nhad been hooked by some random DLL that had been\ninjected into Explorer<\/i>.\n<\/p>\n
\nThe hook function was somewhat complicated\n(more time spent trying to reverse-engineer the hook function),\nbut in simplified form, it went something like this:\n<\/p>\n
\nBOOL Hook_CloseHandle(HANDLE h)\n{\n HookState *state = (HookState*)TlsGetValue(g_tlsHookState);\n if (!state || !state->someCrazyFlag) {\n  return Original_CloseHandle(h);\n }\n ... crazy code that runs if the flag is set ...\n}\n<\/pre>\n
\nWhatever that crazy flag was for,\nit wasn’t set on the current thread,\nso the intent of the hook was to have no effect in that case.\n<\/p>\n
\nBut it did<\/i> have an effect.\n<\/p>\n
\nThe\n\nTls­Get­Value<\/code> function<\/a>\nmodifies the thread error state,\neven on success.\nSpecifically, if it successfully retrieves the thread local storage,\nit sets the thread error state to\nERROR_SUCCESS<\/code>.\n<\/p>\n
\nOkay, now you can put the pieces together.\n<\/p>\n