.NET / Debug post-mortem : obtenir le fichier mscordacwks.dll correspondant à un dump quand on n'a plus d'accès direct à ce fichier
En général, si sur le moment la machine où la session de debug post-mortem à lieu ne dispose pas de la même version du CLR que la machine source, on récupère le fichier mscordacwks.dll sur la machine d'origine du dump.
Cependant, si la session de debugging à lieu plus tard ou si le dump est réutilisé par la suite, par exemple pour vérifier une théorie lorsqu'un problème similaire se produit, il est plus compliqué (pour ne pas dire impossible) de mettre la main sur une machine disposant encore de la bonne version du runtime.
Dans ce genre de cas, la méthode décrite par Sasha Goldshtein dans le post Obtaining mscordacwks.dll for CLR Versions You Don’t Have est une excellente solution : on récupère le fichier dans les setups qui permettent de les installer, qu'on peut localiser facilement grâce aux listes que maintient Doug Stewart pour faire le lien entre une version du CLR et le setup d'où elle provient :
Petit complément à l'article de Sasha Goldshtein
Si en utilisant 7-Zip ou même Universal Extractor vous vous retrouvez avec des fichiers inutilisables en sortie du fichier cab, tels que "_manifest_.cix.xml", "0", "1", "2", "3", ... (ce qui est notamment le cas en sortie des fichiers cab trouvés dans les fichiers .msu) le mieux est de plutôt passer par l'outil expand.exe pour extraire les fichiers de l'archive CAB.
Exemple pour ce patch :
md "Windows6.0-KB2572075-x86" & expand.exe -f:* Windows6.0-KB2572075-x86.cab Windows6.0-KB2572075-x86
Vous voilà parés pour assouvir votre passion pour l'archéologie ! ;-)
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
