| Previous | Next |
| STATUS_HIBERNATION_FAILURE | STATUS_AUTHENTICATION_FIREWALL_FAILED |
STATUS_DELAY_LOAD_FAILED
Delay loading moves dependency failure from process startup to the first call that touches the import
STATUS_DELAY_LOAD_FAILED is tied to the delay-load mechanism. With /DELAYLOAD, a DLL is not necessarily loaded during normal process startup; helper code resolves the module and imports when the application first calls a delayed function. A process can therefore start successfully and fail much later on a feature path that activates the delayed dependency.
Microsoft documents delay-load failure handling around missing modules and missing procedures, and provides __HrLoadAllImportsForDll to force resolution of all delayed imports for a named DLL. Use that behavior to reproduce the failure early and identify whether the module search, API-set redirection, or a specific exported procedure is the failing step.
Capture the delay-load notification/failure information and the original exception or nested loader error. A generic catch block that reports only “feature failed” discards the dependency name and import identity. Avoid copying a DLL next to the executable until the actual resolved search path and version contract are known.
What to inspect
- The delayed DLL name, requested import, first call site that triggered resolution, and nested loader error.
- Linker delay-load configuration, helper hooks, failure hooks, and whether all imports fail or only one symbol.
- The effective DLL search and API-set resolution context of the failing process.
References
- Microsoft: Linker support for delay-loaded DLLs
- Microsoft: GetProcAddress
- Microsoft: API set loader operation
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.