docs/error-messages/compiler-warnings/compiler-warning-level-1-c4747.md:36:BOOL WINAPI DllMain(HANDLE hInstance, ULONG Command, LPVOID Reserved) {
docs/error-messages/compiler-errors-2/compiler-error-c2731.md:13:The functions `main`, `WinMain`, `DllMain`, and `LibMain` cannot be overloaded.
docs/error-messages/compiler-errors-2/compiler-error-c3345.md:41:BOOL WINAPI DllMain(DWORD dwReason, LPVOID lpReserved) {
docs/error-messages/compiler-errors-2/compiler-error-c3345.md:43:   return __super::DllMain(dwReason, lpReserved);
docs/error-messages/tool-errors/linker-tools-warning-lnk4210.md:31:The [/GS](../../build/reference/gs-buffer-security-check.md) compiler option requires initialization by the `__security_init_cookie` function. This initialization is provided by default in the VCRuntime library startup code that runs in `_DllMainCRTStartup`.
docs/error-messages/tool-errors/linker-tools-warning-lnk4210.md:33:- If your project is built using /ENTRY, and if /ENTRY is passed a function other than `_DllMainCRTStartup`, the function must call `_CRT_INIT` to initialize the CRT. This call alone is not sufficient if your DLL uses /GS, requires static initializers, or is called in the context of MFC or ATL code. See [DLLs and Visual C++ run-time library behavior](../../build/run-time-library-behavior.md) for more information.
docs/error-messages/tool-errors/linker-tools-error-lnk1306.md:13:`DllMain` cannot be compiled to MSIL; it must be compiled to native.
docs/error-messages/tool-errors/linker-tools-error-lnk1306.md:37:// compile with: /clr /link /dll /entry:NewDllMain
docs/error-messages/tool-errors/linker-tools-error-lnk1306.md:40:int __stdcall NewDllMain( HINSTANCE h, ULONG ulReason, PVOID pvReserved ) {
docs/error-messages/tool-errors/linker-tools-error-lnk1306.md:49:// compile with: /clr /link /dll /entry:NewDllMain
docs/error-messages/tool-errors/linker-tools-error-lnk1306.md:52:int __stdcall NewDllMain( HINSTANCE h, ULONG ulReason, PVOID pvReserved ) {
docs/error-messages/tool-errors/c-runtime-error-r6033.md:11:Attempt to use MSIL code from this assembly during native code initialization. This indicates a bug in your application. It is most likely the result of calling an MSIL-compiled (/clr) function from a native constructor or from DllMain.
docs/error-messages/tool-errors/c-runtime-error-r6030.md:25:This error occurs if you are using the C Runtime (CRT), but the CRT startup code was not executed. It is possible to get this error if the linker switch [/ENTRY](../../build/reference/entry-entry-point-symbol.md) is used to override the default starting address, usually **mainCRTStartup**, **wmainCRTStartup** for a console EXE, **WinMainCRTStartup** or **wWinMainCRTStartup** for a Windows EXE, or **_DllMainCRTStartup** for a DLL. Unless one of the above functions is called on startup, the C Runtime will not be initialized. These startup functions are ordinarily called by default when you link to the C runtime library and use the normal **main**, **wmain**, **WinMain**, or **DllMain** entry points.
docs/error-messages/tool-errors/linker-tools-error-lnk1561.md:13:The linker did not find an *entry point*, the initial function to call in your executable. By default, the linker looks for a `main` or `wmain` function for a console app, a `WinMain` or `wWinMain` function for a Windows app, or `DllMain` for a DLL that requires initialization. You can specify another function by using the [/ENTRY](../../build/reference/entry-entry-point-symbol.md) linker option.
docs/dotnet/how-to-compile-mfc-and-atl-code-by-using-clr.md:41:1. For the file that contains DllMain and anything it calls, in **Solution Explorer**, right-click the file and then click **Properties**. Under **Configuration Properties**, expand the node next to **C/C++** and select **General**. In the right pane, under **Project Defaults**, set **Compile with Common Language Runtime support** to **No Common Language Runtime support**.
docs/dotnet/how-to-compile-mfc-and-atl-code-by-using-clr.md:65:1. For the file that contains DllMain and anything it calls, in **Solution Explorer**, right-click the file and then click **Properties**. Under **Configuration Properties**, expand the node next to **C/C++** and select **General**. In the right pane, under **Project Defaults**, set **Compile with Common Language Runtime support** to **No Common Language Runtime support**.
docs/dotnet/initialization-of-mixed-assemblies.md:10:Windows developers must always be wary of loader lock when running code during `DllMain`. However, there are some additional issues to consider when dealing with C++/CLI mixed-mode assemblies.
docs/dotnet/initialization-of-mixed-assemblies.md:12:Code within [DllMain](/windows/win32/Dlls/dllmain) must not access the .NET Common Language Runtime (CLR). That means that `DllMain` should make no calls to managed functions, directly or indirectly; no managed code should be declared or implemented in `DllMain`; and no garbage collection or automatic library loading should take place within `DllMain`.
docs/dotnet/initialization-of-mixed-assemblies.md:22:- First, if users attempt to execute functions compiled to Microsoft intermediate language (MSIL) when the loader lock is held (from `DllMain` or in static initializers, for example), it can cause deadlock. Consider the case in which the MSIL function references a type in an assembly that's not loaded yet. The CLR will attempt to automatically load that assembly, which may require the Windows loader to block on the loader lock. A deadlock occurs, since the loader lock is already held by code earlier in the call sequence. However, executing MSIL under loader lock doesn't guarantee that a deadlock will occur. That's what makes this scenario difficult to diagnose and fix. In some circumstances, such as when the DLL of the referenced type contains no native constructs and all of its dependencies contain no native constructs, the Windows loader isn't required to load the .NET assembly of the referenced type. Additionally, the required assembly or its mixed native/.NET dependencies may have already been loaded by other code. Consequently, the deadlocking can be difficult to predict, and can vary depending on the configuration of the target machine.
docs/dotnet/initialization-of-mixed-assemblies.md:30:- Unmanaged and managed initialization is done in two separate and distinct stages. Unmanaged initialization takes place first (via `DllMain`), and managed initialization takes place afterwards, through a .NET-supported `.cctor` construct. The latter is completely transparent to the user unless **`/Zl`** or **`/NODEFAULTLIB`** are used. For more information, see[`/NODEFAULTLIB` (Ignore Libraries)](../build/reference/nodefaultlib-ignore-libraries.md) and [`/Zl` (Omit Default Library Name)](../build/reference/zl-omit-default-library-name.md).
docs/dotnet/initialization-of-mixed-assemblies.md:32:Loader lock can still occur, but now it occurs reproducibly, and is detected. If `DllMain` contains MSIL instructions, the compiler generates warning [Compiler Warning (level 1) C4747](../error-messages/compiler-warnings/compiler-warning-level-1-c4747.md). Furthermore, either the CRT or the CLR will try to detect and report attempts to execute MSIL under loader lock. CRT detection results in runtime diagnostic C Run-Time Error R6033.
docs/dotnet/initialization-of-mixed-assemblies.md:40:### DllMain
docs/dotnet/initialization-of-mixed-assemblies.md:42:The `DllMain` function is a user-defined entry point for a DLL. Unless the user specifies otherwise, `DllMain` is invoked every time a process or thread attaches to or detaches from the containing DLL. Since this invocation can occur while the loader lock is held, no user-supplied `DllMain` function should be compiled to MSIL. Furthermore, no function in the call tree rooted at `DllMain` can be compiled to MSIL. To resolve issues here, the code block that defines `DllMain` should be modified with `#pragma unmanaged`. The same should be done for every function that `DllMain` calls.
docs/dotnet/initialization-of-mixed-assemblies.md:46:As an alternative, if `DllMain` isn't required or if it doesn't need to be executed under loader lock, you can remove the user-provided `DllMain` implementation, which eliminates the problem.
docs/dotnet/initialization-of-mixed-assemblies.md:48:If `DllMain` attempts to execute MSIL directly, [Compiler Warning (level 1) C4747](../error-messages/compiler-warnings/compiler-warning-level-1-c4747.md) will result. However, the compiler can't detect cases where `DllMain` calls a function in another module that in turn attempts to execute MSIL.
docs/dotnet/initialization-of-mixed-assemblies.md:65:This risk of deadlock depends on whether the containing module is compiled with **`/clr`** and whether MSIL will be executed. Specifically, if the static variable is compiled without **`/clr`** (or is in a `#pragma unmanaged` block), and the dynamic initializer required to initialize it results in the execution of MSIL instructions, deadlock may occur. It's because, for modules compiled without **`/clr`**, the initialization of static variables is performed by DllMain. In contrast, static variables compiled with **`/clr`** are initialized by the `.cctor`, after the unmanaged initialization stage has completed and the loader lock has been released.
docs/dotnet/initialization-of-mixed-assemblies.md:153:1. Open the call stack window. (On the menu bar, choose **Debug** > **Windows** > **Call Stack**.) The offending `DllMain` or static initializer is identified with a green arrow. If the offending function isn't identified, the following steps must be taken to find it.
docs/dotnet/initialization-of-mixed-assemblies.md:161:1. Look for the first instance (closest to the bottom of the stack) of either _CorDllMain (if `DllMain` causes the issue) or _VTableBootstrapThunkInitHelperStub or GetTargetForVTableEntry (if a static initializer causes the issue). The stack entry just below this call is the invocation of the MSIL implemented function that attempted to execute under loader lock.
docs/dotnet/initialization-of-mixed-assemblies.md:169:The following sample shows how to avoid loader lock by moving code from `DllMain` into the constructor of a global object.
docs/dotnet/initialization-of-mixed-assemblies.md:171:In this sample, there's a global managed object whose constructor contains the managed object that was originally in `DllMain`. The second part of this sample references the assembly, creating an instance of the managed object to invoke the module constructor that does the initialization.
docs/dotnet/initialization-of-mixed-assemblies.md:196:BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved) {
docs/mfc/tn058-mfc-module-state-implementation.md:29:The current module state is switched by calling `AfxSetModuleState`. For the most part, you will never deal directly with the API. MFC, in many cases, will call it for you (at WinMain, OLE entry-points, `AfxWndProc`, etc.). This is done in any component you write by statically linking in a special `WndProc`, and a special `WinMain` (or `DllMain`) that knows which module state should be current. You can see this code by looking at DLLMODUL.CPP or APPMODUL.CPP in the MFC\SRC directory.
docs/mfc/tn058-mfc-module-state-implementation.md:37:1. `RawDllMain` is called first. It sets the module state to the known static module state for the DLL. For this reason `RawDllMain` is statically linked to the DLL.
docs/mfc/tn058-mfc-module-state-implementation.md:51:Note that certain kinds of DLLs, specifically "MFC Extension" DLLs do not switch the module state in their `RawDllMain` (actually, they usually don't even have a `RawDllMain`). This is because they are intended to behave "as if" they were actually present in the application that uses them. They are very much a part of the application that is running and it is their intention to modify that application's global state.
docs/mfc/tn025-document-view-and-frame-creation.md:20:It is statically constructed and initialized by the framework's internal implementation of `WinMain`. You must derive from `CWinApp` to do anything useful (exception: MFC extension DLLs should not have a `CWinApp` instance — initialization is done in `DllMain` instead).
docs/mfc/tn001-window-class-registration.md:98:It is important to use `AfxRegisterClass` (or `AfxRegisterWndClass`) in a DLL on Win32. Win32 does not automatically unregister classes registered by a DLL, so you must explicitly unregister classes when the DLL is terminated. By using `AfxRegisterClass` instead of `RegisterClass` this is handled automatically for you. `AfxRegisterClass` maintains a list of unique classes registered by your DLL and will automatically unregister them when the DLL terminates. When you use `RegisterClass` in a DLL, you must ensure that all classes are unregistered when the DLL is terminated (in your [DllMain](/windows/win32/Dlls/dllmain) function). Failure to do so might cause `RegisterClass` to fail unexpectedly when another client application tries to use your DLL.
docs/mfc/tn033-dll-version-of-mfc.md:84:- An MFC extension DLL must provide a special `DllMain`. AppWizard supplies a `DllMain` function that you can modify.
docs/mfc/tn033-dll-version-of-mfc.md:113:You can use AppWizard to create an MFC extension DLL project, and it automatically generates the appropriate compiler and linker settings. It also generates a `DllMain` function that you can modify.
docs/mfc/tn033-dll-version-of-mfc.md:264:### DllMain
docs/mfc/tn033-dll-version-of-mfc.md:266:Here's the code you should place in your main source file for your MFC extension DLL. It should come after the standard includes. When you use AppWizard to create starter files for an MFC extension DLL, it supplies a `DllMain` for you.
docs/mfc/tn033-dll-version-of-mfc.md:274:DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID)
docs/mfc/tn033-dll-version-of-mfc.md:302:The global *extensionDLL* must be declared as shown. Unlike the 16-bit version of MFC, you can allocate memory and call MFC functions during this time, since the *`MFCxx.DLL`* is fully initialized by the time your `DllMain` is called.
docs/mfc/tn033-dll-version-of-mfc.md:335:Each client application that wants to use your DLL must call this initialization routine, if you use this approach. You may also allocate this `CDynLinkLibrary` object in your `DllMain` just after you call `AfxInitExtensionModule`.
docs/mfc/reference/afx-extension-module-structure.md:45:MFC extension DLLs need to do two things in their `DllMain` function:
docs/mfc/reference/afx-extension-module-structure.md:51:The `AFX_EXTENSION_MODULE` structure is used to hold a copy of the MFC extension DLL module state, including a copy of the runtime class objects that have been initialized by the MFC extension DLL as part of normal static object construction executed before `DllMain` is entered. For example:
docs/mfc/reference/extension-dll-macros.md:180:Call this function in an MFC extension DLL's `DllMain` to initialize the DLL.
docs/mfc/reference/extension-dll-macros.md:191:A reference to the [`AFX_EXTENSION_MODULE` Structure](afx-extension-module-structure.md) structure that will contain the state of the MFC extension DLL module after the initialization. The state includes a copy of the runtime class objects that have been initialized by the MFC extension DLL as part of normal static object construction executed before `DllMain` is entered.
docs/mfc/reference/extension-dll-macros.md:207:DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
docs/mfc/reference/extension-dll-macros.md:223:MFC extension DLLs need to do two things in their `DllMain` function:
docs/mfc/reference/extension-dll-macros.md:295:DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
docs/mfc/reference/extension-dll-macros.md:324:MFC extension DLLs need to call [`AfxInitExtensionModule`](#afxinitextensionmodule) in their `DllMain`. If the DLL exports [`CRuntimeClass`](cruntimeclass-structure.md) objects or has its own custom resources, you also need to create a `CDynLinkLibrary` object in `DllMain`.
docs/mfc/reference/classes-and-functions-generated-by-the-mfc-dll-wizard.md:14:|[Extension](../../build/extension-dlls-overview.md)|None|None|`DllMain`|
docs/mfc/reference/classes-and-functions-generated-by-the-mfc-dll-wizard.md:17:|[Extension](../../build/extension-dlls-overview.md)|Window Sockets|None|`DllMain`|
docs/mfc/tn011-using-mfc-as-part-of-a-dll.md:54:## WinMain -> DllMain
docs/mfc/tn011-using-mfc-as-part-of-a-dll.md:56:The MFC library defines the standard Win32 `DllMain` entry point that initializes your [CWinApp](../mfc/reference/cwinapp-class.md) derived object as in a typical MFC application. Place all DLL-specific initialization in the [InitInstance](../mfc/reference/cwinapp-class.md#initinstance) method as in a typical MFC application.
docs/mfc/tn011-using-mfc-as-part-of-a-dll.md:62:The `DllMain` function that MFC provides will call the [CWinApp::ExitInstance](../mfc/reference/cwinapp-class.md#exitinstance) method of your class that is derived from `CWinApp` before the DLL is unloaded.
docs/cppcx/wrl/how-to-create-a-classic-com-component-using-wrl.md:29:6. Use the following code to replace the code in `dllmain.cpp`. This file defines the DLL export functions. These functions use the [Microsoft::WRL::Module](module-class.md) class to manage the class factories for the module.
docs/cppcx/wrl/walkthrough-creating-a-windows-store-app-using-wrl-and-media-foundation.md:85:1. Use the following code to replace the contents of `dllmain.cpp`:
docs/cppcx/codesnippet/CPP/walkthrough-creating-a-windows-store-app-using-wrl-and-media-foundation_6.cpp:7:STDAPI_(BOOL) DllMain(_In_ HINSTANCE hInstance, _In_ DWORD reason, _In_opt_ void *reserved)
docs/cppcx/codesnippet/CPP/how-to-create-a-classic-com-component-using-wrl_3.cpp:25:STDAPI_(BOOL) DllMain(_In_opt_ HINSTANCE hinst, DWORD reason, _In_opt_ void*)
docs/atl/creating-the-project-atl-tutorial-part-1.md:52:|Polygon.cpp|Contains the implementation of `DllMain`, `DllCanUnloadNow`, `DllGetClassObject`, `DllRegisterServer`, and `DllUnregisterServer`. Also contains the object map, which is a list of the ATL objects in your project. This is initially blank.|
docs/atl/creating-the-project-atl-tutorial-part-1.md:68:|Polygon.cpp|Contains the implementation of `DllMain`, `DllCanUnloadNow`, `DllGetClassObject`, `DllRegisterServer`, and `DllUnregisterServer`. Also contains the object map, which is a list of the ATL objects in your project. This is initially blank.|
docs/atl/linking-to-the-crt-in-your-atl-project.md:5:helpviewer_keywords: ["CRT, linking with ATL", "WinMainCRTStartup method", "DllMainCRTStartup method", "wWinMainCRTStartup method", "ATL, C Run-Time library (CRT)"]
docs/atl/linking-to-the-crt-in-your-atl-project.md:14:If you statically link to the CRT, code from the CRT is placed in your executable image and you do not need to have the CRT DLL present on a system to run your image. If you dynamically link to the CRT, references to the code in the CRT DLL are placed in your image, but not the code itself. In order for your image to run on a given system, the CRT DLL must be present on that system. Even when you dynamically link to the CRT, you may find that some code can be statically linked (for example, `DllMainCRTStartup`).
docs/atl/linking-to-the-crt-in-your-atl-project.md:16:When you link your image, you either explicitly or implicitly specify an entry point that the operating system will call into after loading the image. For a DLL, the default entry point is `DllMainCRTStartup`. For an EXE, it is `WinMainCRTStartup`. You can override the default with the /ENTRY linker option. The CRT provides an implementation for `DllMainCRTStartup`, `WinMainCRTStartup`, and `wWinMainCRTStartup` (the Unicode entry point for an EXE). These CRT-provided entry points call constructors on global objects and initialize other data structures that are used by some CRT functions. This startup code adds about 25K to your image if it is linked statically. If it is linked dynamically, most of the code is in the DLL, so your image size stays small.
docs/atl/reference/ccomobjectrootex-class.md:287:`ObjectMain` is called from the entry point of the DLL, so the type of operation that the entry-point function can perform is restricted. For more information on these restrictions, see [DLLs and Visual C++ run-time library behavior](../../build/run-time-library-behavior.md) and [DllMain](/windows/win32/Dlls/dllmain).
docs/atl/reference/ccomautothreadmodule-class.md:158:[in] The HINSTANCE passed to `DLLMain` or `WinMain`.
docs/atl/reference/ccommodule-class.md:189:[in] The HINSTANCE passed to `DLLMain` or `WinMain`.
docs/atl/reference/ccommodule-class.md:250:The [Init](#init) method sets `m_hInst` to the handle passed to `DLLMain` or `WinMain`.
docs/atl/reference/ccommodule-class.md:264:The [Init](#init) method sets `m_hInstResource` to the handle passed to `DLLMain` or `WinMain`. You can explicitly set `m_hInstResource` to the handle to a resource.
docs/atl/reference/ccommodule-class.md:280:The [Init](#init) method sets `m_hInstTypeLib` to the handle passed to `DLLMain` or `WinMain`. You can explicitly set `m_hInstTypeLib` to the handle to a type library.
docs/atl/reference/catldllmodulet-class.md:5:f1_keywords: ["CAtlDllModuleT", "ATLBASE/ATL::CAtlDllModuleT", "ATLBASE/ATL::CAtlDllModuleT::CAtlDllModuleT", "ATLBASE/ATL::CAtlDllModuleT::DllCanUnloadNow", "ATLBASE/ATL::CAtlDllModuleT::DllGetClassObject", "ATLBASE/ATL::CAtlDllModuleT::DllMain", "ATLBASE/ATL::CAtlDllModuleT::DllRegisterServer", "ATLBASE/ATL::CAtlDllModuleT::DllUnregisterServer", "ATLBASE/ATL::CAtlDllModuleT::GetClassObject"]
docs/atl/reference/catldllmodulet-class.md:40:|[CAtlDllModuleT::DllMain](#dllmain)|The optional entry point into a dynamic-link library (DLL).|
docs/atl/reference/catldllmodulet-class.md:119:## <a name="dllmain"></a> CAtlDllModuleT::DllMain
docs/atl/reference/catldllmodulet-class.md:124:BOOL WINAPI DllMain(DWORD dwReason, LPVOID /* lpReserved*/) throw();
docs/c-runtime-library/reference/onexit-onexit-m.md:41:In the case when **`_onexit`** is called from within a DLL, routines registered with **`_onexit`** run when the DLL is unloaded, after `DllMain` is called with `DLL_PROCESS_DETACH`.
docs/c-runtime-library/reference/exit-exit-exit.md:66:Don't use `DLL_PROCESS_ATTACH` to call **`exit`** from `DllMain`. To exit the `DLLMain` function, return `FALSE` from `DLL_PROCESS_ATTACH`.
docs/porting/overview-of-potential-upgrade-issues-visual-cpp.md:165:### LNK 2005 _DllMain@12 already defined in MSVCRTD.lib
docs/porting/how-to-use-existing-cpp-code-in-a-universal-windows-platform-app.md:124:Everything else in the project (*`pch.h`*, *`dllmain.cpp`*) is part of the standard Win32 project template. The code defines the macro `GIRAFFE_API`, which resolves to `__declspec(dllexport)` when `GIRAFFE_EXPORTS` is defined. That is, it's defined when the project is built as a DLL, but not when a client uses the *`giraffe.h`* header. This DLL can be used in a UWP project without changing the source code. Only some project settings and properties need to change.
docs/porting/visual-cpp-change-history-2003-2015.md:3208:- Moved `afxGlobalData` initialization to on-demand instead of at CRT initialization time, to satisfy `DLLMain` requirements.
docs/cpp/thread.md:31:1. If the variable is initialized with a function call (including constructors), this function will only be called for the thread that caused the binary/DLL to load into the process, and for those threads that started after the binary/DLL was loaded. The initialization functions are not called for any other thread that was already running when the DLL was loaded. Dynamic initialization occurs on the DllMain call for DLL_THREAD_ATTACH, but the DLL never gets that message if the DLL isn't in the process when the thread starts.
docs/windows/attributes/module-cpp.md:93:   [CAtlDllModuleT](../../atl/reference/catldllmodulet-class.md) is used as the base class and the standard DLL entry points required for a COM server. These entry points are [DllMain](/windows/win32/Dlls/dllmain), [DllRegisterServer](/windows/win32/api/olectl/nf-olectl-dllregisterserver), [DllUnRegisterServer](/windows/win32/api/olectl/nf-olectl-dllunregisterserver), [DllCanUnloadNow](/windows/win32/api/combaseapi/nf-combaseapi-dllcanunloadnow), and [DllGetClassObject](/windows/win32/api/combaseapi/nf-combaseapi-dllgetclassobject).
docs/windows/attributes/module-cpp.md:135:BOOL WINAPI DllMain(DWORD dwReason, LPVOID lpReserved) {
docs/windows/attributes/module-cpp.md:137:   return __super::DllMain(dwReason, lpReserved);
docs/atl-mfc-shared/codesnippet/CPP/afx-extension-module-structure_1.cpp:3:DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
docs/atl-mfc-shared/reference/cimage-class.md:101:> In Visual Studio .NET 2003, this class keeps a count of the number of `CImage` objects created. Whenever the count goes to 0, the function `GdiplusShutdown` is automatically called to release resources used by GDI+. This ensures that any `CImage` objects created directly or indirectly by DLLs are always destroyed properly and that `GdiplusShutdown` is not called from `DllMain`.
docs/atl-mfc-shared/reference/cimage-class.md:354:**Note** In Visual Studio, this class keeps a count of the number of `CImage` objects created. Whenever the count goes to 0, the function `GdiplusShutdown` is automatically called to release resources used by GDI+. This ensures that any `CImage` objects created directly or indirectly by DLLs are always destroyed properly and that `GdiplusShutdown` is not called from DllMain.
docs/build/dll-frequently-asked-questions.yml:24:          - A supplied `DllMain` or **RawDllMain** function in a regular MFC DLL.
docs/build/dll-frequently-asked-questions.yml:26:          - A supplied `DllMain` or **RawDllMain** function in an MFC extension DLL.
docs/build/walkthrough-creating-and-using-a-dynamic-link-library-cpp.md:339:1>dllmain.cpp
docs/build/walkthrough-creating-and-using-a-dynamic-link-library-cpp.md:354:1>dllmain.cpp
docs/build/walkthrough-creating-and-using-a-dynamic-link-library-cpp.md:369:1>dllmain.cpp
docs/build/using-database-ole-and-sockets-extension-dlls-in-regular-dlls.md:45:If you'll only use an MFC extension DLL from an MFC application, and never from a regular MFC DLL, then it's sufficient to create the `CDynLinkLibrary` object in the MFC extension DLL `DllMain` function. It's what the MFC DLL Wizard MFC extension DLL code does. When loading an MFC extension DLL implicitly, `DllMain` loads and executes before the application ever starts. Any `CDynLinkLibrary` creations are wired into a default chain that the MFC DLL reserves for an MFC application.
docs/build/using-database-ole-and-sockets-extension-dlls-in-regular-dlls.md:64:DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
docs/build/extension-dlls.md:22:- MFC extension DLLs should, however, provide a `DllMain` function and do any necessary initialization there.
docs/build/extension-dlls.md:32:- It calls `AfxInitExtensionModule` in its `DllMain` function. The return value of this function should be checked. If a zero value is returned from `AfxInitExtensionModule`, return 0 from your `DllMain` function.
docs/build/extension-dlls.md:98:If your MFC extension DLL needs to maintain extra data for each application, you can derive a new class from **CDynLinkLibrary** and create it in `DllMain`. When running, the DLL can check the current application's list of **CDynLinkLibrary** objects to find the one for that particular MFC extension DLL.
docs/build/regular-dlls-dynamically-linked-to-mfc.md:34:- This type of DLL uses the `DllMain` provided by MFC. Place all DLL-specific initialization code in the `InitInstance` member function and termination code in `ExitInstance` as in a normal MFC application.
docs/build/regular-dlls-dynamically-linked-to-mfc.md:42:Place all DLL-specific initialization in the `CWinApp::InitInstance` member function as in a normal MFC application. The `CWinApp::ExitInstance` member function of your `CWinApp` derived class is called from the MFC provided `DllMain` function before the DLL is unloaded.
docs/build/dlls-in-visual-cpp.md:16:Static linking copies all the object code in a static library into the executables that use it when they're built. Dynamic linking includes only the information needed by Windows at run time to locate and load the DLL that contains a data item or function. When you create a DLL, you also create an import library that contains this information. When you build an executable that calls the DLL, the linker uses the exported symbols in the import library to store this information for the Windows loader. When the loader loads a DLL, the DLL is mapped into the memory space of your application. If present, a special function in the DLL, `DllMain`, is called to do any initialization the DLL requires.
docs/build/linking-an-executable-to-a-dll.md:32:If any of the DLLs has an entry-point function for initialization and termination code such as `DllMain`, the operating system calls the function. One of the parameters passed to the entry-point function specifies a code that indicates the DLL is attaching to the process. If the entry-point function doesn't return TRUE, the system terminates the process and reports the error.
docs/build/linking-an-executable-to-a-dll.md:46:- A process that uses implicit linking is also terminated if any of the DLLs it's linked to have a `DllMain` function that fails. A process that uses explicit linking isn't terminated in this situation.
docs/build/linking-an-executable-to-a-dll.md:54:- If the DLL has a `DllMain` entry point function, the operating system calls the function in the context of the thread that called `LoadLibrary`. The entry-point function isn't called if the DLL is already attached to the process because of a previous call to `LoadLibrary` that has had no corresponding call to the `FreeLibrary` function. Explicit linking can cause problems if the DLL uses a `DllMain` function to initialize each thread of a process, because any threads that already exist when `LoadLibrary` (or `AfxLoadLibrary`) is called aren't initialized.
docs/build/regular-dlls-statically-linked-to-mfc.md:26:- This type of DLL uses the `DllMain` provided by MFC. Place all DLL-specific initialization code in the `InitInstance` member function and termination code in `ExitInstance` as in a normal MFC application.
docs/build/run-time-library-behavior.md:5:f1_keywords: ["_DllMainCRTStartup", "CRT_INIT"]
docs/build/run-time-library-behavior.md:6:helpviewer_keywords: ["DLLs [C++], entry point function", "process detach [C++]", "process attach [C++]", "DLLs [C++], run-time library behavior", "DllMain function", "_CRT_INIT macro", "_DllMainCRTStartup method", "run-time [C++], DLL startup sequence", "DLLs [C++], startup sequence"]
docs/build/run-time-library-behavior.md:11:When you build a Dynamic-link Library (DLL) by using Visual Studio, by default, the linker includes the Visual C++ run-time library (VCRuntime). The VCRuntime contains code required to initialize and terminate a C/C++ executable. When linked into a DLL, the VCRuntime code provides an internal DLL entry-point function called `_DllMainCRTStartup` that handles Windows OS messages to the DLL to attach to or detach from a process or thread. The `_DllMainCRTStartup` function performs essential tasks such as stack buffer security set up, C run-time library (CRT) initialization and termination, and calls to constructors and destructors for static and global objects. `_DllMainCRTStartup` also calls hook functions for other libraries such as WinRT, MFC, and ATL to perform their own initialization and termination. Without this initialization, the CRT and other libraries, as well as your static variables, would be left in an uninitialized state. The same VCRuntime internal initialization and termination routines are called whether your DLL uses a statically linked CRT or a dynamically linked CRT DLL.
docs/build/run-time-library-behavior.md:13:## Default DLL entry point _DllMainCRTStartup
docs/build/run-time-library-behavior.md:15:In Windows, all DLLs can contain an optional entry-point function, usually called `DllMain`, that is called for both initialization and termination. This gives you an opportunity to allocate or release additional resources as needed. Windows calls the entry-point function in four situations: process attach, process detach, thread attach, and thread detach. When a DLL is loaded into a process address space, either when an application that uses it is loaded, or when the application requests the DLL at runtime, the operating system creates a separate copy of the DLL data. This is called *process attach*. *Thread attach* occurs when the process the DLL is loaded in creates a new thread. *Thread detach* occurs when the thread terminates, and *process detach* is when the DLL is no longer required and is released by an application. The operating system makes a separate call to the DLL entry point for each of these events, passing a *reason* argument for each event type. For example, the OS sends `DLL_PROCESS_ATTACH` as the *reason* argument to signal process attach.
docs/build/run-time-library-behavior.md:17:The VCRuntime library provides an entry-point function called `_DllMainCRTStartup` to handle default initialization and termination operations. On process attach, the `_DllMainCRTStartup` function sets up buffer security checks, initializes the CRT and other libraries, initializes run-time type information, initializes and calls constructors for static and non-local data, initializes thread-local storage, increments an internal static counter for each attach, and then calls a user- or library-supplied `DllMain`. On process detach, the function goes through these steps in reverse. It calls `DllMain`, decrements the internal counter, calls destructors, calls CRT termination functions and registered `atexit` functions, and notifies any other libraries of termination. When the attachment counter goes to zero, the function returns `FALSE` to indicate to Windows that the DLL can be unloaded. The `_DllMainCRTStartup` function is also called during thread attach and thread detach. In these cases, the VCRuntime code does no additional initialization or termination on its own, and just calls `DllMain` to pass the message along. If `DllMain` returns `FALSE` from process attach, signaling failure, `_DllMainCRTStartup` calls `DllMain` again and passes `DLL_PROCESS_DETACH` as the *reason* argument, then goes through the rest of the termination process.
docs/build/run-time-library-behavior.md:19:When building DLLs in Visual Studio, the default entry point  `_DllMainCRTStartup` supplied by VCRuntime is linked in automatically. You do not need to specify an entry-point function for your DLL by using the [/ENTRY (Entry point symbol)](reference/entry-entry-point-symbol.md) linker option.
docs/build/run-time-library-behavior.md:22:> While it is possible to specify another entry-point function for a DLL by using the /ENTRY: linker option, we do not recommend it, because your entry-point function would have to duplicate everything that `_DllMainCRTStartup` does, in the same order. The VCRuntime provides functions that allow you to duplicate its behavior. For example, you can call [__security_init_cookie](../c-runtime-library/reference/security-init-cookie.md) immediately on process attach to support the [/GS (Buffer security check)](reference/gs-buffer-security-check.md) buffer checking option. You can call the `_CRT_INIT` function, passing the same parameters as the entry point function, to perform the rest of the DLL initialization or termination functions.
docs/build/run-time-library-behavior.md:28:Your DLL may have initialization code that must execute when your DLL loads. In order for you to perform your own DLL initialization and termination functions, `_DllMainCRTStartup` calls a function called `DllMain` that you can provide. Your `DllMain` must have the signature required for a DLL entry point. The default entry point function `_DllMainCRTStartup` calls `DllMain` using the same parameters passed by Windows. By default, if you do not provide a `DllMain` function, Visual Studio provides one for you and links it in so that `_DllMainCRTStartup` always has something to call. This means that if you do not need to initialize your DLL, there is nothing special you have to do when building your DLL.
docs/build/run-time-library-behavior.md:30:This is the signature used for `DllMain`:
docs/build/run-time-library-behavior.md:35:extern "C" BOOL WINAPI DllMain (
docs/build/run-time-library-behavior.md:41:Some libraries wrap the `DllMain` function for you. For example, in a regular MFC DLL, implement the `CWinApp` object's `InitInstance` and `ExitInstance` member functions to perform initialization and termination required by your DLL. For more details, see the [Initialize regular MFC DLLs](#initializing-regular-dlls) section.
docs/build/run-time-library-behavior.md:44:> There are significant limits on what you can safely do in a DLL entry point. For more information about specific Windows APIs that are unsafe to call in `DllMain`, see [General Best Practices](/windows/win32/Dlls/dynamic-link-library-best-practices). 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.
docs/build/run-time-library-behavior.md:50:To perform your own initialization in ordinary (non-MFC) DLLs that use the VCRuntime-supplied `_DllMainCRTStartup` entry point, your DLL source code must contain a function called `DllMain`. The following code presents a basic skeleton showing what the definition of `DllMain` might look like:
docs/build/run-time-library-behavior.md:55:extern "C" BOOL WINAPI DllMain (
docs/build/run-time-library-behavior.md:85:> Older Windows SDK documentation says that the actual name of the DLL entry-point function must be specified on the linker command-line with the /ENTRY option. With Visual Studio, you do not need to use the /ENTRY option if the name of your entry-point function is `DllMain`. In fact, if you use the /ENTRY option and name your entry-point function something other than `DllMain`, the CRT does not get initialized properly unless your entry-point function makes the same initialization calls that `_DllMainCRTStartup` makes.
docs/build/run-time-library-behavior.md:91:Because regular MFC DLLs have a `CWinApp` object, they should perform their initialization and termination tasks in the same location as an MFC application: in the `InitInstance` and `ExitInstance` member functions of the DLL's `CWinApp`-derived class. Because MFC provides a `DllMain` function that is called by `_DllMainCRTStartup` for `DLL_PROCESS_ATTACH` and `DLL_PROCESS_DETACH`, you should not write your own `DllMain` function. The MFC-provided `DllMain` function calls `InitInstance` when your DLL is loaded and it calls `ExitInstance` before the DLL is unloaded.
docs/build/run-time-library-behavior.md:107:Because MFC extension DLLs do not have a `CWinApp`-derived object (as do regular MFC DLLs), you should add your initialization and termination code to the `DllMain` function that the MFC DLL Wizard generates.
docs/build/run-time-library-behavior.md:123:DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
docs/build/run-time-library-behavior.md:148:In the `DllMain` that the MFC DLL Wizard generates, the call to `AfxInitExtensionModule` captures the module's run-time classes (`CRuntimeClass` structures) as well as its object factories (`COleObjectFactory` objects) for use when the `CDynLinkLibrary` object is created. You should check the return value of `AfxInitExtensionModule`; if a zero value is returned from `AfxInitExtensionModule`, return zero from your `DllMain` function.
docs/build/run-time-library-behavior.md:154:Because the MFCx0.dll is fully initialized by the time `DllMain` is called, you can allocate memory and call MFC functions within `DllMain` (unlike the 16-bit version of MFC).
docs/build/run-time-library-behavior.md:156:Extension DLLs can take care of multithreading by handling the `DLL_THREAD_ATTACH` and `DLL_THREAD_DETACH` cases in the `DllMain` function. These cases are passed to `DllMain` when threads attach and detach from the DLL. Calling [TlsAlloc](/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsalloc) when a DLL is attaching allows the DLL to maintain thread local storage (TLS) indexes for every thread attached to the DLL.
docs/build/run-time-library-behavior.md:163:A sample initialization function that handles multithreading is included in [Using Thread Local Storage in a Dynamic-Link Library](/windows/win32/Dlls/using-thread-local-storage-in-a-dynamic-link-library) in the Windows SDK. Note that the sample contains an entry-point function called `LibMain`, but you should name this function `DllMain` so that it works with the MFC and C run-time libraries.
docs/build/run-time-library-behavior.md:168:[DllMain entry point](/windows/win32/Dlls/dllmain)<br/>
docs/build/reference/entry-entry-point-symbol.md:32:|**_DllMainCRTStartup**|A DLL; calls `DllMain` if it exists, which must be defined to use **`__stdcall`**|
docs/build/reference/entry-entry-point-symbol.md:36:The functions `main`, `WinMain`, and `DllMain` are the three forms of the user-defined entry point.
docs/build/reference/entry-entry-point-symbol.md:40:For information on how to define your own `DllMain` entry point, see [DLLs and Visual C++ run-time library behavior](../run-time-library-behavior.md) .
docs/build/reference/md-mt-ld-use-run-time-library.md:29:|**/LD**|Creates a DLL.<br /><br /> Passes the **/DLL** option to the linker. The linker looks for, but does not require, a `DllMain` function. If you do not write a `DllMain` function, the linker inserts a `DllMain` function that returns TRUE.<br /><br /> Links the DLL startup code.<br /><br /> Creates an import library (.lib), if an export (.exp) file is not specified on the command line. You link the import library to applications that call your DLL.<br /><br /> Interprets [/Fe (Name EXE File)](fe-name-exe-file.md) as naming a DLL rather than an .exe file. By default, the program name becomes *basename*.dll instead of *basename*.exe.<br /><br /> Implies **/MT** unless you explicitly specify **/MD**.|
docs/build/reference/gs-buffer-security-check.md:60:The **/GS** compiler option requires that the security cookie be initialized before any function that uses the cookie is run. The security cookie must be initialized immediately on entry to an EXE or DLL. This is done automatically if you use the default VCRuntime entry points: mainCRTStartup, wmainCRTStartup, WinMainCRTStartup, wWinMainCRTStartup, or _DllMainCRTStartup. If you use an alternate entry point, you must manually initialize the security cookie by calling [__security_init_cookie](../../c-runtime-library/reference/security-init-cookie.md).
docs/build/reference/atl-program-or-control-source-and-header-files.md:26:| *`dllmain.h`* | In DLL projects, the header file for the module class. |
docs/build/reference/atl-program-or-control-source-and-header-files.md:27:| *`dllmain.cpp`* | In DLL projects, the source file for the `DllMain` function. |
docs/build/reference/atl-program-or-control-source-and-header-files.md:46:| *`dllmain.h`* | In DLL projects, the header file for the module class. |
docs/build/reference/atl-program-or-control-source-and-header-files.md:47:| *`dllmain.cpp`* | In DLL projects, the source file for the `DllMain` function. |
docs/build/reference/clr-common-language-runtime-compilation.md:86:The global variables in a native object file are initialized first (during `DllMain` if the executable is a DLL), and then the global variables in the managed section are initialized (before any managed code is run). [`#pragma init_seg`](../../preprocessor/init-seg.md) only affects the order of initialization in the managed and unmanaged categories.
docs/build/reference/linker-support-for-delay-loaded-dlls.md:23:The delayed loading of a DLL can be specified during the build of either an EXE or DLL project. A DLL project that delays the loading of one or more DLLs itself shouldn't call a delay-loaded entry point in `DllMain`.
