Un DLL fantôme qui plante Windows : comment Microsoft a résolu l'énigme
Pourquoi ça compte pour toi
C'est un cas d'école fascinant si tu travailles sur du bas niveau ou que tu débogues des crashs Windows mystérieux. Ça montre comment une petite anomalie peut déclencher une boucle infinie d'exceptions qui paralyse le système. Et surtout, c'est une leçon sur la rigueur du débogage technique.
Ce qu'il faut retenir
- 1.Une DLL shell32 causait des crashs en déclenchant d'abord une exception d'accès mémoire (STATUS_ACCESS_VIOLATION) dans combase!CoTaskMemFree
- 2.Au lieu de planter simplement, le système s'est enfermé dans une boucle mortelle : exception → tentative de gestion → nouvelle exception → boucle infinie jusqu'au débordement de pile
- 3.Les traces de débogage montraient une pile entièrement composée de RtlDispatchException et KiUserExceptionDispatch qui se répétaient, signe classique d'une mort en spirale récursive
Tu galères avec le jargon ?
Lis la version réécrite en mode débutant — toutes les idées, sans le jargon.
Le symptôme : un débordement de pile inexplicable
L'équipe shell32 reçoit un signalement : leur DLL provoque des crashs massifs dans un programme tiers. Les dumps de crash montrent les signes classiques du débordement de pile : la même séquence d'appels de fonction se répète dans la pile des appels, encore et encore.
Les traces maudites
Dans les dumps critiques, tu vois apparaître une danse macabre :
- ▸
RtlLookupFunctionEntry→ chercher le bon gestionnaire d'exception - ▸
RtlDispatchException→ faire remonter l'exception - ▸
KiUserExceptionDispatch→ renvoyer l'exception en mode utilisateur
Et ça recommence. Des centaines de fois. Jusqu'au crash.
La mécanique du cauchemar
Voici ce qui s'est réellement passé :
- ▸
Première exception :
combase!CoTaskMemFreetente d'accéder à une adresse mémoire non exécutable. C'est une violation d'accès brute :STATUS_ACCESS_VIOLATION. - ▸
Réaction en chaîne : le noyau Windows ne sait pas gérer ça en mode noyau, il renvoie l'exception au mode utilisateur pour qu'un gestionnaire d'exception la capture.
- ▸
La boucle infernale : pendant que le système cherche quel code peut gérer cette exception (
RtlLookupFunctionEntry), il prend une nouvelle exception. Peut-être à cause d'un pointeur corrompu, d'une mémoire inaccessible, ou d'une corruption de la pile. - ▸
Spirale mortelle : la nouvelle exception relance le processus complet. Exception → recherche → nouvelle exception → exception → recherche… jusqu'à ce que la pile soit pleine.
C'est comme un algorithme sans condition d'arrêt : il récurse infiniment jusqu'à la mort.
Le détail révélateur
En remontant aux racines du crash, le débogueur retrouve enfin l'origine : combase!CoTaskMemFree au cœur du processus de nettoyage de shell32.dll.
L'adresse mémoire rapportée par le gestionnaire d'exception ? 00007ff9fcba0af0. Techniquement, elle pointe dans la zone mémoire où devrait être combase.dll, mais quand le système vérifie avec !address, le résultat est glaçant : MEM_FREE — la mémoire a été désallouée.
La DLL a beau être « chargée » en théorie, sa mémoire n'existe plus. D'où le titre de l'article original : une DLL non formellement déchargée, mais dont la mémoire a mystérieusement disparu.
À retenir
C'est un bug subtil qui mêle corruption mémoire, état des DLL et gestion d'exceptions — trois éléments qui interagissent de manière catastrophique. Pour les développeurs Windows : vérifiez vos déchargements de DLL et les pointeurs restants, sinon vous risquez exactement ce scénario.
Et concrètement pour toi ?
Choisis ton profil — la lecture de l'article change selon qui tu es.
Pour toi, l'enjeu c'est que Windows a géré son propre piège sans crash total grâce à des garde-fous : ça montre que même les systèmes critiques vivent avec des anomalies, l'important c'est de les détecter avant qu'elles se répliquent.
Source
📊 Cours en bourse
Pour aller plus loin
Cet article t'a donné envie d'approfondir ? Deux formations Noésis t'attendent :