On Windows, processes normally open files in a way that forbids other processes from deleting them. This is in contrast to posix-based systems where unlink is allowed to remove the name of a file that processes have open. There may also be other reasons we could fail to delete a file on Windows.

Recently we've been observing failures to remove the FTDC metrics.interim file on Windows using boost::filesystem::remove here. The error code is ERROR_INVALID_HANDLE, which I don't think corresponds to another process holding the file open (I think we'd expect ERROR_ACCESS_DENIED, ERROR_SHARING_VIOLATION, or ERROR_LOCK_VIOLATION). Nonetheless, these kinds of failures are a fact of life on Windows and we should probably be robust to them.

We've observed similar problems in the past with the shell. See SERVER-60887 and SERVER-44553 and the associated BFs for more information.

It's worth noting that this failure starting happening right after our windows-vsCurrent-* hosts got an update. I don't think the update is to blame per se, it probably just exposed the issue somehow.