LINK : fatal error LNK1104: cannot open file — Identify the File First

Why LNK1104 happens

Microsoft documents LNK1104 when the linker cannot open a file for reading or writing. Two common causes are a program/output file that is still in use and an incorrect or unquoted library path, but the same error code also covers missing Microsoft libraries, third-party libraries, project outputs and other file-access problems. That is why the filename is the diagnostic key.

Diagnostic flow — classify the file before fixing anything

Fix #2 — if LNK1104 names your .exe or .pdb, release the output file

If the filename is the executable being built or its program database, stop the application and unload it from the debugger. Also close any editor or tool that has the output open. If the lock is not obvious or recurs, identify the process holding the exact output path with an approved Windows handle/resource-monitoring tool before killing unrelated processes. If the owning process is unresponsive, end that specific process; restarting Visual Studio is a later fallback, not the first diagnostic step.

Verify: rebuild the same configuration and output path. Success means LINK can overwrite/create the same .exe or .pdb. If releasing one process fixes it only temporarily, capture which process reacquires the file rather than treating repeated IDE restarts as the solution.

Fix #3 — if it names a .lib, determine who owns that library

Microsoft library: first check that the active project still inherits the normal MSVC and Windows SDK library directories. In Visual Studio, inspect the active configuration/platform under VC++ Directories → Library Directories and Linker → General → Additional Library Directories. A custom value can accidentally replace inherited defaults instead of extending them. Then verify the intended C++ workload/toolset and Windows SDK are installed and selected. A standard library such as kernel32.lib, msvcprt.lib or msvcprtd.lib should not be “fixed” by downloading a replacement file.

Third-party library: resolve the exact .lib path that LINK is attempting to open, then confirm that specific file exists and the build identity can read it. In Visual Studio, inspect Configuration Properties → Linker → General → Additional Library Directories and Linker → Input → Additional Dependencies. For command-line builds, inspect /LIBPATH and the LIB environment. Debug/Release and x86/x64/ARM64 configuration matter because they often select different directories or filenames. An architecture mismatch in a file LINK successfully opens normally progresses to a different linker diagnostic; for LNK1104, focus first on why the selected file/path cannot be opened. In the Visual Studio Additional Dependencies property editor, keep each library as its own entry; do not paste a malformed combined filename.

Verify: resolve the final path for the exact library named by LNK1104, confirm it exists and is readable under the same build identity, then rerun the same LINK invocation/configuration. If LINK opens it and reports a machine-type, symbol, runtime or other linker error next, stop diagnosing LNK1104 and follow that new failure class.

Fix #4 — if another project should build the file, repair the dependency

When LNK1104 names a library or object produced by another project in the solution, first confirm that producer project successfully creates the expected file. Then check the project reference/dependency so it builds before the consumer. Do not mask a failed producer build by manually copying an old output into the consumer’s directory.

Verify: Clean/rebuild the relevant projects. The producer should create the expected file before the consumer reaches LINK, and the consumer should reference that current output.

Fix #5 — if the filename looks like C:\Program.obj, repair path quoting

Microsoft specifically documents C:\Program.obj as a symptom of an unquoted path beginning with C:\Program Files. Inspect /LIBPATH, LIB, VC++ Library Directories, Additional Library Directories and Additional Dependencies for paths containing spaces. Also inspect the exact Additional Dependencies entries: malformed separators can turn what should be separate library names into one impossible filename.

Verify: Rebuild and inspect the error text. A correctly quoted path should no longer be split into a fake root-level object such as C:\Program.obj.

Fix #6 — if it is LNKnnn, temporary, unusually long or very large

Filename looks like LNKnnn: Microsoft identifies names of this form as temporary files created by the linker. Check that TMP/TEMP points to an existing writable directory and that the drive has free space.

Ordinary temporary/output file: verify the target directory exists and the current build identity can write there. Prefer fixing the specific inaccessible directory over running the whole IDE permanently as Administrator.

Very long path: if the resolved filename/path approaches the traditional Windows MAX_PATH boundary, shorten the project/output/library path and rebuild. Treat this as an edge case after the normal filename branches, not as a first fix.

Very large .lib or .obj: Microsoft also documents rare failures where the 32-bit linker can exhaust address space while handling very large files. If the named file is exceptionally large and ordinary path/access checks pass, use the 64-bit-hosted MSVC toolchain/linker rather than deleting or replacing the library.

Verify: For LNKnnn, confirm the build identity can create/remove a file in the resolved temp directory. For long paths, confirm the shortened resolved path is used. For very large inputs, confirm the build invokes the 64-bit-hosted linker and moves past the same file.

Still seeing LNK1104?

Capture the exact filename, its resolved full path and the active build context before changing anything else. Preserve the final LINK command when possible: two builds with the same visible LNK1104 text can be searching different directories because of configuration, environment or generated-command differences. If the filename or resolved path changes after a fix, treat it as a new diagnostic branch rather than assuming the original cause remains.

Official references