dotnet/runtime · critical

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

Error message

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

What it means

Closing marker at src/coreclr/hosts/corerun/corerun.cpp:641 for the coreclr_execute_assembly failure block. Brackets the logger.dump_details() output for the execute failure; the function then returns -1. Same HRESULT as 242.

Solutions

  1. Capture and analyze the full BEGIN..END block together with error 242.
  2. Apply the same assembly/runtime fixes described for error 242.
  3. If the dump between markers is empty, run a checked/debug runtime build for richer detail.
Defensive patterns

Strategy: validation

Prevention

When it happens

Trigger: Always emitted alongside error 242. It exists to delimit the diagnostic dump; the trigger is the same failed coreclr_execute_func call.

Common situations: Appears in logs immediately after 242 with the diagnostic detail in between. Used by log scrapers to find the start and end of the failure block.

Related errors

AI-assisted analysis of dotnet/runtime@60108ba66e (2026-08-10). Data as JSON: /api/errors/d973d62c470b54f0. Report an issue: GitHub.

Appendix: source

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

        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
    // wasi:cli/exit's stable exit() only signals ok/err, so wasmtime
    // collapses any non-zero Main return to host exit 1. When

View on GitHub (pinned to 60108ba66e)