lucasg/Dependencies · error

[!] Unhandled exception occured while processing "{1:s}"

Error message

[!] Unhandled exception occured while processing "{1:s}"

What it means

Printed by SafeExecutor<T>'s generic catch(Exception ex) (Program.cs:551) when an UNRECOGNISED exception escapes the action lambda inside LoadPe()/ResolveDependencies(). Unlike the RethrownException branch, this is the first time the exception is seen, so it is wrapped in a new RethrownException (Program.cs:554) to start the module backtrace. NOTE: the format string uses {1:s} while passing (RecursionLevel, Filepath) as args, so Filepath is what is shown; RecursionLevel is passed but unused in this line.

Source

Thrown at Dependencies/Program.cs:551

        private void SafeExecutor(Action action)
        {
            SafeExecutor(() => { action(); return 0; });
        }

        private T SafeExecutor<T>(Func<T> action)
        {
            try
            {
                return action();
            }
            catch (RethrownException rex)
            {
                Console.Error.WriteLine(" - \"{0:s}\"", Filepath);
                throw rex;
            }
            catch (Exception ex)
            {
                Console.Error.WriteLine("[!] Unhandled exception occured while processing \"{1:s}\"", RecursionLevel, Filepath);
                Console.Error.WriteLine("Stacktrace:\n{0:s}\n", ex.StackTrace);
                Console.Error.WriteLine("Modules backtrace:");
                throw new RethrownException(ex);
            }
            finally
            {
                //
                
            }

            // return default(T);
        }

        // Json exportable
		public string ModuleName;
        public string Filepath;
        public ModuleSearchStrategy SearchStrategy;
        public List<PeDependencyItem> Dependencies

View on GitHub (pinned to 1997a40000)

Solutions

1. Look at the Stacktrace line printed next (error 4) to find the throwing call site and method.
2. Reproduce with `-cache` off and a single target to reduce concurrency/noise, then fix the root cause at the identified call site.
3. If the cause is an unloadable transitive DLL, exclude it by lowering `-depth` or resolving the underlying file access problem.

Example fix

// before (Program.cs:551) - RecursionLevel passed but unused, message is vague:
Console.Error.WriteLine("[!] Unhandled exception occured while processing \"{1:s}\"", RecursionLevel, Filepath);
// after - include depth and the exception message:
Console.Error.WriteLine("[!] Unhandled exception at depth {0} while processing \"{1:s}\" : {2}", RecursionLevel, Filepath, ex.GetType().Name);

// SafeExecutor wraps any non-RethrownException into a RethrownException,
// so callers only ever need to catch RethrownException at the boundary.
try
{
    Program.DumpDependencyChain(pe, Program.PrettyPrinter, depth);
}
catch (RethrownException rex)
when (rex.InnerException != null)
{
    // rex.InnerException is the original exception; its StackTrace was printed
    // by SafeExecutor (errors 3-5) before wrapping.
    Console.Error.WriteLine($"Root cause: {rex.InnerException.GetType().Name}: {rex.InnerException.Message}");
}

When it happens

Trigger: Any unhandled exception during PeDependencyItem.LoadPe() (BinaryCache.LoadPe / GetImports / Mono.Cecil ReadAssembly) or ResolveDependencies() (Root.ResolveModule / cache lookups) that is not itself a RethrownException.

Common situations: A PE import table references a module whose resolution throws an unexpected error; BinaryCache returns a PE in a bad state; a null ModuleFilepath is dereferenced; Mono.Cecil throws something other than the caught BadImageFormatException.

Related errors

• - "{0:s}"
• [x] "Malformed" pe manifest for file {0:s} : {1:s}
• [x] Exception : {0:s}
• Stacktrace: {0:s}
• Modules backtrace:

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