What is 0xC0000142

STATUS_DLL_INIT_FAILED

Microsoft Windows operating system generates STATUS_DLL_INIT_FAILED (0xC0000142) error is entry point function of a dynamic link library (DLL) returns FALSE at receiving DLL_PROCESS_ATTACH notification. The reason why the initialization failed depends on the library and can be different. You can find it out by analyzing the logs (if such are kept and information about the initialization error gets into them) or by contacting the library manufacturer (author). If you are a developer and have the source code for this library, set a breakpoint on the DllMain function and look under the debugger to see what causes the error.

DllMain entry point

An optional entry point into a dynamic-link library (DLL). When the system starts or terminates a process or thread, it calls the entry-point function for each loaded DLL using the first thread of the process. The system also calls the entry-point function for a DLL when it is loaded or unloaded using the LoadLibrary and FreeLibrary functions.

Example

BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,  // handle to DLL module
    DWORD fdwReason,     // reason for calling function
    LPVOID lpReserved )  // reserved
{
    // Perform actions based on the reason for calling.
    switch( fdwReason ) 
    { 
        case DLL_PROCESS_ATTACH:
         // Initialize once for each new process.
         // Return FALSE to fail DLL load.
            break;

        case DLL_THREAD_ATTACH:
         // Do thread-specific initialization.
         // return FALSE will cause STATUS_DLL_INIT_FAILED (0xC0000142).
            break;

        case DLL_THREAD_DETACH:
         // Do thread-specific cleanup.
            break;

        case DLL_PROCESS_DETACH:
         // Perform any necessary cleanup.
            break;
    }
    return TRUE;  // Successful DLL_PROCESS_ATTACH.
}

Warning

There are significant limits on what you can safely do in a DLL entry point. See General Best Practices for specific Windows APIs that are unsafe to call in DllMain. If you need anything but the simplest initialization then do that in an initialization function for the DLL. You can require applications to call the initialization function after DllMain has run and before they call any other functions in the DLL.

Dynamic link library (DLL)

A dynamic library is not a static set of exported functions. This is a living organism, stuffed to the top with tricks and secrets with truly unlimited possibilities. Continuing the theme of the previous article, here we will talk about the mechanisms of automatic initialization / deinitialization, consider the DllMain function (some similarity to the main function – the start function of the C language) and discover one elegant way to share data between several processes.

All examples work perfectly in all versions of Windows and are “blessed” by Microsoft itself – use them without a shadow of fear. The compiler recommended by the author is Microsoft Visual C++, compatibility with the rest is not guaranteed (although it is assumed).

Suppose your DLL needs initialization and deinitialization functions. Special mention should be made about deinitialization – since, when a DLL is disabled, the memory allocated by it is not freed by itself, and open files are not closed, the “garbage clearance” has to be done by the DLL itself.

Doing this “manually” by calling a special function before disabling the DLL is tedious and unsafe (the programmer can forget to do this, causing a subtle resource leak error). It would be better if the initialization/deinitialization of the DLL would happen automatically each time it is connected/disconnected. And there really is such an opportunity!

If a DLL wants to be notified of the most important system events, it must have a special function (do not export it! just have it – the compiler will take care of the rest) – BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved), somewhat similar to main function of the C language. But the similarity is deceptive. The main function is called only once when the program is loaded, and DllMain receives control repeatedly and is more like a message fetch loop, but first things first.

Through DllMain, the system notifies the dynamic library of the following events:

1. projecting a DLL onto a process’s address space (connection);
2. disconnecting the DLL from the process address space (deallocation);
3. creation of a new thread by the connecting DLL process;
4. termination of the thread created by the process that connected the DLL

Each event has its own “own” value of the fdwReason argument passed to the DllMain function when it occurs.

DLL_PROCESS_ATTACH – With this value, DllMain is called whenever a process loads a DLL with explicit or implicit linking. Some popular writers, including such an indisputable authority as Jeffrey Richter in his monograph “Windows for Professionals”, argue that DLL_PROCESS_ATTACH is called only once for each process. It turns out that if the process frees the library by calling FreeLibrary, and then loads it again, the DllMain function will not be called? The question arises – how then to initialize the DLL when it is reconnected? Fortunately, no tricky tricks need to be invented – DLL_PROCESS_ATTACH is always called – no matter how many times the library is projected onto the process.

Note: Another thing is trying to reload already loaded (and not yet unloaded!) libraries. In this case, LoadLibrary simply returns the description of the specified DLL instance, naturally without calling the DllMain function. This is exactly what Richter wants to say, but, in any case, in the Russian translation, he expresses his thought very vaguely and ambiguously.

If initialization was successful, DllMain must return TRUE, otherwise FALSE, and a LoadLibrary call attempting to load the DLL will return an error STATUS_DLL_INIT_FAILED. and the process linking the DLL with implicit linking will crash.