ErrLookup › Background articles › FileNotFoundException: "could not find file" — missing assets, wrong paths, dead downloads, and stripped embedded resources

FileNotFoundException: "could not find file" — missing assets, wrong paths, dead downloads, and stripped embedded resources

FileNotFoundException is thrown when code tries to open, read, or promote a file that does not exist at the resolved path. Developers meet it when a bundled asset is missing after install, a relative path resolves against the wrong working directory, a case-sensitive filesystem rejects a path that worked on Windows, an embedded resource was dropped by trimming, or a library maps an upstream HTTP 404 onto this exception. This article covers the family across 53 repositories: the layers that produce it, the causes that recur regardless of library, and the checks that prevent it.

Distilled from 204 documented records across 53 repositories.

Background

FileNotFoundException originates at the boundary between a path string and the filesystem. In the .NET Base Class Library it is thrown natively by File.Open and read APIs, and most libraries in this family add an explicit File.Exists guard before their own work so the error carries the offending path in a predictable place: DevToys' FileStorage.OpenReadFile, Playnite's DatabaseAPI.AddFile, PDFPatcher's OpenPdfFile, and OfficeCLI's OLE embedding all follow this guard-then-throw shape. From the caller's side it always looks the same — an exception whose message or FileName property names a path the code believed existed — but the reason the path is dead varies: the file was never written (UniGetUI promoting a .part download that never completed), it was deleted between a check and a use (Subtitle Edit batch jobs, stale FileInfo objects in DevToys), or it resolved against the wrong root (relative paths resolved against the CWD, a wrong FLINK_HOME for Flink's GPU discovery script).

A second cluster has nothing to do with the disk. Orleans Dashboard and jadx throw FileNotFoundException when an embedded manifest resource or classpath resource cannot be opened — a packaging defect, not a filesystem one — and .NET trimming or single-file publishes make this worse by silently dropping embedded assets. Wand-Enhancer shows the degenerate case: a resource name returned by GetManifestResourceNames() itself fails to open, signaling a corrupt assembly load. Subtitle Edit's DownloadHelper maps an upstream HTTP 404 onto FileNotFoundException deliberately, so a dead release-asset URL surfaces as a file-not-found and is excluded from the retry loop as a permanent condition rather than a transient network error. Kestra re-throws it when a namespace-file revision does not exist. A few records use the exception type as a general lookup-failed signal: Playnite fires it when an emulator profile's StartupExecutable regex matches no file, and one Flink Parquet record associates it with a physical-type/logical-type mismatch — behavior in those cases is library-specific and should be read on the record page.

Because the exception type itself says only "the thing is not there," diagnosis reduces to three questions: where did the path come from (user input, config, convention, a previous operation's output such as GetPartialPath or GetBackupPath), what root was it resolved against (working directory, AppCacheDirectory, FLINK_HOME, a JS script root, an emulator InstallDir, a mod's mounted file system in OpenRA), and did the file ever exist at that location (packaging, antivirus quarantine, version-control omission, a concurrent cleanup path). The 30 best-documented records show the answers cluster into a short list of recurring causes, ordered below by how often they appear.

Platform and build configuration matter as much as the library. Records from MonoGame, Playnite, OpenRA, and better-genshin-impact repeatedly flag case-sensitivity mismatches that only fire on Linux/macOS, because 'Track.MP3' and 'track.mp3' are different files there. MonoGame and better-genshin-impact records also treat build configuration — CopyToOutputDirectory and Content build actions in .csproj files — as a first-class cause, since a file present in the repository but never copied to build output is indistinguishable from a file that was never shipped.

Common causes

What usually fixes it

Go deeper

Documented occurrences

…and 184 more across the corpus — use search.

Honest provenance: generated on 2026-08-14 from AI-assisted analysis of the linked records. See how records are made.