MSB3027 means MSBuild tried to copy a file into your output folder, retried several times, and gave up; the most common cause Microsoft lists is that the destination file “is in use by another program.” The fix is to find which process holds that file, close or end only that process, and build again, rather than restarting Visual Studio or your PC. LockGhost from Automata Labs shows the exact app or service holding a locked file on Windows, with friendly names and guardrails, so you can release the right one.
See which process is holding your build output, then release just that one.
Get it from Microsoft
What does MSB3027 “Exceeded retry count” mean?
Microsoft’s MSB3027 reference gives the message as “Could not copy ‘value’ to ‘value’. Exceeded retry count of ‘value’. Failed.” and explains that “This error occurs when MSBuild tries to copy a file repeatedly and fails when the limit of the number of retries is reached.”
It usually arrives after a run of warnings. Each failed attempt logs MSB3026: “Could not copy ‘value’ to ‘value’. Beginning retry ‘value’ in ‘value’ms.” When the last retry fails, MSB3026 turns into the MSB3027 error. A related code, MSB3021, “Unable to copy file,” covers copy failures in general.
What causes MSB3027 and MSB3021?
Microsoft lists the same family of causes on both pages. For MSB3027, “Typical causes include the destination file is in use by another program, the permissions do not allow writing to the destination file, not enough space on the drive, or the network drive is not available.” For MSB3021, the first common cause listed is that “the file is locked by another process.”
| Cause | What it looks like | What to check |
|---|---|---|
| File in use by another program | The DLL or EXE in bin is held open | Which process holds it, and whether it should still be running |
| No write permission | Access denied in the extra message | Folder permissions and read-only attributes |
| Not enough disk space | Disk full message from Windows | Free space on the output drive |
| Network drive unavailable | Path on a mapped or network share | Connection and credentials for the share |
Both pages give the same advice: “The standard output message text is followed by additional information from the operating system.” That extra text is where the real answer usually is.
Does MSBuild tell you which process is locking the file?
Often, yes, and it is easy to miss. In the current MSBuild source, the MSB3026 and MSB3027 messages each end with an optional extra string from a helper called LockCheck, which reads: The file is locked by: followed by the process name in quotes.
The LockCheck code explains how it finds that name: “It uses the Restart Manager API to do this. Other platforms are skipped.” Restart Manager is the Windows API that installers use to find which applications and services have files open. So on Windows, scroll to the end of the MSB3026 warnings or the MSB3027 error in the build output. If a process name appears there, that is your first suspect.
If the field is empty, or you see a process name you do not recognize, you need a tool that can look at the file directly.
How do I fix MSB3027 step by step?
- Read the full message. Note the destination path, which is usually a DLL or EXE in your bin or obj folder, and any “locked by” name at the end.
- Check the obvious holder. A copy of the app you are building that is still running, or a debug session that has not fully stopped, will hold its own EXE and DLLs. Close it and build again.
- Find the real holder if it is not obvious. Check the file or folder with LockGhost from your normal Explorer workflow. It names the app or service holding the file, with friendly process names instead of bare process IDs.
- Release only that process. End or close just the process that holds the file. LockGhost’s guardrails help you avoid ending critical system processes by mistake.
- Build again. If the error returns, review LockGhost’s local lock history to see whether the same process keeps holding the file, which can point to a tool or extension that needs a setting change.
For related cases, see a DLL locked by a running process when you rebuild, cannot delete bin and obj output that is locked, and how Restart Manager finds a file lock on Windows.
Stop guessing in Task Manager when a build output file is in use.
Get it from Microsoft
Should I just increase the copy retry count?
Be careful. Microsoft’s Copy task reference says Retries “Specifies how many times to attempt to copy, if all previous attempts have failed,” and that while the task default is zero, “uses of the task often pass $(CopyRetryCount) which is nonzero by default.” A RetryDelayMilliseconds parameter sets the wait between attempts.
The same page carries a warning: “The use of retries can mask a synchronization problem in your build process.” More retries can help when a lock is brief, such as a scanner that opens a file for a moment. But if the same process holds the file for the whole build, more retries only make the build slower before it fails. Finding the holder is the lasting fix.
Can MSBuild itself keep files locked?
It can keep processes around. The MSBuild command-line reference says node reuse is on by default, so “Nodes remain after the build finishes so that subsequent builds can use them.” If a lock check names an MSBuild process, you can test a build with the switch -nodeReuse:false, which means “Nodes don’t remain after the build completes.” Use it to confirm a cause, not as a permanent setting, since reuse exists to make builds faster.
How is LockGhost different from rebooting or killing processes in Task Manager?
A reboot frees every file, but it costs you your open work and does not tell you what caused the lock, so it can happen again. Task Manager can end processes, but it does not show which one holds a given file. LockGhost starts from the file:
- Process-level clarity: it shows the exact app or service blocking the file.
- Friendly process details: understandable app names and clear lock information instead of obscure IDs.
- Safe resolution controls: you act only once you understand what is blocking the file.
- Explorer-friendly workflow: you check locks from your normal file management routine.
- Local lock history: recent lock events stay on your PC.
- Private: 100% offline, with no cloud account and no telemetry, on Windows 10 and Windows 11.
For other developer lock errors, see Git cannot delete a file used by another process and node_modules EPERM: operation not permitted. For a tool comparison, read PowerToys File Locksmith vs LockGhost.
Frequently asked questions
Is MSB3027 a bug in my code?
Usually not. It is a file copy failure during the build. Microsoft’s most common listed cause is a destination file in use by another program.
What is the difference between MSB3026 and MSB3027?
MSB3026 is the warning logged on each retry. MSB3027 is the error logged when MSBuild runs out of retries.
Why does the error mention a file in obj or bin?
Those folders hold the outputs MSBuild copies at the end of a build, such as your DLL and EXE. A running copy of your app, or another tool, can keep them open.
Will cleaning the solution fix it?
Not if a process still holds the file, because the clean needs to delete the same file. Release the holder first. See cannot delete a file in use on Windows.
Does LockGhost send my file names anywhere?
No. LockGhost is offline and keeps file names, folders and lock history on your PC.
Try LockGhost
Get LockGhost from the Microsoft Store. It is a one-time purchase with no subscription, and the Store listing shows the current price.
Find the process behind file in use errors in seconds, locally and offline.
Get it from Microsoft
Microsoft, Windows, Visual Studio and MSBuild are trademarks of the Microsoft group of companies. LockGhost is not affiliated with or endorsed by Microsoft.
Last updated 21 October 2026. Published by Automata Labs, a software company in Canada.