dotnet/runtime · critical

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

Error message

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

What it means

Printed by the corerun host immediately before dumping diagnostics when the CoreCLR runtime fails to initialize via coreclr_initialize. The HRESULT (0x%08x) identifies the specific failure (e.g. missing coreclr.dll, bad property, incompatible runtime). The BEGIN/END pair brackets the logger.dump_details() output so the user can find the detailed trace.

Solutions

  1. Check that CORE_ROOT or --clr-path points to a complete runtime layout containing both coreclr.dll/libcoreclr.so and the System.* managed assemblies.
  2. Decode the printed HRESULT (e.g. 0x8007000b = ERROR_BAD_FORMAT, 0x80131700 = runtime init) using the HRESULT table in docs to find the root cause.
  3. Re-run with the runtime's matching corerun binary (same bitness/architecture as the runtime).
  4. If passing -p properties, verify TRUSTED_PLATFORM_ASSEMBLIES and APP_PATHS are correct and that every listed file exists.

Example fix

// before
corerun -c /opt/wrong-runtime My.dll
// after
corerun -c /opt/dotnet-shared/Microsoft.NETCore.App/8.0.0 My.dll
Defensive patterns

Strategy: validation

Validate before calling

// Before invoking corerun, verify the runtime layout
#include <filesystem>
namespace fs = std::filesystem;
bool runtime_ok(const fs::path& clr_path) {
    return fs::exists(clr_path / "coreclr.dll")  // or libcoreclr.so/.dylib
        && fs::exists(clr_path / "System.Private.CoreLib.dll");
}
if (!runtime_ok(config.clr_path)) { return report_error("bad CORE_ROOT"); }

Prevention

When it happens

Trigger: Emitted at src/coreclr/hosts/corerun/corerun.cpp:615 when coreclr_init_func (the resolved coreclr_initialize export) returns a FAILED HRESULT. This happens if libcoreclr cannot be located via --clr-path/CORE_ROOT, the runtime binary is the wrong architecture, a TRUSTED_PLATFORM_ASSEMBLIES property is missing/malformed, or the runtime version mismatches the target assembly.

Common situations: Running corerun against a mismatched or partial CORE_ROOT (e.g. only coreclr.dll copied without the managed CLR assemblies), pointing --clr-path at a 32-bit runtime while executing a 64-bit corerun, passing a System.Runtime properties bag that omits required keys like TRUSTED_PLATFORM_ASSEMBLIES, or after a SDK/runtime upgrade that left stale paths.

Related errors


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

Appendix: source

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

    }

#ifdef TARGET_WASM
    // install the pinvoke override callback to resolve p/invokes to statically linked libraries
    add_pinvoke_override();
#endif // TARGET_WASM

    int result;
    result = coreclr_init_func(
        exe_path_utf8.c_str(),
        "corerun",
        propertyCount,
        propertyKeys.data(),
        propertyValues.data(),
        &CurrentClrInstance,
        &CurrentAppDomainId);
    if (FAILED(result))
    {
        pal::fprintf(stderr, W("BEGIN: coreclr_initialize failed - Error: 0x%08x\n"), result);
        logger.dump_details();
        pal::fprintf(stderr, W("END: coreclr_initialize failed - Error: 0x%08x\n"), result);
        return -1;
    }

    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,

View on GitHub (pinned to 60108ba66e)