What causes "[x] Could not load file {0:s} as a PE" in lucasg/Dependencies?

Confirm the file is a PE image with `dumpbin /headers ` or another PE-aware tool.

[x] Could not load file {0:s} as a PE

Error message

[x] Could not load file {0:s} as a PE

What it means

Printed by Main (Program.cs:884) when `new PE(FileName)` followed by Pe.Load() returns false. The file exists on disk but phlib could not parse it as a valid PE/COFF image (bad DOS/PE header, truncated, unsupported architecture). The process returns without running the selected command.

Source

Thrown at Dependencies/Program.cs:884

                Console.Error.WriteLine("[x] Command {0:s} needs to have a PE <FILE> argument", command.Method.Name);
                Console.Error.WriteLine("");

                DumpUsage();
                return;
            }

			String FileName = eps[0];
            if (!NativeFile.Exists(FileName))
            {
                Console.Error.WriteLine("[x] Could not find file {0:s} on disk", FileName);
                return;
            }

			Debug.WriteLine("[-] Loading file {0:s} ", FileName);
			PE Pe = new PE(FileName);
            if (!Pe.Load())
            {
                Console.Error.WriteLine("[x] Could not load file {0:s} as a PE", FileName);
                return;
            }

            command(Pe, GetObjectPrinter(export_as_json), recursion_depth);

        }
    }
}

View on GitHub (pinned to 1997a40000)

Solutions

Confirm the file is a PE image with `dumpbin /headers <file>` or another PE-aware tool.
Re-download/rebuild the binary if it is truncated or corrupted.
Ensure you are using the Dependencies build (x86/x64) appropriate for the target image.

Defensive patterns

Strategy: validation

Validate before calling

var pe = new PE(fileName);
if (!pe.Load())
{
    Console.Error.WriteLine($"[x] Could not load file {fileName} as a PE");
    return;
}
// pe.LoadSuccessful is true here; safe to call GetImports/GetExports/etc.

Prevention

Always check the bool returned by PE.Load() before using the PE instance - a constructed PE is not necessarily loaded.
Match the Dependencies build bitness (x86/x64) to the target image to avoid spurious parse failures.

When it happens

Trigger: Pointing Dependencies at a file that exists but is not a PE: a text file, a Mach-O/ELF binary, a corrupted/truncated image, or a PE for an architecture phlib rejects.

Common situations: Analysing a non-Windows binary by mistake; a download that was truncated; a packed image whose headers were corrupted; cross-platform binaries (.NET Core self-contained linux builds).

Related errors

AI-assisted analysis of lucasg/Dependencies@1997a40000 (2026-08-13). Data as JSON: /api/errors/fd49b85b542cd3ee. Report an issue: GitHub.