DllMain et le verrou du chargeur — la vraie raison pour laquelle on vous dit de « ne rien faire dans l'initialisation d'une DLL »

« Lorsque nous chargeons notre propre DLL, LoadLibrary ne revient jamais. » « Cela ne se bloque que sur certains PC, ou seulement au démarrage du service. » Face à des pannes de ce type, l’un des premiers endroits à vérifier est le code d’initialisation de la DLL : DllMain et tout ce qu’il appelle.

DllMain n’est pas comme une fonction d’initialisation ordinaire d’une application. C’est une fonction que l’OS appelle en détenant le verrou du chargeur, donc ce qu’elle peut faire est fortement restreint. La position de Microsoft selon laquelle « le DllMain idéal est un stub vide » vient du fait que cette restriction n’affecte pas seulement votre propre DLL, mais les autres DLL et threads du processus.¹

Cet article s’adresse aux développeurs qui écrivent des DLL, des plug-ins et des wrappers C++/CLI sous Windows. Il traite le sujet dans cet ordre : pourquoi ça s’arrête, puis où déplacer l’initialisation, puis comment s’arrêter, puis comment investiguer un blocage.

1. La conclusion d’abord — garder DllMain petit et changer le moment d’exécution

Plutôt que de chercher une façon sûre d’écrire quelque chose à l’intérieur de DllMain, l’approche de base est de réduire le travail qui s’y exécute. Décidez ce qui y reste dans l’ordre suivant.¹

Ce qui est facile à manquer, c’est que les mêmes restrictions s’appliquent aux constructeurs et destructeurs des objets C++ globaux et statiques. En C++/CLI, vous éliminez aussi tout chemin qui exécute du MSIL sous le verrou du chargeur. Que le corps de DllMain lui-même soit vide ne suffit pas pour juger.²³

Si vous investiguez un blocage en ce moment, commencez au chapitre 7 ; si vous revoyez une conception, lisez les chapitres 2 à 6 dans l’ordre, et vous pourrez associer chaque interdiction à son remède.

2. Le mécanisme — DllMain est appelé à l’intérieur du verrou du chargeur

2.1 Il est appelé non seulement au chargement, mais aussi au démarrage et à la sortie des threads

DllMain est le point d’entrée que le chargeur de l’OS appelle lorsqu’une DLL entre dans un processus ou un thread, ou en sort. Il y a quatre notifications.²

Une notification de démarrage de thread ne va pas seulement à la DLL qui a créé le thread, mais à chaque DLL chargée dans le processus. DllMain n’est pas « du code qui s’exécute une fois lorsque ma DLL est chargée ». Dans un processus qui crée des threads fréquemment, il s’exécute à chaque notification.²

Si vous n’avez pas besoin des notifications, une option est d’appeler DisableThreadLibraryCalls à l’intérieur de DLL_PROCESS_ATTACH. Il ne peut toutefois pas être utilisé dans une DLL liée avec la CRT statique, et le TLS statique impose une condition propre, donc la section 5.3 traite cette décision à part.⁴

2.2 Être appelé en détenant le verrou est le point de départ de toutes les restrictions

Pour garder cohérents les chargements, déchargements et notifications de DLL, le chargeur de l’OS les sérialise avec un seul verrou du chargeur par processus. Le point important est qu’il acquiert ce verrou avant d’appeler DllMain et qu’il continue de le détenir pendant que DllMain s’exécute.¹

Pendant ce temps, tout autre thread du même processus qui essaie de charger une DLL ou de poursuivre une notification de démarrage ou de sortie de thread attend que le verrou soit libéré. Ce n’est pas un endroit où vous pouvez insérer une longue attente simplement parce que cela arrange votre propre DLL.

flowchart TB
    accTitle: Pourquoi le travail dans DllMain affecte les notifications de DLL dans tout le processus
    accDescr: Le chargeur acquiert le verrou du chargeur à l'échelle du processus avant d'appeler DllMain, et les chargements de DLL et les notifications de thread sur d'autres threads attendent sa libération, donc le travail dans DllMain affecte aussi les autres DLL et threads
    loader["Le chargeur acquiert le verrou partagé"] --> dll["DllMain s'exécute"]
    dll --> ret["DllMain revient"]
    ret --> unlock["Le verrou du chargeur est libéré"]
    other["Chargement de DLL ou notification sur un autre thread"] --> wait["Attend que le même verrou soit libéré"]
    unlock --> resume["Le travail en attente peut avancer"]
    wait --> resume

Figure 1 : le verrou partagé est détenu pendant que DllMain s’exécute, donc une attente à cet endroit arrête la progression des autres DLL et threads.

Les interdictions qui suivent deviennent compréhensibles une fois que vous demandez : « ce travail a-t-il besoin, directement ou indirectement, du verrou du chargeur ou de l’initialisation d’une autre DLL ? »

3. Pourquoi ça s’arrête — comprendre les interdictions par quatre chemins

3.1 Appeler un traitement qui charge une autre DLL

Évitez d’appeler LoadLibrary / FreeLibrary depuis DllMain. LoadLibrary crée des dépendances circulaires dans l’ordre de chargement et conduit à utiliser une DLL avant que son code d’initialisation n’ait tourné. Du côté de l’arrêt, il y a de même le risque d’utiliser une DLL déjà traitée ou libérée.²

Ne pas avoir écrit LoadLibrary vous-même ne vous rend pas sûr. Certaines fonctions User, Shell et COM chargent en interne d’autres composants système, et elles peuvent toucher un composant pas encore initialisé ou déjà libéré et provoquer une violation d’accès.²

La base de ce qui peut être appelé en sécurité, ce sont les fonctions de Kernel32.dll qui ne chargent pas d’autres DLL, car Kernel32.dll est garanti chargé au moment où DllMain s’exécute. Vous pouvez par exemple créer des objets de synchronisation tels que des sections critiques et des mutex, et utiliser le TLS. La documentation officielle indique toutefois explicitement qu’il n’existe aucune liste exhaustive de fonctions sûres. Ne raisonnez pas « c’est dans Kernel32, donc tout est permis » ni « je peux créer un objet de synchronisation, donc je peux attendre d’autres threads ».²

3.2 Attendre à l’intérieur de DllMain qu’un autre thread se termine

L’interblocage classique se produit au déchargement de la DLL : DllMain demande à un thread worker de s’arrêter, puis attend qu’il se termine.

Même après que le worker a fini son propre travail, il doit passer par la notification DLL_THREAD_DETACH à la sortie du thread. Cette notification a besoin du verrou du chargeur, que le DllMain en attente détient. Le résultat est que DllMain attend le worker, et le worker attend que DllMain revienne.⁵

sequenceDiagram
    accTitle: Pourquoi attendre un thread dans DllMain interbloque
    accDescr: DllMain, détenant le verrou du chargeur, attend qu'un thread worker se termine, mais le thread worker qui se termine attend que le verrou du chargeur soit libéré pour sa notification DLL_THREAD_DETACH, donc les deux s'attendent et interbloquent
    participant L as Chargeur (détient le verrou)
    participant D as DllMain
    participant W as Thread worker
    L->>D: Notifier DLL_PROCESS_DETACH
    D->>W: Demander la sortie et attendre l'achèvement
    W->>W: Finir le travail et se diriger vers la sortie du thread
    Note over W: La notification de sortie a besoin du verrou du chargeur
    Note over D,W: DllMain attend en détenant le verrou, W attend le verrou

Figure 2 : même après que le worker a fini son travail, il ne peut pas passer la notification de sortie de thread, donc l’attente de sortie à l’intérieur de DllMain ne se résout jamais.

Ce n’est pas un cas de « ça s’arrête si vous n’avez pas de chance » ; l’attente mutuelle tient structurellement. Le nettoyage nécessaire au déchargement est traité au chapitre 6, séparément du travail à la sortie du processus.

3.3 L’ordre d’acquisition de votre verrou et du verrou du chargeur s’inverse

Ce n’est pas seulement le démarrage et la sortie de thread ; des API telles que GetModuleHandle ont aussi besoin du verrou du chargeur en interne. Lorsque les deux chemins suivants se recouvrent, l’ordre d’acquisition des verrous s’inverse.⁶

• Du côté DllMain, du code qui détient déjà le verrou du chargeur essaie de prendre le verrou privé G.
• Du côté worker, du code qui détient déjà le verrou privé G appelle une API et essaie de prendre le verrou du chargeur.

flowchart TB
    accTitle: Inversion d'ordre entre le verrou du chargeur et un verrou privé
    accDescr: DllMain va chercher un verrou privé en détenant le verrou du chargeur, et un thread worker va chercher le verrou du chargeur, pour GetModuleHandle et analogues, en détenant le verrou privé, donc l'ordre d'acquisition s'inverse et ils interbloquent
    d["DllMain : détient le verrou du chargeur"] --> dg["Va chercher le verrou privé G"]
    w["Worker : détient le verrou privé G"] --> wl["Va chercher le verrou du chargeur"]
    dg -.-> dead["Interblocage par ordre d'acquisition inversé"]
    wl -.-> dead
    wl -.-> api["Exigé en interne par GetModuleHandle et d'autres"]

Figure 3 : lorsque l’un prend le verrou du chargeur puis G, et l’autre G puis le verrou du chargeur, chacun attend que l’autre libère.

Le guidage officiel demande de traiter le verrou du chargeur comme le sommet de la hiérarchie de verrous de l’application, c’est-à-dire le verrou acquis en premier. Au moment où vous êtes dans DllMain, ce verrou est déjà détenu. Vérifiez non seulement le nom de la fonction que vous appelez, mais aussi quels verrous vous détenez lorsque vous l’appelez.⁶

3.4 Même seulement créer un thread laisse des problèmes d’attente de démarrage et de durée de vie

CreateThread à l’intérieur de DllMain n’est pas recommandé non plus. Le nouveau thread ne peut pas commencer à exécuter sa fonction de thread tant que la notification DLL_THREAD_ATTACH n’a pas été traitée. Parce que le DllMain actuel détient le verrou du chargeur, attendre à l’intérieur de ce DllMain que le thread démarre ou se termine interbloque.⁵

Ne pas attendre ne résout pas tout non plus. Si la DLL est déchargée après le retour de DllMain mais avant que le thread que vous avez créé n’ait commencé à s’exécuter, l’adresse de démarrage du thread pointe vers du code déjà libéré, et un plantage reste possible.⁵

flowchart TB
    accTitle: Deux problèmes qui restent lorsqu'un thread est créé dans DllMain
    accDescr: Un thread créé dans DllMain attend le verrou du chargeur pour sa notification de démarrage, donc si DllMain attend son démarrage ou sa fin ils interbloquent, et même si DllMain revient sans attendre, la durée de vie du code s'arrête et il plante si la DLL est déchargée avant que le thread ne commence à s'exécuter
    create["Thread créé à l'intérieur de DllMain"] --> pending["Le nouveau thread attend la notification de démarrage"]
    pending --> q{"Attendre le démarrage ou l'achèvement à l'intérieur de DllMain ?"}
    q -->|"Oui"| dead["Attente mutuelle en détenant le verrou"]
    q -->|"Non"| returns["Retour depuis DllMain"]
    returns --> race["DLL déchargée avant que le thread ne commence à s'exécuter"]
    race --> crash["Le code à l'adresse de démarrage a disparu"]

Figure 4 : ne pas attendre à l’intérieur de DllMain et protéger la durée de vie de la DLL qu’utilise le thread créé sont deux exigences distinctes.

4. Deux endroits dangereux même lorsque DllMain est vide

4.1 Initialisation dynamique des objets globaux et statiques

Dans une DLL liée avec la CRT (le runtime C/C++), les constructeurs et destructeurs des objets C++ globaux et statiques s’exécutent via le point d’entrée de la CRT. Ils font effectivement partie de DllMain et sont soumis aux mêmes restrictions.²

Mettre le chargement d’un fichier de configuration, le démarrage d’un journal, l’initialisation COM ou le démarrage d’un thread dans un constructeur ne fait que cacher l’endroit de l’appel ; le moment où cela s’exécute reste à l’intérieur du verrou du chargeur. Si ce travail complexe inclut le chargement d’une autre DLL ou une synchronisation de threads, c’est exactement aussi dangereux que de l’écrire dans le corps de DllMain.

flowchart TB
    accTitle: Comment l'initialisation des objets globaux devient une mine
    accDescr: Le chargement de la DLL acquiert le verrou du chargeur et les constructeurs des objets globaux s'exécutent via la CRT, donc un LoadLibrary, une synchronisation de threads ou une initialisation COM à l'intérieur est une exécution de ce que DllMain interdit
    load["Chargement de la DLL (verrou du chargeur acquis)"] --> crt["Point d'entrée de la CRT"]
    crt --> ctor["Constructeur de l'objet global"]
    ctor --> ng1["Travail équivalent à LoadLibrary"]
    ctor --> ng2["Démarrer un thread et attendre qu'il se termine"]
    ctor --> ng3["Utilisation de COM ou de User32"]
    ng1 -.-> risk["Tout cela est une interdiction de DllMain"]
    ng2 -.-> risk
    ng3 -.-> risk

Figure 5 : revoyez non seulement le corps de DllMain, mais aussi l’initialisation et la terminaison des objets statiques appelés depuis la CRT.

Traitez l’initialisation constante à la compilation, par exemple tout ce qui peut être constexpr, séparément d’une initialisation d’exécution complexe. Différez l’initialisation dynamique qui implique des appels de fonction, et faites en sorte que le premier accès se produise aussi hors de DllMain.

4.2 MSIL exécuté dans une cible d’appel C++/CLI

L’encapsulation d’une DLL native en C++/CLI est traitée dans Appeler une DLL native depuis C# : wrapper C++/CLI vs P/Invoke. Dans cette configuration, surveillez les chemins qui exécutent du MSIL (code géré) sous le verrou du chargeur. Si l’exécution du MSIL exige l’initialisation du CLR ou le chargement d’un autre assemblage, un interblocage est possible.³

Le compilateur émet l’avertissement C4747 pour le code dans lequel DllMain essaie directement d’exécuter du MSIL. Mais il ne peut pas détecter une exécution indirecte à travers une fonction d’un autre module. L’absence de l’avertissement à elle seule n’est pas une base pour dire que le code est sûr. Les initialiseurs dynamiques des objets statiques sont aussi dans le périmètre.³

flowchart TB
    accTitle: Si l'exécution de MSIL sous le verrou du chargeur peut être détectée
    accDescr: Le code dans lequel DllMain exécute du MSIL directement peut être détecté par le compilateur avec l'avertissement C4747, mais une exécution indirecte à travers une fonction d'un autre module ne peut pas l'être, donc il faut la prévenir en revoyant l'arbre d'appels et en compilant nativement de bout en bout
    d2["Appel depuis DllMain"] --> dir["Exécute du MSIL directement"]
    d2 --> ind["Exécute via un autre module"]
    dir --> c47["Détecté par l'avertissement C4747"]
    ind --> nc["Le compilateur ne peut pas le détecter"]
    nc -.-> rv["Prévenir par revue et #pragma unmanaged"]

Figure 6 : en plus du chemin direct que C4747 détecte, revoyez aussi les appels qui passent par un autre module.

Le remède est de compiler DllMain et toute fonction atteignable depuis celui-ci en natif avec #pragma unmanaged, ou de ne pas avoir de DllMain du tout. Même dans ce dernier cas, ne manquez pas les chemins indirects tels que les initialiseurs statiques.³

5. Concevoir l’initialisation — la rendre statique, la différer, ne garder que le minimum

5.1 Avant de laisser quelque chose dans DllMain, demandez-vous si le moment d’exécution peut changer

La ligne de base officielle est de terminer à la compilation l’initialisation que vous pouvez et de différer le reste autant que possible. Seul le travail qui doit être détecté tôt comme un échec de chargement reste, à titre d’exception et au minimum.¹

Il peut par exemple y avoir l’exigence de faire échouer le chargement de la DLL elle-même parce qu’un fichier de configuration dont elle dépend est corrompu. Même alors, réduisez-le à « tenter le travail requis et échouer immédiatement » plutôt que de faire tourner d’abord d’autres initialisations et d’échouer ensuite. Ce n’est pas une exception qui autorise une initialisation complexe au chargement.¹

flowchart TB
    accTitle: Lignes directrices de conception pour l'initialisation d'une DLL
    accDescr: D'abord examiner si l'initialisation peut être statique à la compilation ; sinon, différer par défaut à la première utilisation, et ne laisser dans DllMain que le minimum qui doit être détecté tôt comme un échec de chargement
    q1{"Décidable à la compilation ?"} -->|"Oui"| s["En faire une initialisation statique"]
    q1 -->|"Non"| q2{"L'échec doit-il être détecté au chargement ?"}
    q2 -->|"Non"| lazy["Différer à la première utilisation (le défaut)"]
    q2 -->|"Oui"| min["Ne faire que le minimum dans DllMain"]
    lazy -.-> once["Protéger avec INIT_ONCE ou un static local à une fonction"]

Figure 7 : examinez d’abord l’initialisation statique et différée, et ne laissez dans DllMain que le minimum qui a besoin d’une détection précoce.

5.2 L’initialisation différée doit être conçue jusqu’à « qui l’appelle en premier »

Pour l’exclusion mutuelle à la première utilisation, vous pouvez utiliser une initialisation unique avec INIT_ONCE ou un static local à une fonction C++ (un static magique). L’idée est de déplacer les objets globaux complexes vers un pointeur créé au premier accès ou vers un static local à une fonction.

Différer seulement, toutefois, ne vous sort pas du verrou du chargeur. La restriction n’est levée que lorsque le premier accès vient d’« une API ordinaire appelée après que le chargement de la DLL est terminé ». Dans ce cas, on peut la concevoir comme une initialisation ordinaire qui peut utiliser presque toute l’API Windows.¹

Inversement, si ce premier accès se produit depuis DllMain ou un initialiseur statique, l’initialisation finit tout de même par s’exécuter sous le verrou du chargeur. Au-delà d’extraire une fonction d’initialisation, confirmez qui l’appelle en premier, et quand.

flowchart TB
    accTitle: Quand l'initialisation différée sort du verrou du chargeur
    accDescr: Si le premier accès de l'initialisation différée vient d'une API ordinaire après la fin du chargement, on peut initialiser hors du verrou du chargeur, mais s'il vient de DllMain ou d'un initialiseur statique, elle s'exécute sous les mêmes restrictions
    first{"D'où vient le premier accès ?"}
    first -->|"API ordinaire après la fin du chargement"| outside["Initialiser hors du verrou du chargeur"]
    first -->|"DllMain ou un initialiseur statique"| inside["Initialiser sous les mêmes restrictions"]
    outside --> once["Protéger avec INIT_ONCE ou un static local à une fonction"]
    inside --> move["Déplacer aussi le moment du premier accès"]

Figure 8 : INIT_ONCE et les statics locaux à une fonction s’occupent de l’exclusion mutuelle de l’initialisation ; ils ne garantissent pas qu’elle soit appelée hors du verrou du chargeur.

5.3 Décider de DisableThreadLibraryCalls selon trois conditions

Dans une DLL qui ne dépend pas des notifications de thread, appeler DisableThreadLibraryCalls dans DLL_PROCESS_ATTACH arrête les notifications DLL_THREAD_ATTACH / DLL_THREAD_DETACH. Dans un processus qui crée des threads fréquemment, cela réduit le surcoût des notifications.⁴

Avant de l’appliquer, vérifiez la CRT statique, le TLS statique, et si quelque chose utilise les notifications. Une DLL liée avec la CRT statique ne doit pas l’appeler, parce que la CRT elle-même a besoin des notifications de thread. Lorsque le TLS statique via thread_local ou __declspec(thread) est en vigueur, l’appel lui-même échoue et renvoie FALSE.⁴

flowchart TB
    accTitle: Décider d'appeler DisableThreadLibraryCalls
    accDescr: Une DLL liée avec la CRT statique ne doit pas l'appeler, et avec le TLS statique en vigueur l'appel lui-même échoue donc on ne l'appelle pas, mais une DLL qui n'est ni l'un ni l'autre et n'utilise pas les notifications de thread peut l'appeler dans DLL_PROCESS_ATTACH, en vérifiant la valeur de retour, pour réduire le coût des notifications
    q1{"Liée avec la CRT statique ?"} -->|"Oui"| no2["Ne doit pas l'appeler"]
    q1 -->|"Non"| q2{"Utilise le TLS statique ?"}
    q2 -->|"Oui"| eff["L'appel échoue de toute façon (FALSE)"]
    q2 -->|"Non"| q3{"A besoin des notifications de thread ?"}
    q3 -->|"Non"| yes["L'appeler dans ATTACH (vérifier la valeur de retour)"]
    q3 -->|"Oui"| keep["Ne pas l'appeler ; traiter les notifications"]

Figure 9 : distinguez la CRT statique, où il ne faut pas l’utiliser, du TLS statique, où il échoue, et vérifiez la valeur de retour même lorsque les notifications sont inutiles.

C’est une optimisation à considérer pour une DLL typique qui utilise la CRT liée dynamiquement et satisfait ces conditions. DisableThreadLibraryCalls existe pour réduire les notifications ; ce n’est pas un moyen de faire une initialisation complexe dans DllMain.

6. Arrêt — séparer le déchargement de la DLL de la sortie du processus

6.1 Le même DLL_PROCESS_DETACH, mais ce qui reste ensuite diffère

DLL_PROCESS_DETACH est délivré à la fois lorsque seule la DLL est déchargée et lorsque le processus entier se termine. La notification a le même nom, mais les prémisses du nettoyage diffèrent.⁵

Lors d’un déchargement via FreeLibrary, le processus continue ensuite. Donc les threads doivent être arrêtés, et les handles ouverts, les ressources allouées, l’état qui doit être persisté, etc., doivent être nettoyés correctement. Comme l’a montré la section 3.2, attendre à l’intérieur de DllMain la sortie naturelle d’un thread à cette fin interbloque toutefois.⁵

Mieux encore, évitez une conception dans laquelle une DLL qui peut être déchargée possède des threads ; déplacer la propriété des threads du côté de l’EXE est l’option la plus sûre. Pour une conception existante dans laquelle la DLL possède des threads, considérez le protocole d’arrêt suivant avec ses contraintes, jamais l’un sans l’autre.

6.2 Le protocole d’arrêt documenté officiellement lorsque la DLL possède un worker

Les meilleures pratiques de Microsoft documentent une procédure d’arrêt au déchargement qui attend non pas « la sortie naturelle du thread » mais « un signal qu’il a atteint un état cohérent ».⁵

1. Le côté DllMain signale au worker de s’arrêter, au moyen d’un événement.
2. Le worker ramène son travail en cours jusqu’à un état cohérent, signale l’achèvement et entre dans une attente infinie.
3. Le côté DllMain confirme l’état cohérent et termine le thread avec TerminateThread.

Cela a l’air brutal, mais c’est documenté sous la contrainte que attendre une sortie naturelle fait collisionner la notification de sortie avec le verrou du chargeur. La prémisse est que le travail d’atteindre l’état cohérent obéit aussi aux mêmes restrictions que DllMain. Si ce travail entre dans le chargement d’une autre DLL ou dans une attente du verrou du chargeur, un interblocage avec le côté qui attend le signal est inévitable.⁵

sequenceDiagram
    accTitle: Au déchargement, attendre l'achèvement de cohérence plutôt que la sortie naturelle
    accDescr: DllMain signale au worker de s'arrêter, le worker atteint un état cohérent en obéissant aux mêmes restrictions que DllMain, signale en retour et entre dans une attente infinie, et DllMain confirme l'état cohérent avant de terminer le thread
    participant D as DllMain (au déchargement)
    participant W as Thread worker
    D->>W: Signaler l'arrêt avec un événement
    W->>W: Atteindre un état cohérent sous les mêmes restrictions
    W->>D: Signaler que la cohérence est atteinte
    W->>W: Entrer dans une attente infinie
    D->>W: Confirmer la cohérence, puis TerminateThread
    Note over D,W: Ce qu'on attend est le signal de cohérence, pas la sortie naturelle

Figure 10 : même avec ce protocole, le travail qui établit l’état cohérent ne doit pas attendre le verrou du chargeur.

Cela ne signifie pas que n’importe quel thread en cours d’exécution peut simplement être coupé. Examinez d’abord si le thread peut être possédé hors de la DLL.

6.3 À la sortie du processus, l’idéal est de revenir sans rien faire

Au moment où DLL_PROCESS_DETACH est délivré à la sortie du processus, les autres threads se sont terminés ou ont été terminés de force, et on ne peut pas compter sur la cohérence de l’espace d’adresses. L’état des DLL et runtimes dépendants n’est pas non plus fiable, donc un nettoyage tel que libérer de la mémoire devient dangereux plutôt qu’utile. Le guidage officiel dit aussi que le gestionnaire idéal dans ce cas est vide.⁵

Écrivez les données qui doivent être persistées dans le propre code d’arrêt de l’application. N’utilisez pas DLL_PROCESS_DETACH comme le dernier endroit où tout peut encore être rangé.

flowchart TB
    accTitle: Les prémisses du nettoyage diffèrent entre déchargement de DLL et sortie de processus
    accDescr: Lorsque seule la DLL est déchargée, le processus continue donc les ressources doivent être nettoyées, mais évitez d'attendre la sortie naturelle à l'intérieur de DllMain ; à la sortie du processus, ne comptez pas sur la cohérence des autres threads et ressources, revenez essentiellement sans rien faire, et écrivez auparavant l'état à sauvegarder dans le code d'arrêt de l'application
    reason{"Raison de DLL_PROCESS_DETACH ?"}
    reason -->|"Déchargement de la DLL seulement"| alive["Le processus continue ensuite"]
    alive --> cleanup["Nettoyer correctement les ressources restantes"]
    cleanup -.-> nojoin["Ne pas attendre la sortie naturelle à l'intérieur de DllMain"]
    reason -->|"Sortie du processus"| processEnd["L'état des autres threads et ressources est incertain"]
    processEnd --> empty["Revenir essentiellement sans rien faire"]
    empty -.-> save["Sauvegarder auparavant dans le code d'arrêt de l'application"]

Figure 11 : décidez non seulement « un nettoyage est-il nécessaire », mais si le processus continue et si les ressources utilisées pour le nettoyage sont fiables.

7. Investiguer un blocage — trouver le côté qui attend le verrou du chargeur et le côté qui le détient

7.1 Confirmer dans un dump la paire de threads qui s’attendent

Capturez un dump au moment du gel et examinez la pile de chaque thread. L’empreinte typique est une paire : un thread qui attend un verrou à l’intérieur d’une fonction du chargeur dans ntdll.dll dont le nom commence par Ldr, et un thread qui attend autre chose à l’intérieur de DllMain ou d’un initialiseur statique (dynamic initializer).

Un thread arrêté au milieu d’un appel LoadLibrary est un autre participant typique. Une fois que la relation entre le côté qui attend le verrou et le côté qui le détient en attendant autre chose se connecte, vous pouvez presque certainement conclure qu’il s’agit d’un interblocage du verrou du chargeur.

flowchart TB
    accTitle: Confirmer une attente mutuelle du verrou du chargeur à partir d'un dump de blocage
    accDescr: Dans la pile de chaque thread, chercher une attente de verrou dans les fonctions Ldr et une attente à l'intérieur de DllMain ou d'un initialiseur statique, confirmer que les deux s'attendent, et si la paire typique n'apparaît pas, investiguer aussi d'autres types de blocage
    dump["Capturer un dump pendant le blocage"] --> stacks["Examiner la pile de chaque thread"]
    stacks --> ldr["Attente de verrou dans les fonctions Ldr"]
    stacks --> init["Attente à l'intérieur de DllMain ou d'un initialiseur statique"]
    ldr --> pair{"La relation d'attente mutuelle se connecte-t-elle ?"}
    init --> pair
    pair -->|"Oui"| found["Interblocage du verrou du chargeur"]
    pair -->|"Pas visible"| more["Investiguer aussi d'autres types de blocage"]

Figure 12 : ne décidez pas à partir d’une seule pile ; cherchez la paire du côté qui attend le verrou du chargeur et du côté qui le détient en attendant.

Des conditions telles que « occasionnellement au démarrage », « seulement sur une machine particulière » ou « seulement lorsqu’il est exécuté comme un service » sont aussi des indices. L’attente mutuelle se forme lorsqu’un chargement de DLL coïncide avec un démarrage ou une sortie de thread, donc les différences d’environnement et le moment d’exécution changent la façon dont elle apparaît.

7.2 Prévenir avec Application Verifier et la revue des cibles d’appel

Lancer des tests avec Application Verifier activé détecte à l’exécution les erreurs typiques de DllMain.¹ En C++/CLI, n’ignorez pas l’avertissement C4747, et vérifiez les chemins indirects que l’avertissement ne peut pas détecter du point de vue de la section 4.2.

Dans la revue, cherchez des fonctions qui appellent LoadLibrary indirectement parmi le travail atteignable depuis DllMain. L’initialisation COM, certaines fonctionnalités de la CRT et les imports à chargement différé (delay-load) sont des points à vérifier. En particulier, il est facile de manquer que le premier appel d’une fonction d’import à chargement différé devient un LoadLibrary en interne. Même si le nom de la fonction vit hors de DllMain, tant que l’appelant est DllMain, la restriction demeure.

8. Résumé — ne pas regarder le nom de la fonction, mais « quand, et sous quel verrou, ça s’exécute »

Les restrictions de DllMain se comprennent toutes à partir d’un seul point : il est appelé en détenant le verrou du chargeur à l’échelle du processus. Non seulement votre propre DllMain, mais aussi l’initialisation et la terminaison statiques de la CRT et les appels indirects de C++/CLI tombent dans le même périmètre.

Commencez une revue en demandant si l’initialisation peut être rendue statique et si le reste peut être différé jusqu’après la fin du chargement. Vérifiez jusqu’au premier accès du travail différé, et si les notifications sont inutiles, envisagez DisableThreadLibraryCalls après avoir vérifié les conditions de CRT statique et de TLS statique.

Du côté de l’arrêt, séparez un déchargement de la DLL seulement d’une sortie de tout le processus. Si la DLL possède un worker, suivez le protocole signal, vérification de cohérence et terminaison, et déplacez si possible la propriété des threads du côté de l’EXE. Rapprochez DllMain à la sortie du processus du vide, et placez la sauvegarde des données dans le propre code d’arrêt de l’application.

flowchart TB
    accTitle: L'ordre pour revoir DllMain et ce qu'il appelle
    accDescr: Examiner le périmètre en incluant non seulement DllMain mais l'initialisation statique et les appels indirects, déplacer l'initialisation vers le statique ou après le chargement, concevoir l'arrêt et le nettoyage selon la raison de l'arrêt, puis confirmer avec Application Verifier et des dumps
    scope["DllMain, initialisation statique et cibles d'appel"] --> timing["Déplacer l'initialisation vers le statique ou après le chargement"]
    timing --> first["Vérifier aussi le premier accès du travail différé"]
    first --> shutdown["Concevoir le nettoyage selon la raison de l'arrêt"]
    shutdown --> verify["Confirmer avec Verifier, avertissements et dumps"]

Figure 13 : suivre non seulement ce que fait l’initialisation, mais quand elle s’exécute et sa durée de vie à l’arrêt, permet de traiter les interdictions comme une seule politique de conception.

La question à poser dans un cas limite est : « ce travail est-il acceptable à exécuter en détenant le verrou du chargeur ? » Ne pas entasser dans DllMain une initialisation douteuse, et changer plutôt le moment où elle s’exécute, est le point de départ d’une conception de DLL sûre.

Articles connexes

• Comment fonctionne la résolution des noms de DLL sous Windows - Ordre de recherche et SxS
• Appeler une DLL native depuis C# : wrapper C++/CLI vs P/Invoke
• Bonnes pratiques de multithreading en pratique — édition C++ : éliminer les accidents structurellement avec RAII et jthread
• Réveils parasites — pourquoi les variables de condition se réveillent « sans avoir été notifiées » et comment attendre correctement sous Windows
• Lire un dump de plantage avec WinDbg + SOS — Guide pratique d’analyse après la collecte
• Les fondamentaux STA/MTA de COM - modèles de threads et comment éviter les blocages

Domaines de conseil associés

KomuraSoft LLC prend en charge l’investigation des causes profondes des blocages et interblocages au démarrage ou au chargement d’une DLL (analyse de dump), les revues de conception autour de DllMain et de l’initialisation statique, et la remédiation des wrappers C++/CLI et des DLL de plug-in vers une conception d’initialisation sûre. Vous pouvez nous consulter même au stade difficile à reproduire de « cela ne se bloque au démarrage que dans un environnement particulier ».

• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Peut-on vraiment ne rien faire du tout dans DllMain ?

« Ne rien faire » n'est pas une hyperbole ; c'est la politique de conception officielle, et Microsoft elle-même dit que le DllMain idéal est un stub quasi vide. Ce qui est sûr se limite aux fonctions de Kernel32.dll, qui est garanti chargé au moment où DllMain s'exécute, qui ne chargent pas d'autres DLL. Vous pouvez par exemple créer des sections critiques et des mutex, et utiliser le TLS. Inversement, LoadLibrary/FreeLibrary, la synchronisation avec d'autres threads et les appels vers User32, le Shell, COM et analogues sont interdits parce qu'ils provoquent des interblocages et des violations d'accès. Pour une initialisation dont vous n'êtes pas sûr, la bonne réponse n'est pas de la faire dans DllMain, mais de la différer jusqu'à la première utilisation.

Les constructeurs des globaux C++ (objets statiques) tombent-ils aussi sous les restrictions de DllMain ?

Ils le font. Lorsque la DLL est liée avec la CRT (le runtime C++), les constructeurs et destructeurs des objets globaux et statiques s'exécutent via le point d'entrée que la CRT fournit, effectivement comme une partie de DllMain. Appeler LoadLibrary dans un constructeur, démarrer un autre thread et attendre qu'il se termine, initialiser COM, etc., portent tous le même danger que de le faire dans DllMain. Pour les objets globaux à initialisation complexe, décalez le moment d'exécution hors de DllMain : gardez un pointeur et créez l'objet au premier accès, ou utilisez un static local à une fonction.

Dois-je appeler DisableThreadLibraryCalls ?

C'est utile sous conditions. Si la DLL n'a pas besoin des notifications DLL_THREAD_ATTACH/DETACH, appeler DisableThreadLibraryCalls dans DLL_PROCESS_ATTACH arrête la notification à chaque création et destruction de thread et réduit le surcoût dans un processus qui crée des threads fréquemment. Il y a toutefois deux exceptions. Ne l'appelez pas dans une DLL liée avec la CRT statique (la CRT statique a besoin des notifications de thread). Et lorsque le TLS statique via thread_local ou __declspec(thread) est en vigueur, l'appel lui-même échoue et renvoie FALSE, donc prenez l'habitude de vérifier la valeur de retour. Utilisez-le dans une DLL typique avec la CRT liée dynamiquement, après avoir confirmé que rien ne dépend des notifications de thread.

Pourquoi une DLL C++/CLI (mixte gérée) se bloque-t-elle au démarrage ?

La cause typique est d'essayer d'exécuter du MSIL (code géré) alors que le verrou du chargeur est détenu. Dans un assemblage mixte C++/CLI, si DllMain, les fonctions qu'il appelle ou les initialiseurs dynamiques des globaux sont compilés en MSIL, l'initialisation du CLR ou le chargement d'un autre assemblage devient nécessaire sous le verrou du chargeur, et cela peut interbloquer. Le compilateur émet l'avertissement C4747 lorsque DllMain essaie d'exécuter du MSIL directement, mais il ne peut pas détecter une exécution indirecte à travers un autre module. Le remède est de compiler DllMain et son arbre d'appels en natif avec #pragma unmanaged, ou de ne pas avoir de DllMain du tout.

Puis-je nettoyer des ressources dans DLL_PROCESS_DETACH ?

La réponse diffère entre « sortie de processus » et « déchargement via FreeLibrary ». Dans DLL_PROCESS_DETACH à la sortie du processus, les autres threads ont déjà été terminés de force et il n'y a aucune garantie que l'espace d'adresses soit cohérent, donc un nettoyage tel que libérer de la mémoire est en fait dangereux, et le guidage officiel est que « le gestionnaire idéal est vide ». Écrivez les données qui doivent être persistées dans le propre code d'arrêt de l'application, et dans le gestionnaire ne faites essentiellement rien et revenez. Lors d'un déchargement via FreeLibrary, au contraire, le processus continue, donc un nettoyage complet, comme arrêter les threads et fermer les handles, est requis. Attendre qu'un thread se termine à l'intérieur de DllMain interbloque toutefois, donc vous devez suivre le protocole que la documentation officielle décrit : signaler, attendre jusqu'à un état cohérent, et faire le travail final hors de DllMain.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.