| Previous | Next |
| STATUS_THREADPOOL_RELEASE_MUTEX_ON_COMPLETION_FAILED | STATUS_THREADPOOL_RELEASED_DURING_OPERATION |
STATUS_THREADPOOL_FREE_LIBRARY_ON_COMPLETION_FAILED
Deferred DLL release failed after the callback returned
FreeLibraryWhenCallbackReturns defers decrementing a module reference until execution has left callback code. This prevents unloading the DLL while its callback is still running. Failure indicates that the saved module handle or reference-counting lifecycle was not valid at finalization time.
The remedy is not to call FreeLibrary blindly again. First determine whether the module reference was acquired, whether another path released it, and whether pending callbacks can still enter code in that DLL. Incorrect unloading can cause instruction-pointer use after unload.
What to inspect
- Capture module path, module handle, reference acquisition point, callback object, and shutdown ordering.
- Cancel or drain pending callbacks before allowing the containing DLL to unload.
- Pair each explicit module reference with one clearly owned deferred or direct release.
- Use
SetThreadpoolCallbackLibrarywhen callback code can race with DLL teardown.
References
- Microsoft Open Specifications: NTSTATUS values
- Microsoft: FreeLibraryWhenCallbackReturns
- Microsoft: SetThreadpoolCallbackLibrary
- Microsoft: DisassociateCurrentThreadFromCallback
Looking for a different code? Search another status or error code.
