dotnet/runtime · critical

Export '%s' not found.

Error message

Export '%s' not found.

What it means

Printed by try_get_export() when pal::get_module_symbol() returns NULL for a required CoreCLR export symbol (e.g. 'coreclr_initialize', 'coreclr_execute_assembly', 'coreclr_shutdown_2'). It means the loaded coreclr dynamic library does not expose the symbol the host expects. This is almost always a version skew between the corerun host binary and the coreclr library it loaded.

Source

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

    if (*fptr != nullptr)
        return true;
#else // !TARGET_WASM
    if (!strcmp(symbol, "coreclr_initialize")){
        *fptr = (void*)coreclr_initialize;
        return true;
    } else if (!strcmp(symbol, "coreclr_execute_assembly")){
        *fptr = (void*)coreclr_execute_assembly;
        return true;
    } else if (!strcmp(symbol, "coreclr_shutdown_2")){
        *fptr = (void*)coreclr_shutdown_2;
        return true;
    } else if (!strcmp(symbol, "coreclr_set_error_writer")){
        *fptr = (void*)coreclr_set_error_writer;
        return true;
    }
#endif // !TARGET_WASM

    pal::fprintf(stderr, W("Export '%s' not found.\n"), symbol);
    return false;
}

class logger_t final
{
    const char* _exePath;
    int _propertyCount;
    const char** _propertyKeys;
    const char** _propertyValues;
    const char* _managedAssembly;
    int _argc;
    const char** _argv;
public:
    logger_t(
        const char* exePath,
        int propertyCount, const char** propertyKeys, const char** propertyValues,
        const char* managedAssembly, int argc, const char** argv)
    : _exePath{ exePath }

View on GitHub (pinned to 290d5ab72c)

Solutions

  1. Verify CORE_ROOT / --clr-path points to a complete, matching-architecture CoreCLR build that contains coreclr.dll/libcoreclr.so/libcoreclr.dylib.
  2. Reinstall or rebuild the .NET runtime so corerun and coreclr come from the same commit/build.
  3. Inspect the loaded library's exports (dumpbin /exports, nm -D, objdump -T) to confirm 'coreclr_initialize', 'coreclr_execute_assembly', and 'coreclr_shutdown_2' are present.
  4. On WASM, ensure only the four supported exports are requested and that the pinvoke-override path is taken for statically linked libraries.

Example fix

# before: CORE_ROOT points at a mismatched/incomplete build
export CORE_ROOT=/opt/dotnet/old/lib
corerun App.dll
# after: point at the matching runtime that ships corerun
corerun -c /path/to/matching/coreclr/lib App.dll
Defensive patterns

Strategy: validation

Validate before calling

# before invoking corerun, confirm the coreclr lib exports the required symbols
LIB="$CORE_ROOT/libcoreclr.so"   # coreclr.dll on Windows, libcoreclr.dylib on macOS
if command -v nm >/dev/null; then
  for sym in coreclr_initialize coreclr_execute_assembly coreclr_shutdown_2; do
    nm -D "$LIB" | grep -q " $sym" || echo "MISSING: $sym in $LIB"
  done
fi

Prevention

When it happens

Trigger: corerun successfully calls pal::try_load_coreclr() (so a coreclr .dll/.so/.dylib was found and dlopen/LoadLibrary succeeded), but the subsequent pal::get_module_symbol(mod, "coreclr_initialize") (or execute/shutdown) returns nullptr. On TARGET_WASM it fires for any symbol other than the four hardcoded ones.

Common situations: Pointing --clr-path (or CORE_ROOT) at a coreclr library from a different .NET build/architecture; a stripped or partial coreclr build that did not export the host API; a corrupted install; running a 32-bit corerun against a 64-bit coreclr or vice versa.

Related errors


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