If Windows says a file is open in Runtime Broker, do not delete RuntimeBroker.exe or force-close a mysterious handle. A program or Windows component still has a reference to that file, so the move, rename, or delete operation cannot finish yet. Save any work in the app that opened the file, close that app normally, then retry once. If the message returns, identify the exact file and the process holding it before ending anything. Drecov is not an unlocking tool; it matters only if a local file is actually lost later.
⚠ Warning: Install it on a drive different from the one where your data was lost to prevent overwriting.
What the message proves—and what it does not
Runtime Broker is a Windows process associated with app permissions. Its name in the dialog tells you that Windows sees the target file as open in that process at the moment of the attempted action. It does not tell you that the file is infected, permanently damaged, or impossible to remove. Nor does it prove which visible app started the access. A photo viewer, media player, Store app, preview pane, or another component may still be working with the item after its window appears to have closed.
Write down the file’s full path and what you were trying to do. Was it a photo in Pictures, a video on an external drive, or a file in a synchronized folder? Is the operation a rename, move, or delete? Check that the filename in the dialog matches the file you intended. If you are deleting a folder, one item inside it may be the real source of the lock. Do not try to clear the message by taking ownership, changing permissions, or formatting a drive; those actions solve different problems and can create new ones.
A file lock is also different from File Explorer failing to open at all. If Explorer itself will not launch, use the separate guide to restore File Explorer access. Stay here when Explorer works but one specific file repeatedly triggers the Runtime Broker dialog.
Close the program that last used the file
Start with the least disruptive action. Save current edits in the photo, video, document, or Store app that opened the file. Close its window normally. If a media file was playing, stop playback before closing the player. Turn off File Explorer’s Preview pane for the folder while testing, or switch to a different folder so the item is no longer selected. Then return and repeat the original action once. An immediate success means the handle was temporary; there is no need to change Windows settings.
If several apps may have used the same item, close them one at a time and retry. That order helps identify the real trigger. A recently viewed video, for example, may still be held by the viewer rather than by the folder itself. Avoid ending every process named Runtime Broker in Task Manager just because several instances appear. Windows can run multiple broker processes for different app activity. Ending the wrong one can interrupt an app or discard work without proving the file is free.
Where the file lives in OneDrive or another synchronized location, check whether a copy or upload is still running. Let the current operation finish and look for a conflict or pending state. A synchronization error may coexist with the Runtime Broker message, but deleting the local copy to “free it” could remove the version you meant to keep. Preserve a separate copy of irreplaceable content before testing any deletion. On a shared computer, ask whether another signed-in user or app is currently using the same file.
Use a normal restart as a controlled reset
When closing the likely app does not release the file, save all open work and restart Windows normally. A restart closes processes and their ordinary file handles. Sign back in and try the same action before reopening the viewer or player. If the lock is gone, you can stop there. If the dialog reappears only after launching one app, you have a useful lead for further troubleshooting. Record the app name and the kind of file involved.
A restart is not a reason to force power off during a file copy or an update. Wait for ongoing operations to finish. On an external disk, check that the cable and drive remain stable. If the drive disconnects repeatedly or returns read errors, do not keep retrying moves and deletions. A storage fault needs data protection first; it is not cured by terminating a process. Our article on an external drive freezing File Explorer addresses that broader device problem.
If the file becomes available after restarting but the problem recurs with every new photo or video, focus on the app or preview workflow that repeatedly opens it. Check the app’s current update and Windows Update status using normal settings. Change one behavior at a time—such as testing another supported viewer—then see whether the same operation still fails. This is more informative than running multiple cleanup tools with no known relationship to the lock.
When the holder is unclear, verify the handle
Microsoft’s Process Explorer can show which processes have files or other objects open. Download it from Microsoft’s Sysinternals page, not from an unverified mirror. Run it under an account with appropriate rights. Use its search function for a distinctive part of the file name or path, then read the result rather than immediately changing anything. A match helps confirm whether Runtime Broker, a viewer, or another process currently holds that specific item.
Be precise about the search term. A common name such as “video” may match many files, while a unique filename or final folder segment is easier to interpret. Check the full path in the result. A search that returns no match does not prove the disk is damaged; the handle may have closed before the search, or the file may be held differently. Retry the original move or rename once. If that works, the temporary lock has already cleared.
Process Explorer is a diagnostic tool here, not a license to close a handle by force. Forcibly closing handles can destabilize the application or Windows and can leave a file half-written. If the holder is a normal app, save its work and close it through its interface. If it appears to be Runtime Broker again, restart and test without reopening the app that previously used the file. Do not rename, delete, or replace the Windows executable. If you are unsure which process owns the handle, stop rather than experimenting with system processes.
Why a file may remain locked after the visible window closes
Closing a window does not always end every background task immediately. A viewer may still be generating a thumbnail, a player may be reading metadata, or a Store app may continue a task briefly. This is a plausible explanation, not a diagnosis of your individual computer. The way to test it is to close the app, wait for its operation to finish, and see whether the lock disappears without changing permissions. If the problem follows a particular file type, compare another small file of that type in a separate folder.
Do not confuse this with a file that cannot be deleted because of permissions. A permissions dialog names access rights rather than a program that has the file open. A read-only attribute, a protected system location, and an active handle are different conditions. Likewise, a file that is missing from the folder after a failed move is not necessarily deleted: check the original and destination paths first. Repeating a move while unsure where the file went can produce duplicates or overwrite a newer copy.
When File Explorer begins crashing instead of merely reporting the lock, the troubleshooting path changes. Repeated application failures need a separate diagnosis. For a single Runtime Broker lock, keep the investigation centered on the named file, its recent app, and the observed process handle.
If an important local file was deleted during the attempts
Unlocking a file and recovering a deleted file are different tasks. If the file still exists but Windows will not let you move it, Drecov does not release the handle. If it was actually deleted by mistake after the lock cleared, stop writing new data to that drive. Check Recycle Bin, the folder you moved it to, and any available version history first. The broader guide to undeleting files in Windows covers those built-in routes.
Drecov is Windows data-recovery software for a stable, accessible source drive. Only in this actual-loss branch can its Quick Scan, optional Deep Scan, filters, and preview help locate a deleted local copy. Lost Partition Recovery is available for a lost partition, but a Runtime Broker file lock is not a lost partition. The program does not repair physical damage or guarantee recovery after the storage area has been overwritten. Prepare another healthy destination, and never install the software onto the partition where the deleted file was stored.
Recover only after confirming the file is missing
Step 1: Open Drecov and choose the original drive
Select the partition that contained the file before deletion. Use its former folder path and filename as search clues. If the item lived solely in a cloud account and never had a local copy, a local drive scan is not the right first method.
Step 2: Run Quick Scan, then Deep Scan if needed
Start with Quick Scan. If the target is absent and the drive remains stable, continue with Deep Scan. Stop repeated scans when the disk clicks, disconnects, or develops serious read errors; an image or specialist may be safer.
Step 3: Filter, find, and preview likely matches
Search by name, old folder, and file type. Preview a supported candidate to see whether its content is recognizable. A preview checks that sample, not every page, frame, or archive member. Keep more than one plausible version if dates differ.
Step 4: Save elsewhere and verify the file
Recover the candidate to the healthy destination, never the source. If it is not in the expected output path, inspect Drecov Folder or Recovery Folder. Open the recovered file and check its content and size before deleting any remaining copies or cleaning the original folder. If recovery is incomplete, preserve the source instead of continuing to write to it.
⚠ Warning: Install it on a drive different from the one where your data was lost to prevent overwriting.
Conclusion
“File is open in Runtime Broker” is a file-handle message, not a request to remove a Windows component. Save work, close the app that used the file, retry once, and use a normal restart or Microsoft’s Process Explorer when the holder remains unclear. Do not force-close handles or treat a disk problem as a simple lock. Drecov belongs only to the separate situation where a local file was truly deleted: on a stable source, it can search, preview, and restore that file to another healthy drive. It cannot unlock a file that still exists.
⚠ Warning: Install it on a drive different from the one where your data was lost to prevent overwriting.
