MOVEFILE_DELAY_UNTIL_REBOOT

Some time ago, I have described ShareAccess parameter present in API functions responsible for opening files. If you don’t remember it, try to find “Locker” email in your inbox, somewhere near mid-August. I have intentionally focused on mechanisms and not on dealing with them, and today I will focus on one thing more: on deleting or renaming files that are “locked”, and you cannot unlock them.
​
Of course, killing the locking process works well, but not all processes can be freely killed. What if the file is locked by a process that starts automatically? Let’s assume someone wants to delete one of system files to observe an effect. Don’t do this on any production machine, but I would bet you want to know the effect anyway.
​
Theoretically we can boot from the removable media and manipulate the file offline, but it’s very manual, requires offline access and historically was way harder before Windows PE was introduced. Delete does not work, rename does not work and if the “System” pseudo-process locks the file, no one can kill the owner.
​
And here comes the MOVEFILE_DELAY_UNTIL_REBOOT flag. You can specify it when calling MoveFileEx() or MoveFileWithProgress() API functions. Instead of renaming (a.k.a. moving) the file immediately, Windows registers the wish for renaming (or deletion) in the PendingFileRenameOperations value of the “Control\Session Manager” registry key and the smss.exe process performs the actual operation during next boot, before anyone else can lock the file.
​
The mechanism is very simple, may lead to strange situations (when you don’t notice the file was registered for renaming at next boot) and you can manipulate it a bit by changing the registry entries directly.
​
Feel free to play with the function and registry keys, and if you are in hurry – use movefile and pedmoves tools from Systinternals. I believe sooner or later I’ll describe less brutal (not requiring restart) ways of replacing (or copying) a locked file as well.
Stay tuned!