Mark Russinovich has chased this Windows annoyance since the 1990s. Now Azure CTO and Technical Fellow at Microsoft, he recently laid out exactly why the operating system insists a file remains “in use” even after its apparent application has vanished from the screen. The explanation mixes file handles, background scanners, network ghosts and memory-mapped DLLs. And the tools he built decades ago still work best.
The classic error reads simple enough. “The action can’t be completed because the file is open in another program.” Users see it when they try to delete, rename or move a document, photo or executable. Windows 11 throws the message with the same stubbornness as its predecessors. Yet the program in question often sits closed. No visible window. No obvious process in Task Manager. Frustration builds fast.
Russinovich unpacked the mechanics in a recent video. Every time software opens a file, the kernel creates a handle. That structure tracks ownership and prevents destructive changes that could corrupt live data. Close the app cleanly and the handle should disappear. Reality disagrees. Handles linger. Background tasks keep them alive. So do other machines on the local network.
Antivirus provides one frequent culprit. Security software opens files at the system level to scan them. Media Player or Word may have exited minutes earlier. The antivirus engine keeps scanning. Its handle blocks deletion. Network shares create similar traps. A colleague on another PC might have browsed the folder. That remote access leaves a reference behind even after the share closes.
The toughest case involves DLLs. Load a library into a process and Windows maps the file into memory. Standard handle queries miss it. The file shows no open references yet stays locked because its contents sit inside an application’s address space. Only terminating the entire hosting process frees the mapping. Russinovich noted this scenario trips up experienced administrators.
Microsoft has carried this behavior across decades of development. The company rarely discusses it in public release notes. Russinovich’s comments mark a welcome admission. He first hit the problem early in his career and responded by writing diagnostic software. Those utilities now ship inside the Sysinternals suite that Microsoft owns and updates. Windows Latest first reported his detailed breakdown on June 30, 2026.
Handle.exe remains the quickest command-line option. Run it with administrator rights, point it at the locked filename and it lists every process holding a reference. The output includes process IDs, allowing targeted termination. Process Explorer, the graphical counterpart, adds visual clarity. Press Ctrl+Shift+F inside it. Type the filename. Results appear instantly. Right-click any listed handle and close it directly when safe.
PowerToys users enjoy an even simpler path. The File Locksmith module integrates directly into the context menu. Right-click the stubborn file, choose “Unlock with File Locksmith” and a clean list appears. Kill the offending process from that window and retry the deletion. No command prompt required. Russinovich himself once suggested deeper Sysinternals integration into PowerToys. Progress on that front continues.
But what happens when immediate termination feels risky? Russinovich offered a practical workaround. Rename the locked file instead of deleting it. Windows sometimes permits the rename even when handles remain active. Place a fresh copy with the original name in the same directory. Dependent processes switch to the new version. The renamed original can wait until its handles expire, then vanish safely.
IT professionals have relied on these techniques for years. The persistence of the problem into 2026 reveals how much of the operating system’s file-management foundation traces back to older design choices. Recent Windows 11 updates focused on File Explorer speed and low-latency improvements, yet core locking logic stayed untouched. Windows Latest covered the faster File Explorer rollout just days earlier on June 28, 2026.
Enterprise environments see the error more often. Shared drives, centralized antivirus servers and background indexing services multiply the opportunities for stray handles. Developers encounter it when rebuilding projects that load custom DLLs. Even routine photo management can trigger it if cloud-sync clients keep files open for thumbnail generation.
Some third-party tools promise one-click unlocking. They usually wrap the same Sysinternals logic or call similar kernel APIs. Microsoft does not endorse them for production use. The built-in options and Russinovich’s rename trick cover most cases without extra software.
The discussion spread quickly across forums after the video surfaced. System administrators traded new examples. One thread highlighted Photoshop leaving lock files behind even after exit. Another noted certain backup utilities that scan entire drives on schedule. Each case traced back to the same trio of causes Russinovich outlined: scanners, network references and memory mappings.
Future Windows versions could improve transparency. Displaying the actual process name in the error dialog would help. Exposing memory-mapped files in standard tools would reduce reliance on third-party utilities. For now users must dig deeper. The tools exist. They simply require knowing where to look.
Russinovich’s long career demonstrates both the problem’s age and the value of transparency. He built Handle and Process Explorer because the operating system hid critical details. Those utilities remain relevant because parts of Windows still operate the same way. The recent explanation changes little in the code. It changes everything in how administrators approach the error.
Next time the dialog appears, resist the urge to reboot. Open Process Explorer. Search for the file. Check for antivirus activity or network connections. Consider the DLL possibility if nothing shows. Rename if termination feels dangerous. The file will yield. Understanding the reason makes the wait shorter.
WebProNews is an iEntry Publication