dotnet/runtime · critical

BEGIN: coreclr_execute_assembly failed - Error: 0x%08x

Error message

BEGIN: coreclr_execute_assembly failed - Error: 0x%08x

What it means

Opening marker printed when coreclr_execute_assembly() returns a failing HRESULT inside run(). It brackets the logger.dump_details() output before the END line at 641. By this point CoreCLR initialized successfully; the failure is in loading/running the entry assembly itself (e.g. missing dependency, bad image, unhandled managed exception at startup).

Source

Thrown at src/coreclr/hosts/corerun/corerun.cpp:639

    if (coreclr_set_error_writer_func != nullptr)
    {
        coreclr_set_error_writer_func(nullptr);
    }

    int exit_code;
    {
        actions.before_execute_assembly(config.entry_assembly_fullpath);

        result = coreclr_execute_func(
            CurrentClrInstance,
            CurrentAppDomainId,
            config.entry_assembly_argc,
            argv_utf8.get(),
            entry_assembly_utf8.c_str(),
            (uint32_t*)&exit_code);
        if (FAILED(result))
        {
            pal::fprintf(stderr, W("BEGIN: coreclr_execute_assembly failed - Error: 0x%08x\n"), result);
            logger.dump_details();
            pal::fprintf(stderr, W("END: coreclr_execute_assembly failed - Error: 0x%08x\n"), result);
            return -1;
        }

        actions.after_execute_assembly();
    }

#ifdef TARGET_BROWSER
    // in NodeJS/Browser this is not really end of the process, JS keeps running.
    // We want to keep the CoreCLR runtime alive to be able to process async work
    // The NodeJS process is kept alive by pending async work via safeSetTimeout() -> runtimeKeepalivePush()
    // The actual exit code would be set by SystemJS_ResolveMainPromise if the managed Main() is async.
    // Or in Module.onExit handler when  managed Main() is synchronous.
    return exit_code;
#else // TARGET_BROWSER
    int final_exit_code = corerun_shutdown(exit_code);
#ifdef TARGET_WASI

View on GitHub (pinned to 290d5ab72c)

Solutions

  1. Decode the HRESULT (e.g. 0x80070002 missing file, 0x80131522 BadImageFormat).
  2. Inspect the dumped 'Managed assembly' and 'APP_PATHS'/'NATIVE_DLL_SEARCH_DIRECTORIES' to confirm dependencies resolve.
  3. Ensure all referenced assemblies are either on the TPA list, in the app directory, or resolvable via the external assembly probe.
  4. Rebuild the entry assembly against the same .NET target framework the loaded CoreCLR provides.
  5. If using APP_ASSEMBLIES=EXTERNAL, verify the external_assembly_probe callbacks can find the file under s_core_libs_path / s_core_root_path.

Example fix

# before: dependency not on the TPA list
corerun App.dll  # App references Newtonsoft.Json.dll not in CORE_ROOT
# after: add the lib dir to native search / TPA
export CORE_LIBRARIES=/app/libs
corerun App.dll
Defensive patterns

Strategy: validation

Validate before calling

# before running, verify the entry assembly and its obvious deps exist
test -f "$ASSEMBLY" || { echo "missing entry assembly: $ASSEMBLY"; exit 1; }
# list referenced assemblies and check they resolve against CORE_ROOT/CORE_LIBRARIES
for d in $(dirname "$ASSEMBLY") "$CORE_ROOT" "${CORE_LIBRARIES:-}"; do
  [ -n "$d" ] && [ -d "$d" ] && echo "probe dir: $d"
done

Prevention

When it happens

Trigger: coreclr_execute_func() is called with CurrentClrInstance, CurrentAppDomainId, argc, argv (UTF-8), entry_assembly path. It fails — common causes: assembly not found, FileLoadException-level failures, BadImageFormatException, missing dependency on the TPA list / APP_PATHS, or a security/CLR policy rejection.

Common situations: Entry assembly references a DLL not present in TRUSTED_PLATFORM_ASSEMBLIES or APP_PATHS; assembly compiled against a different target framework; mixed 32/64 bit assembly loaded into a runtime of the wrong bitness; corrupted PE file.

Related errors

AI-assisted analysis of dotnet/runtime@290d5ab72c (2026-08-06). Data as JSON: /api/errors/fcb96bfebc5f370a. Report an issue: GitHub.