desktop-src/SecCrypto/installing-the-new-functionality.md:13:[**CryptInstallOIDFunctionAddress**](/windows/desktop/api/Wincrypt/nf-wincrypt-cryptinstalloidfunctionaddress) installs the address of the new functionality. It should be placed in the **DllMain** function of the DLL.
desktop-src/SecCrypto/installing-the-new-functionality.md:39:BOOL WINAPI DllMain(
desktop-src/SecBioMet/creating-an-engine-adapter.md:289:DllMain( 
desktop-src/SecBioMet/creating-a-sensor-adapter.md:218:DllMain( 
desktop-src/SecBioMet/creating-a-storage-adapter.md:252:DllMain( 
desktop-src/winmsg/about-window-classes.md:169:The system passes an instance handle to the entry-point function of each executable (see [**WinMain**](/windows/win32/api/winbase/nf-winbase-winmain)) and .dll (see [**DllMain**](/windows/desktop/Dlls/dllmain)). The executable or .dll assigns this instance handle to the class by copying it to the **hInstance** member of the [**WNDCLASSEX**](/windows/win32/api/winuser/ns-winuser-wndclassexa) structure.
desktop-src/NetMon2/createprotocol.md:68:The parser DLL calls **CreateProtocol** during its implementation of [DllMain](dllmain-parser.md). The **CreateProtocol** function is called when the operating system loads the parser DLL for the first time.
desktop-src/NetMon2/createprotocol.md:83:| How to implement **DllMain** includes an example of calling **CreateProtocol** within **DllMain**. | [Implementing DllMain](implementing-dllmain-parser.md) |
desktop-src/NetMon2/createprotocol.md:107:[DllMain](/windows/desktop/Dlls/dllmain)
desktop-src/NetMon2/dllmain-parser.md:2:description: The DllMain export function for the parser identifies the existence of the parser, and releases resources that Network Monitor uses for the parser. DllMain must be implemented in all parser DLLs.
desktop-src/NetMon2/dllmain-parser.md:4:title: DllMain Parser callback function (Process.h)
desktop-src/NetMon2/dllmain-parser.md:11:- DllMain
desktop-src/NetMon2/dllmain-parser.md:18:# DllMain Parser callback function
desktop-src/NetMon2/dllmain-parser.md:20:The **DllMain** export function for the parser identifies the existence of the parser, and releases resources that Network Monitor uses for the parser. **DllMain** must be implemented in all parser DLLs.
desktop-src/NetMon2/dllmain-parser.md:26:BOOL WINAPI DllMain(
desktop-src/NetMon2/dllmain-parser.md:49:Indicator to determine why the function is called. For a list of all possible flags, see [DllMain](/windows/desktop/Dlls/dllmain). The parser implementation must process the following values.
desktop-src/NetMon2/dllmain-parser.md:55:| <span id="DLL_PROCESS_ATTACH"></span><span id="dll_process_attach"></span><dl> <dt>**DLL\_PROCESS\_ATTACH**</dt> </dl> | When **DllMain** is called for the first time, the DLL must call [CreateProtocol](createprotocol.md) to provide information to Network Monitor. <br/>   |
desktop-src/NetMon2/dllmain-parser.md:56:| <span id="DLL_PROCESS_DETACH"></span><span id="dll_process_detach"></span><dl> <dt>**DLL\_PROCESS\_DETACH**</dt> </dl> | When **DllMain** is called for the last time, the DLL must call [DestroyProtocol](destroyprotocol.md) to release the resources that the DLL uses. <br/> |
desktop-src/NetMon2/dllmain-parser.md:77:The operating system calls **DllMain** to load and unload the parser DLL. This function is based on the dynamic-link library [DllMain](/windows/desktop/Dlls/dllmain) function.
desktop-src/NetMon2/dllmain-parser.md:79:You can also use the implementation of **DllMain** to store an instance of a parser for use in the future. For example, you can store a parser DLL instance, and then use it for a system call in the future.
desktop-src/NetMon2/dllmain-parser.md:87:| How to implement **DllMain**  includes an example.        | [Implementing DllMain](implementing-dllmain-parser.md) |
desktop-src/NetMon2/dllmain-parser.md:115:[DllMain](/windows/desktop/Dlls/dllmain)
desktop-src/NetMon2/entrypoints.md:87:| How to implement **DllMain**  includes an example.        | [Implementing DllMain](implementing-dllmain-parser.md) |
desktop-src/NetMon2/implementing-dllmain-parser.md:2:description: Network Monitor uses the DllMain export function to identify the existence of the parser, and release resources that Network Monitor uses to store information about the parser.
desktop-src/NetMon2/implementing-dllmain-parser.md:4:title: Implementing DllMain Parser
desktop-src/NetMon2/implementing-dllmain-parser.md:9:# Implementing DllMain Parser
desktop-src/NetMon2/implementing-dllmain-parser.md:11:Network Monitor uses the **DllMain** export function to identify the existence of the parser, and release resources that Network Monitor uses to store information about the parser.
desktop-src/NetMon2/implementing-dllmain-parser.md:13:When Network Monitor calls **DllMain** for the first time, the parser DLL calls [**CreateProtocol**](createprotocol.md) to do the following:
desktop-src/NetMon2/implementing-dllmain-parser.md:18:When Network Monitor calls **DllMain** for the last time, **DllMain** calls [**DestroyProtocol**](destroyprotocol.md) to release all resources that Network Monitor uses to store information about the parser.
desktop-src/NetMon2/implementing-dllmain-parser.md:20:The following procedure identifies the steps necessary to implement **DllMain**.
desktop-src/NetMon2/implementing-dllmain-parser.md:22:**To implement DllMain**
desktop-src/NetMon2/implementing-dllmain-parser.md:37:3.  Return **TRUE** because the **DllMain** parser function must always return **TRUE**.
desktop-src/NetMon2/implementing-dllmain-parser.md:39:The following is a basic implementation of **DllMain**. The code example uses a case statement to trap values of the *Command* parameter to determine if [**CreateProtocol**](createprotocol.md) or [**DestroyProtocol**](destroyprotocol.md) should be called.
desktop-src/NetMon2/implementing-dllmain-parser.md:57:BOOL WINAPI DllMain(HANDLE hInstance, ULONG Command, LPVOID Reserved)
desktop-src/NetMon2/experts.md:28:When you start Network Monitor, the [**DllMain**](dllmain-expert.md) function builds all experts in the experts subdirectory. When the user selects **Experts** on the **Tools** menu of the Network Monitor UI, Network Monitor loads the expert DLLs. The expert is called through the [Register Expert](register-expert.md) entry point to provide basic details about the expert.
desktop-src/NetMon2/experts.md:34:-   [**DllMain**](dllmain-expert.md)
desktop-src/NetMon2/parser-dll-export-functions.md:17:| [DllMain Parser](dllmain-parser.md)               | Indicates to the parser DLL that it is loaded or unloaded. The operating system calls the **DllMain Parser** function when a process loads or unloads the DLL. |
desktop-src/NetMon2/implementing-parser-export-functions.md:2:description: The parser export functions provide all the functionality of the parsers in the parser DLL. Each parser DLL must implement ParserAutoInstallInfo and DllMain. The remaining export functions must be implemented for each parser included in the parser DLL.
desktop-src/NetMon2/implementing-parser-export-functions.md:11:The parser export functions provide all the functionality of the parsers in the parser DLL. Each parser DLL must implement [**ParserAutoInstallInfo**](parserautoinstallinfo.md) and [**DllMain**](dllmain-parser.md). The remaining export functions must be implemented for each parser included in the parser DLL.
desktop-src/NetMon2/implementing-parser-export-functions.md:20:| <span id="Implementing_DllMain_Parser"></span><span id="implementing_dllmain_parser"></span><span id="IMPLEMENTING_DLLMAIN_PARSER"></span>[Implementing DllMain Parser](implementing-dllmain-parser.md)<br/>                                    | Provides a description and code example of implementing the [**DllMain Parser**](dllmain-parser.md) function, which identifies the existence of a parser, and then releases resources that Network Monitor uses for the parser.<br/>                                              |
desktop-src/NetMon2/programming-an-expert.md:21:| [**DllMain**](dllmain-expert.md)                    | DLL entry function | Yes                                             |
desktop-src/NetMon2/dllmain-expert.md:2:description: The expert implements the DllMain function. The operating system calls DllMain to obtain a handle to an instance of the expert.
desktop-src/NetMon2/dllmain-expert.md:4:title: DllMain Expert callback function (Process.h)
desktop-src/NetMon2/dllmain-expert.md:11:- DllMain
desktop-src/NetMon2/dllmain-expert.md:18:# DllMain Expert callback function
desktop-src/NetMon2/dllmain-expert.md:20:The expert implements the [**DllMain**](/windows/desktop/Dlls/dllmain) function. The operating system calls **DllMain** to obtain a handle to an instance of the expert.
desktop-src/NetMon2/dllmain-expert.md:26:BOOL WINAPI DllMain(
desktop-src/NetMon2/dllmain-expert.md:53:With any other value, all calls to the [**DllMain**](/windows/desktop/Dlls/dllmain) function can be ignored. For a list of all possible flags set by the operating system, see **DLLMain**.
desktop-src/NetMon2/dllmain-expert.md:72:The operating system calls the **DllMain** expert function when a process loads or unloads the expert DLL. The **DllMain** expert function must be exported only if the expert has a user interface for viewing either configuration or results, and then only to return the proper *hInstance* value.
desktop-src/NetMon2/dllmain-expert.md:74:The **DllMain** expert function is based on the dynamic link library [**DllMain**](/windows/desktop/Dlls/dllmain) function.
desktop-src/NetMon2/toc.yml:140:        - name: "Implementing DllMain Parser"
desktop-src/NetMon2/toc.yml:141:          href: implementing-dllmain-parser.md
desktop-src/NetMon2/toc.yml:251:        - name: "DllMain Expert"
desktop-src/NetMon2/toc.yml:252:          href: dllmain-expert.md
desktop-src/NetMon2/toc.yml:318:        - name: "DllMain Parser"
desktop-src/NetMon2/toc.yml:319:          href: dllmain-parser.md
desktop-src/NetMon2/expert-dll-export-functions.md:17:| [**DllMain Expert**](dllmain-expert.md)   | Indicates that the expert DLL has been loaded or unloaded. When a process loads or unloads the DLL, the operating system calls the [**DllMain**](/windows/desktop/Dlls/dllmain) function. |
desktop-src/NetMon2/destroyprotocol.md:50:The parser DLL calls the **DestroyProtocol** function during its implementation of [DllMain](dllmain-parser.md). **DestroyProtocol** is called when the operating system is going to unload the DLL.
desktop-src/NetMon2/destroyprotocol.md:57:| How to implement **DllMain** includes an example.         | [Implementing DllMain](implementing-dllmain-parser.md) |
desktop-src/NetMon2/destroyprotocol.md:81:[DllMain](dllmain-parser.md)
desktop-src/ADSI/libmain-cpp.md:22:| **DllMain**<br/>                | Entry point for most Windows 2000 or Windows NT versions.<br/>     |
desktop-src/Midl/c-compiler-definitions-for-proxy-stubs.md:19:| REGISTER\_PROXY\_DLL                                                                                                                                                                            | Generates **DllMain**, **DllRegisterServer**, and **DllUnregisterServer** functions for automatically registering a proxy DLL.                                                                                       |
desktop-src/Midl/c-compiler-definitions-for-proxy-stubs.md:27:By defining the **REGISTER\_PROXY\_DLL** macro when compiling Dlldata.c, your proxy/stub marshaling DLL will automatically include default definitions for the **DllMain**, **DllRegisterServer**, and **DllUnregisterServer** functions. You can use these functions to self-register your proxy DLL in the system registry.
desktop-src/Midl/c-compiler-definitions-for-proxy-stubs.md:31:Use the **PROXY\_CLSID**=&lt;clsid&gt; macro when you want to explicitly specify the proxy/stub server's CLSID rather than rely on the default CLSID. For example, if you are building a standard marshaling DLL as your own in-process COM server, or if you need to define your own **DllMain** to handle DLL\_PROCESS\_ATTACH.
desktop-src/direct3ddxgi/d3d10-graphics-programming-guide-dxgi.md:36:-   [DXGI Responses from DLLMain](#dxgi-responses-from-dllmain)
desktop-src/direct3ddxgi/d3d10-graphics-programming-guide-dxgi.md:284:## DXGI responses from DLLMain
desktop-src/direct3ddxgi/d3d10-graphics-programming-guide-dxgi.md:286:Because a [**DllMain**](../dlls/dllmain.md) function can't guarantee the order in which it loads and unloads DLLs, we recommend that your app's **DllMain** function not call Direct3D or DXGI functions or methods, including functions or methods that create or release objects. If your app's **DllMain** function calls into a particular component, that component might call another DLL that isn't present on the operating system, which causes the operating system to crash. Direct3D and DXGI might load a set of DLLs, typically a set of drivers, that differs from computer to computer. Therefore, even if your app doesn t crash on your development and test computers when its **DllMain** function calls Direct3D or DXGI functions or methods, it might crash when it runs on another computer.
desktop-src/direct3ddxgi/d3d10-graphics-programming-guide-dxgi.md:290:-   If your app's [**DllMain**](../dlls/dllmain.md) function releases its last reference to a DXGI factory, DXGI raises an exception.
desktop-src/direct3ddxgi/d3d10-graphics-programming-guide-dxgi.md:291:-   If your app's [**DllMain**](../dlls/dllmain.md) function creates a DXGI factory, DXGI returns an error code.
desktop-src/ETW/configuring-and-starting-a-private-logger-session.md:15:Note that you cannot start, stop, or flush a private trace session from DllMain; you should do so in the initialization and finalization routines of the DLL.
desktop-src/DirectShow/building-directshow-filters.md:25:    DllMain             PRIVATE
desktop-src/DirectShow/building-directshow-filters.md:44:BOOL APIENTRY DllMain(HANDLE hModule, DWORD dwReason, LPVOID lpReserved)
desktop-src/DirectShow/dll-functions.md:18:-   [*DllMain*](/windows/desktop/Dlls/dllmain): The DLL entry point. The name *DllMain* is a placeholder for the library-defined function name. The DirectShow implementation uses the name **DllEntryPoint**. For more information, see the Platform SDK.
desktop-src/DirectShow/dll-functions.md:24:Of these, the first three are implemented by DirectShow. If your factory template provides an initialization function in the [**m\_lpfnInit**](cfactorytemplate-m-lpfninit.md) member variable, that function is called from inside the DLL entry-point function. For more information on when the system calls the DLL entry-point function, see [*DllMain*](/windows/desktop/Dlls/dllmain).
desktop-src/search/implementing-a-word-breaker-and-stemmer.md:32:-   DllMain is the standard entry point to DLL.
desktop-src/search/-search-3x-wds-extidx-filters.md:37:-   Do not allocate or free resources in the DllMain entry point. This can lead to failures during low-resource stress tests.
desktop-src/Debug/calling-the-dbghelp-library.md:53:        // ghinst is the HINSTANCE of this module, initialized in DllMain or WinMain
desktop-src/printdocs/addprinter.md:70:Do not call this method in [**DllMain**](/windows/desktop/Dlls/dllmain).
desktop-src/printdocs/openprinter.md:80:Do not call this method in [**DllMain**](/windows/desktop/Dlls/dllmain).
desktop-src/printdocs/openprinter2.md:82:Do not call this method in [**DllMain**](/windows/desktop/Dlls/dllmain).
desktop-src/printdocs/enumprinters.md:144:Do not call this method in [**DllMain**](/windows/desktop/Dlls/dllmain).
desktop-src/WinInet/internetgetproxyinfo.md:117:Like all other aspects of the WinINet API, this function can't be safely called from within **DllMain** or the constructors and destructors of global objects.
desktop-src/WinInet/cleanupcredentialcache.md:54:Like all other aspects of the WinINet API, this function cannot be safely called from within DllMain or the constructors and destructors of global objects.
desktop-src/Win7AppQual/preventing-hangs-in-windows-applications.md:111:Worse yet, the operating system has its own internal process-specific lock that sometimes is held while your code executes. This lock is acquired when DLLs are loaded into the process, and is therefore called the 'loader lock.' The DllMain function always executes under the loader lock; if you acquire any locks in DllMain (and you should not), you need to make the loader lock part of your lock order. Calling certain Win32 APIs might also acquire the loader lock on your behalf - functions like LoadLibraryEx, GetModuleHandle, and especially CoCreateInstance.
desktop-src/Win7AppQual/preventing-hangs-in-windows-applications.md:113:To tie all of this together, look at the sample code below. This function acquires multiple synchronization objects and implicitly defines a lock order, something that is not necessarily obvious on cursory inspection. On function entry, the code acquires a Critical Section and does not release it until function exit, thereby making it the top node in our lock hierarchy. The code then calls the Win32 function LoadIcon(), which under the covers might call into the Operating System Loader to load this binary. This operation would acquire the loader lock, which now also becomes part of this lock hierarchy (make sure the DllMain function does not acquire the g\_cs lock). Next the code calls SendMessage(), a blocking cross-thread operation, which will not return unless the UI thread responds. Again, make sure that the UI thread never acquires g\_cs.
desktop-src/Win7AppQual/preventing-hangs-in-windows-applications.md:132:-   Design a lock hierarchy and obey it. Add all the necessary locks. There are many more synchronization primitives than just Mutex and CriticalSections; they all need to be included. Include the loader lock in your hierarchy if you take any locks in DllMain()
desktop-src/Win7AppQual/preventing-hangs-in-windows-applications.md:142:-   Do anything other than very simple initialization work in your DllMain() function. See DllMain Callback Function for more details. Especially do not call LoadLibraryEx or CoCreateInstance
desktop-src/Win7AppQual/preventing-hangs-in-windows-applications.md:188:-   [**DllMain Callback Function**](../dlls/dllmain.md)
desktop-src/SbsCs/searching-for-assembly-files.md:17:If a DLL is loaded in this manner using [**LoadLibrary**](/windows/desktop/api/libloaderapi/nf-libloaderapi-loadlibrarya), that DLL's entry point (DllMain) is called while the original activation context is kept active, except if the DLL itself contains a manifest at a certain resource ID (ISOLATIONAWARE\_MANIFEST\_RESOURCE\_ID, or 2)
desktop-src/SbsCs/using-side-by-side-assemblies-as-a-resource.md:31:MANIFEST\_RESOURCE\_ID 2 should be used for applications that host third-party controls or plug-ins. In this case, the manifest affects all side-by-side assemblies being loaded by static loading, calls to DllMain, and calls redirected by -DISOLATION\_AWARE\_ENABLED. For more information, see [Enabling an Assembly in an Application Hosting a DLL, Extension, or Control Panel](enabling-an-assembly-in-an-application-hosting-a-dll-extension-or-control-panel.md).
desktop-src/tracelogging/tracelogging-native-quick-start.md:121:to register your provider handle. This is typically done in main() or DLLMain()
desktop-src/shell/band-objects.md:238:-   [**DllMain**](../dlls/dllmain.md)
desktop-src/shell/int-shell-exts.md:15:-   [**DllMain**](../dlls/dllmain.md). The standard entry point to the DLL.
desktop-src/shell/handlers.md:69:-   [**DllMain**](../dlls/dllmain.md). The standard entry point to the DLL.
desktop-src/WmiSdk/unloading-a-provider.md:75:The user may stop WMI at any time. In such a situation, WMI does not unload any providers or call the [**DllCanUnloadNow**](/windows/win32/api/combaseapi/nf-combaseapi-dllcanunloadnow) entry point on any in-process provider. Moreover, if an in-process provider is in the middle of a method call at the time of the shutdown, WMI can possibly terminate the executing thread in the middle of the call. In this circumstance, WMI does not call routines that normally handle cleanup, such as an object destructor. At most, WMI will call [**DllMain**](/windows/desktop/Dlls/dllmain) only.
desktop-src/WmiSdk/unloading-a-provider.md:85:If you must place cleanup code in your provider, you have two options. One place to perform this sort of cleanup is [**DllMain**](/windows/desktop/Dlls/dllmain), the DLL entry point function the operating system calls when unloading the DLL. Cleanup code can be added directly into **DllMain**, executing it in response to **DLL\_PROCESS\_DETACH**. Implementing cleanup code in **DllMain** can be somewhat difficult to arrange, especially in programming environments such as MFC or ATL. For more information, see the Microsoft Knowledge Base article Q148791, "*How to Provide Your Own DllMain in an MFC Regular DLL.*" (This resource may not be available in some languages and countries or regions.)
desktop-src/WmiSdk/provider-framework-utility-classes.md:20:-   In the function **DllMain** where you call [**CWbemProviderGlue::FrameworkLoginDLL**](/windows/desktop/api/WbemGlue/nf-wbemglue-cwbemproviderglue-frameworklogindll(lpcwstr_plong)), you must add a second parameter which is a pointer to a long.
desktop-src/WmiSdk/provider-framework-utility-classes.md:27:> In Maindll.cpp, **DllGetClassObject**, **DllCanUnloadNow**, **DllRegisterServer**, **DllUnregisterServer** and **DllMain** routines must be wrapped in a try/catch block.
desktop-src/Tapi/using-the-tapi-3-msp-base-classes.md:44:6.  Implement your DLL exports (for example, DllMain). Microsoft Visual C++ will generate these for you. In DllMain, on DLL\_PROCESS\_ATTACH and DLL\_PROCESS\_DETACH, respectively, use the **MSPLOGREGISTER** and **MSPLOGDEREGISTER** macros to enable up logging features for your DLL. Specify the name of your DLL in the **MSPLOGDEREGISTER** call.
desktop-src/Tapi/how-to-enable-debug-tracing-logging-for-derived-msps.md:11:First, make sure that the implementation of the derived MSP has followed the guidelines in the previous section with regard to debug tracing (defining the preprocessor symbol MSPLOG, registering for tracing during DllMain, and using the LOG macro for tracing). Find out what name the MSP uses when registering for tracing (this should usually be the DLL's name; it is referred to below as "&lt;dll name&gt;"). To enable tracing, use a registry editor ("Regedit.exe" or "Regedt32.exe") to locate the key "HKEY\_LOCAL\_MACHINE\\Software\\Microsoft\\Tracing" and do the following. Note that all of the values mentioned below, except the EnableDebuggerTracing value, should be created automatically after running your MSP for the first time.
desktop-src/Intl/creating-a-multilingual-user-interface-application.md:159:This Win32 DLL could also contain library type executable functionality (as any other DLL might). But to help focus on the Win32 resource-related aspects, we leave the run-time DLL code stubbed out in dllmain.cpp. Subsequent sections of this tutorial make use of the HelloModule resource data being built here and also present appropriate runtime code.
desktop-src/Intl/creating-a-multilingual-user-interface-application.md:161:To construct a Win32 resource module, start by creating a DLL with a stubbed out dllmain:
desktop-src/Intl/creating-a-multilingual-user-interface-application.md:179:3.  Examine dllmain.cpp. (You may want to add the UNREFERENCED\_PARAMETER macros to the generated code, as we have here, to enable it to compile at warning level 4.)
desktop-src/Intl/creating-a-multilingual-user-interface-application.md:181:    // dllmain.cpp : Defines the entry point for the DLL application.
desktop-src/Intl/creating-a-multilingual-user-interface-application.md:184:    BOOL APIENTRY DllMain( HMODULE hModule,
desktop-src/WsdApi/using-winhttp-logging-to-verify-get-traffic.md:80:16:51:47.899 ::*Session* :: DllMain(0x73fc0000, DLL_THREAD_ATTACH, 0x0)
desktop-src/Stg/create-and-run-stoserve-sample.md:24:| STOSERVE.CPP | The main implementation file for STOSERVE.DLL. Has DllMain and the COM server functions (for example, DllGetClassObject). |
desktop-src/WMP/modifying-wizard-generated-code.md:71:Find the **DllMain** function in NetworkPlugindll.cpp:
desktop-src/WMP/modifying-wizard-generated-code.md:75:extern "C" BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID /*lpReserved*/)
desktop-src/WMP/modifying-wizard-generated-code.md:94:extern "C" BOOL WINAPI DllMain(HANDLE hInstance, DWORD dwReason, LPVOID /*lpReserved*/)
desktop-src/Dlls/dllmain.md:4:title: DllMain entry point (Process.h)
desktop-src/Dlls/dllmain.md:11:- DllMain
desktop-src/Dlls/dllmain.md:18:# DllMain entry point
desktop-src/Dlls/dllmain.md:25:BOOL WINAPI DllMain(
desktop-src/Dlls/dllmain.md:64:> There are significant limits on what you can safely do in a DLL entry point. See [General Best Practices](dynamic-link-library-best-practices.md) 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.
desktop-src/Dlls/dllmain.md:72:BOOL WINAPI DllMain(
desktop-src/Dlls/dllmain.md:123:When the system calls the **DllMain** function with the **DLL\_PROCESS\_ATTACH** value, the function returns **TRUE** if it succeeds or **FALSE** if initialization fails. If the return value is **FALSE** when **DllMain** is called because the process uses the [**LoadLibrary**](/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya) function, **LoadLibrary** returns NULL. (The system immediately calls your entry-point function with **DLL\_PROCESS\_DETACH** and unloads the DLL.) If the return value is **FALSE** when **DllMain** is called during process initialization, the process terminates with an error. To get extended error information, call [**GetLastError**](/windows/desktop/api/errhandlingapi/nf-errhandlingapi-getlasterror).
desktop-src/Dlls/dllmain.md:125:When the system calls the **DllMain** function with any value other than **DLL\_PROCESS\_ATTACH**, the return value is ignored.
desktop-src/Dlls/dllmain.md:129:**DllMain** is a placeholder for the library-defined function name. You must specify the actual name you use when you build your DLL. For more information, see the documentation included with your development tools.
desktop-src/Dlls/dllmain.md:131:During initial process startup or after a call to [**LoadLibrary**](/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya), the system scans the list of loaded DLLs for the process. For each DLL that has not already been called with the **DLL\_PROCESS\_ATTACH** value, the system calls the DLL's entry-point function. This call is made in the context of the thread that caused the process address space to change, such as the primary thread of the process or the thread that called **LoadLibrary**. Access to the entry point is serialized by the system on a process-wide basis. Threads in *DllMain* hold the loader lock so no additional DLLs can be dynamically loaded or initialized.
desktop-src/Dlls/dllmain.md:148:Because Kernel32.dll is guaranteed to be loaded in the process address space when the entry-point function is called, calling functions in Kernel32.dll does not result in the DLL being used before its initialization code has been executed. Therefore, the entry-point function can call functions in Kernel32.dll that do not load other DLLs. For example, *DllMain* can create [synchronization objects](/windows/desktop/Sync/synchronization-objects) such as critical sections and mutexes, and use TLS. Unfortunately, there is not a comprehensive list of safe functions in Kernel32.dll.
desktop-src/Dlls/dllmain.md:156:If your DLL is linked with the C run-time library (CRT), the entry point provided by the CRT calls the constructors and destructors for global and static C++ objects. Therefore, these restrictions for *DllMain* also apply to constructors and destructors and any code that is called from them.
desktop-src/Dlls/using-shared-memory-in-a-dynamic-link-library.md:37:BOOL WINAPI DllMain(HINSTANCE hinstDLL,  // DLL module handle
desktop-src/Dlls/dynamic-link-library-data.md:26:A DLL can use file mapping to allocate memory that can be shared among processes. For a general discussion of how to use file mapping to create named shared memory, see [File Mapping](/windows/desktop/Memory/file-mapping). For an example that uses the [**DllMain**](dllmain.md) function to set up shared memory using file mapping, see [Using Shared Memory in a Dynamic-Link Library](using-shared-memory-in-a-dynamic-link-library.md).
desktop-src/Dlls/dynamic-link-library-data.md:30:The thread local storage (TLS) functions enable a DLL to allocate an index for storing and retrieving a different value for each thread of a multithreaded process. For example, a spreadsheet application can create a new instance of the same thread each time the user opens a new spreadsheet. A DLL providing the functions for various spreadsheet operations can use TLS to save information about the current state of each spreadsheet (row, column, and so on). For a general discussion of thread local storage, see [Thread Local Storage](/windows/desktop/ProcThread/thread-local-storage). For an example that uses the [**DllMain**](dllmain.md) function to set up thread local storage, see [Using Thread Local Storage in a Dynamic-Link Library](using-thread-local-storage-in-a-dynamic-link-library.md).
desktop-src/Dlls/dynamic-link-library-entry-point-function.md:15:If you are providing your own entry-point, see the [**DllMain**](dllmain.md) function. The name **DllMain** is a placeholder for a user-defined function. You must specify the actual name you use when you build your DLL. For more information, see the documentation included with your development tools.
desktop-src/Dlls/dynamic-link-library-entry-point-function.md:50:BOOL WINAPI DllMain(
desktop-src/Dlls/run-time-dynamic-linking.md:25:Run-time dynamic linking can cause problems if the DLL uses the [**DllMain**](dllmain.md) function to perform initialization for each thread of a process, because the entry-point is not called for threads that existed before [**LoadLibrary**](/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya) or [**LoadLibraryEx**](/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) is called. For an example showing how to deal with this problem, see [Using Thread Local Storage in a Dynamic-Link Library](using-thread-local-storage-in-a-dynamic-link-library.md).
desktop-src/Dlls/dynamic-link-library-functions.md:19:| [**DllMain**](dllmain.md)                                     | An optional entry point into a DLL.                                                                                                                            |
desktop-src/Dlls/toc.yml:54:      - name: "DllMain"
desktop-src/Dlls/toc.yml:55:        href: dllmain.md
desktop-src/Dlls/dynamic-link-library-best-practices.md:17:-   [**DllMain**](dllmain.md)
desktop-src/Dlls/dynamic-link-library-best-practices.md:23:Improper synchronization within [**DllMain**](dllmain.md) can cause an application to deadlock or access data or code in an uninitialized DLL. Calling certain functions from within **DllMain** causes such problems.
desktop-src/Dlls/dynamic-link-library-best-practices.md:29:[**DllMain**](dllmain.md) is called while the loader-lock is held. Therefore, significant restrictions are imposed on the functions that can be called within **DllMain**. As such, **DllMain** is designed to perform minimal initialization tasks, by using a small subset of the Microsoft® Windows® API. You cannot call any function in **DllMain** that directly or indirectly tries to acquire the loader lock. Otherwise, you will introduce the possibility that your application deadlocks or crashes. An error in a **DllMain** implementation can jeopardize the entire process and all of its threads.
desktop-src/Dlls/dynamic-link-library-best-practices.md:31:The ideal [**DllMain**](dllmain.md) would be just an empty stub. However, given the complexity of many applications, this is generally too restrictive. A good rule of thumb for **DllMain** is to postpone as much initialization as possible. Lazy initialization increases robustness of the application because this initialization is not performed while the loader lock is held. Also, lazy initialization enables you to safely use much more of the Windows API.
desktop-src/Dlls/dynamic-link-library-best-practices.md:35:You should never perform the following tasks from within [**DllMain**](dllmain.md):
desktop-src/Dlls/dynamic-link-library-best-practices.md:52:The following tasks are safe to perform within **DllMain**:
desktop-src/Dlls/dynamic-link-library-best-practices.md:66:It is important to note that the loader calls [**DllMain**](dllmain.md) with the loader lock already acquired, so the loader lock should have the highest precedence in the locking hierarchy. Also note that code only has to acquire the locks it requires for proper synchronization; it does not have to acquire every single lock that is defined in the hierarchy. For example, if a section of code requires only locks A and C for proper synchronization, then the code should acquire lock A before it acquires lock C; it is not necessary for the code to also acquire lock B. Furthermore, DLL code cannot explicitly acquire the loader lock. If the code must call an API such as [**GetModuleFileName**](/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea) that can indirectly acquire the loader lock and the code must also acquire a private lock, then the code should call **GetModuleFileName** before it acquires lock P, thus ensuring that load order is respected.
desktop-src/Dlls/dynamic-link-library-best-practices.md:68:Figure 2 is an example that illustrates lock order inversion. Consider a DLL whose main thread contains [**DllMain**](dllmain.md). The library loader acquires the loader lock L and then calls into **DllMain**. The main thread creates synchronization objects A, B, and G to serialize access to its data structures and then tries to acquire lock G. A worker thread that has already successfully acquired lock G then calls a function such as GetModuleHandle that attempts to acquire the loader lock L. Thus, the worker thread is blocked on L and the main thread is blocked on G, resulting in a deadlock.
desktop-src/Dlls/dynamic-link-library-best-practices.md:78:Thread Synchronization in [**DllMain**](dllmain.md) during Process Exit
desktop-src/Dlls/dynamic-link-library-best-practices.md:80:-   By the time [**DllMain**](dllmain.md) is called at process exit, all the process’s threads have been forcibly cleaned up and there is a chance that the address space is inconsistent. Synchronization is not required in this case. In other words, the ideal DLL\_PROCESS\_DETACH handler is empty.
desktop-src/Dlls/dynamic-link-library-best-practices.md:84:Thread Synchronization in **DllMain** for DLL\_THREAD\_DETACH during DLL Unload
desktop-src/Dlls/dynamic-link-library-best-practices.md:87:-   Thread synchronization is tricky because waiting on threads to exit in [**DllMain**](dllmain.md) can cause a deadlock. For example, DLL A holds the loader lock. It signals thread T to exit and waits for the thread to exit. Thread T exits and the loader tries to acquire the loader lock to call into DLL A’s **DllMain** with DLL\_THREAD\_DETACH. This causes a deadlock. To minimize the risk of a deadlock:
desktop-src/Dlls/dynamic-link-library-best-practices.md:88:    -   DLL A gets a DLL\_THREAD\_DETACH message in its [**DllMain**](dllmain.md) and sets an event for thread T, signaling it to exit.
desktop-src/Dlls/dynamic-link-library-best-practices.md:89:    -   Thread T finishes its current task, brings itself to a consistent state, signals DLL A, and waits infinitely. Note that the consistency-checking routines should follow the same restrictions as [**DllMain**](dllmain.md) to avoid deadlocking.
desktop-src/Dlls/dynamic-link-library-best-practices.md:92:If a DLL is unloaded after all its threads have been created, but before they begin executing, the threads may crash. If the DLL created threads in its **DllMain** as part of its initialization, some threads may not have finished initialization and their DLL\_THREAD\_ATTACH message is still waiting to be delivered to the DLL. In this situation, if the DLL is unloaded, it will begin terminating threads. However, some threads may be blocked behind the loader lock. Their DLL\_THREAD\_ATTACH messages are processed after the DLL has been unmapped, causing the process to crash.
desktop-src/Dlls/dynamic-link-library-best-practices.md:98:-   Use Application Verifier to catch the most common errors in [**DllMain**](dllmain.md).
desktop-src/Dlls/dynamic-link-library-best-practices.md:99:-   If using a private lock inside [**DllMain**](dllmain.md), define a locking hierarchy and use it consistently. The loader lock must be at the bottom of this hierarchy.
desktop-src/Dlls/dynamic-link-library-best-practices.md:101:-   Perform simple initializations statically at compile time, rather than in [**DllMain**](dllmain.md).
desktop-src/Dlls/dynamic-link-library-best-practices.md:102:-   Defer any calls in [**DllMain**](dllmain.md) that can wait until later.
desktop-src/Dlls/using-thread-local-storage-in-a-dynamic-link-library.md:39:// DllMain() is the entry-point function for this DLL. 
desktop-src/Dlls/using-thread-local-storage-in-a-dynamic-link-library.md:41:BOOL WINAPI DllMain(HINSTANCE hinstDLL, // DLL module handle
desktop-src/cossdk/implementing-a-com--resource-dispenser.md:19:4.  In the startup ([*DllMain*](/windows/desktop/Dlls/dllmain) or first call to the dispenser API), call the [**GetDispenserManager**](/windows/desktop/api/MtxDM/nf-mtxdm-getdispensermanager) function. This returns a pointer to the dispenser manager's [**IDispenserManager**](/windows/desktop/api/ComSvcs/nn-comsvcs-idispensermanager) interface.
