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
- Verify CORE_ROOT / --clr-path points to a complete, matching-architecture CoreCLR build that contains coreclr.dll/libcoreclr.so/libcoreclr.dylib.
- Reinstall or rebuild the .NET runtime so corerun and coreclr come from the same commit/build.
- 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.
- 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
- Always source corerun and coreclr from the same build/install.
- Pin CORE_ROOT to a runtime version directory that matches the corerun binary.
- Verify architecture (x64/arm64/x86) matches between corerun and coreclr.
- Add a CI step that runs 'nm -D / dumpbin /exports' to assert the three required exports exist.
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
- BEGIN: coreclr_initialize failed - Error: 0x%08x
- END: coreclr_initialize failed - Error: 0x%08x
- BEGIN: coreclr_execute_assembly failed - Error: 0x%08x
- END: coreclr_execute_assembly failed - Error: 0x%08x
- coreclr_shutdown_2 failed - Error: 0x%08x
AI-assisted analysis of dotnet/runtime@290d5ab72c (2026-08-06).
Data as JSON: /api/errors/32e92bb822cbcf0f.
Report an issue: GitHub.