| Previous | Next |
| ERROR_NO_UNICODE_TRANSLATION | ERROR_SHUTDOWN_IN_PROGRESS |
ERROR_DLL_INIT_FAILED
A dynamic link library (DLL) initialization routine failed.
ERROR_DLL_INIT_FAILED has decimal value 1114 (0x45A). Windows located and began loading a DLL, but initialization did not complete successfully. The important distinction is that this is not the same as a missing module: the loader reached an initialization stage and then rejected the DLL or unwound the load.
Where the result is usually reported
- a direct
LoadLibraryorLoadLibraryExcall returnsNULLafter the target DLL was discovered - process startup fails while resolving load-time dependencies before the application reaches its normal entry point
- a plug-in host, service, shell extension, or COM server loads a component whose startup code cannot finish
- the C/C++ runtime invokes global constructors before or around
DllMain, and one of those initialization paths fails or raises an exception
For a load-time dependency, the visible application may never start, so the only evidence can be the process exit status, loader diagnostics, Windows Error Reporting data, or a debugger break inside the failing module. For run-time loading, preserve the error immediately after the failed loader call; any cleanup API can overwrite the thread-local last-error value.
Likely causes to investigate
DllMainreturnedFALSEforDLL_PROCESS_ATTACH- initialization performed unsafe work while the loader lock was held, such as waiting for another thread that also needed the loader
- a dependent DLL was present but failed in its own initialization path
- static constructors accessed missing configuration, unavailable devices, incompatible runtime state, or damaged data
- security software, mitigation policy, or an injected module altered the expected load sequence
Do not diagnose this code by checking only whether the named DLL exists. A dependency walker can prove that files are present and still miss a failure caused by process-attach logic, TLS callbacks, runtime constructors, or a nested load.
Diagnostic sequence
- record the full DLL path, caller process architecture, process command line, and whether the load was implicit or explicit
- enable loader snaps or attach a debugger and break on module load, first-chance exceptions, and process termination
- inspect the dependency chain for architecture mismatches and unexpected copies selected by the DLL search order
- identify the last module whose process-attach code ran and inspect its
DllMain, TLS callbacks, and global constructors - repeat with nonessential plug-ins, injectors, and security hooks disabled only in a controlled test environment
A useful log entry includes the requested module name, resolved path, loader API, numeric code 1114, process bitness, and the module load sequence immediately before failure. If the DLL is maintained in-house, add explicit initialization outside DllMain so failures can return a component-specific reason rather than collapsing into this generic loader code.
Handling and recovery
Retrying the same load in the same process is rarely a sound recovery strategy because partial process-wide initialization may already have occurred. Prefer terminating the affected worker cleanly, correcting the component or environment, and starting a fresh process. A host that can isolate untrusted plug-ins should load them out of process so one initialization failure does not corrupt the main service state.
Developers should keep DllMain minimal, avoid synchronization with threads that may touch the loader, and move fallible setup into an ordinary exported function. Administrators should verify the exact binary path and version before reinstalling anything; replacing the wrong copy can hide the real search-order or side-by-side deployment problem.
How it differs from nearby loader errors
ERROR_MOD_NOT_FOUND and ERROR_DLL_NOT_FOUND indicate that a required module could not be located. ERROR_BAD_EXE_FORMAT points toward an invalid or incompatible image format. ERROR_DLL_INIT_FAILED instead says the loader got far enough to execute initialization and that phase failed.
Example
A service upgrade deploys a new plug-in DLL. The file and all imports are present, but its process-attach constructor opens a configuration database that has not yet been migrated and throws an exception. LoadLibraryEx returns NULL with 1114. The durable fix is to remove database access from loader-time code and report migration failure from an explicit plug-in initialization call.
References
- Microsoft: System Error Codes (1000–1299)
- Microsoft: DllMain entry point
- Microsoft: Dynamic-link library best practices
Looking for a different code? Search another status or error code.