Here’s something interesting and mildly mystifying. If you use Reliability Monitor to keep tabs on Windows stability, you may have spotted old_mscopilot_proxy.exe as a problem item — I certainly have. My most recent entry occurred July 6, 2026, at 12:02 PM. That naturally sent me hunting for the file so I could understand what it was doing and if I could delete it safely. What I found — or rather, what I didn’t find — tells a nifty story about how Reliability Monitor actually works. Despite throwing error, old_mscopilot_proxy.exe is MIA when I try to search (and perhaps root) it out.
Despite Throwing Error, Old_mscopilot_proxy.exe Is MIA
Take a look at the lead-in graphic. It shows the error details from Reliability Monitor. Basically, it’s saying that the app has quit working. To be more specific, it says the program has “stopped interacting with Windows and was closed.” The version number provided — 149.0.4022.80 — follows a Chromium-based versioning scheme Microsoft adopted for its Copilot app. That’s an important and concrete clue about the file’s true origin.
Key factoid: the old_ prefix is a standard artifact of Microsoft’s in-place updater for Copilot. Before dropping a new executable, the updater renames the currently running binary to old_[filename].exe as a rollback maneuver. Once the new version installs successfully, that old_ file should be cleaned up automatically. In practice, that cleanup step fails silently with some regularity, leaving an orphaned executable on disk — and a crash record in the event log when the system subsequently tries to invoke it.
Seeking Old Copilot Files/Versions
Knowing where the file should be is not the same as finding it. I ran Get-ChildItem searches against C:\Windows, LocalAppData, Program Files, and the notoriously ACL-locked C:\Program Files\WindowsApps folder — all with -ErrorAction SilentlyContinue to suppress access-denied noise. Every search returned immediately with no output. I then queried the Windows Error Reporting archive and queue folders using Select-String to look for any .wer report referencing the file. Nothing there either. Finally, I launched Voidtools Everything as administrator, triggered a full C: rescan, and searched again. The file is completely absent, gone MIA.
Why Does ReliMon Report This Error?
Here’s the part that catches people off-guard, including your humble author. Reliability Monitor does not verify live disk state before displaying an error entry. It reads the Windows Application Event Log — specifically Event ID 1000 Application Error records. These persist independently of whether or not the executable they name still resides on disk. Such log entries cannot be selectively deleted in Windows, either. You’d have to clear the whole Application log to remove them, which is far too blunt an instrument for this situation.
When in Doubt, Do No Harm (Nothing)
There’s really no need to do anything about this error, except to recognize its (in)significance. The file is gone, the Windows Error Reporting reports are gone, and the Application event log entry from July 6 will age out of Reliability Monitor’s 28-day display window naturally — in my case, by August 3, 2026. If you want to confirm that the event log is the sole remaining source of the entry, run this command string in an elevated PowerShell session:
Get-WinEvent -LogName Application | Where-Object { $_.Message -like "*mscopilot_proxy*" } | Select-Object TimeCreated, Id, Message | Format-List
When I run it, I get hits from 7/6, but also 6/19, 6/12, 5/28, and then weekly back to 4/14. This, apparently, is a pretty constant (if bogus) error on the Flo6 system. Indeed, Copilot tells me “the ghost error pattern — where a file that no longer exists keeps appearing in Reliability Monitor — is surprisingly common and poorly documented.”
But once you understand that Reliability Monitor reads historical event log records rather than interrogating live disk state, these apparent mysteries resolve themselves. The file is gone, the risk is zero, and the entry will vanish from ReliMon on its own (though it remains in the error log). Sometimes the best fix is no fix at all, particularly when there’s nothing wrong, nor anything to repair. Here in Windows-World, doing nothing can come as a welcome relief. That’s my take, anywho…
