Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

CoqBlog

.NET is good :-)
{ Blog de coq }

Actualités

.NET / Debug : inspection de la mémoire d'applications .NET (dump ou processus live) : première livraison d'une librairie .NET par Microsoft

Excellente nouvelle pour ceux qui ont besoin d'effectuer des analyses poussées et/ou automatiques de dumps d'application .NET : Microsoft nous livre une première beta d'une librairie .NET appelée Microsoft.Diagnostics.Runtime (ClrMD).
A noter qu'elle est estampillée "beta" mais de ce que j'en ai vu le niveau de qualité est très bon.

 

A quoi ça sert ?

Cela veut tout simplement dire qu'il y a maintenant moyen d'écrire des applications, en C#, permettant d'effectuer tout ou partie des tâches réalisables via des extensions du debugger (comme SOS, SOSEX, PSSCOR, ...), mais aussi bien plus encore.
Pour ne prendre que quelques exemples de tâches pour lesquelles les extensions actuelles ne sont pas forcément prévues :

  • extraire la liste complète des chaines de caractères présentes dans le dump, avec possibilité de filtrage par génération, longueur, valeur etc
  • extraire des statistiques de doublons de chaines de caractères présentes dans le dump
  • extraire des statistiques sur la répartition des objets par génération, leur ventilation sur les différentes heaps dans le cas d'un GC server, le nombre d'objets boxed présents sur la heap et leur répartition par génération, etc etc
  • ...
Je n'ai pas d'exemple de code à vous présenter dans l'immédiat, mais Lee Culver en fourni un à la fin de son post de présentation de ClrMD sur le blog MSDN de l'équipe .NET : .NET Crash Dump and Live Process Inspection - .NET Blog
Attention : à l'heure où j'écris ces lignes le sample comporte un petit bug, lisez bien les 2 premiers commentaires sur le post (ceci dit si vous ne les lisez pas vous vous apercevrez très vite du bug ;-))

Alors ? C# c'est quand même plus sympa comme language de script que du WinDbg-script, non ? ;-)

 

La fin de SOS, SOSEX & co ?

Je ne pense pas.
De mon point de vue cette librairie ne fait en rien de l'ombre aux extensions existantes comme l'excellente SOSEX de Steve Johnson, qui couvre bien d'autres besoins qu'il n'est pas forcément utile (ou possible) de recouvrir avec un code managé (sauf pour les besoins d'analyse automatisée, bien sûr).

 

Mes impressions

J'ai eu l'occasion d'utiliser ClrMD ces derniers jours sur des dumps, plutôt massifs, d'application .NET 4.0 et je dois dire que je suis plutôt content des possibilités offertes et des performances, surtout que cette librairie est sortie au moment où certains besoins d'analyse faisaient que je commençais à me demander s'il n'allait pas falloir que je me (re)mette au C/C++ pour tenter de développer une extension pour WinDbg...
Mon C/C++ étant (très) rouillé et le développement de ce type d'extension ciblant .NET n'étant apparemment pas des plus aisés* (mais je n'ai pas forcément encore suffisamment creusé le sujet), je suis très content de voir cette librairie apparaitre !

Et de toute façon, si le besoin se fait sentir, il est toujours possible d'utiliser l'API managée pour produire un fichier intermédiaire qui pourra être traité par un code non-managé sans avoir besoin de d'utiliser directement le dump depuis celui-ci.

En tout cas la mise à disposition de ClrMD me semble encourageante !
Depuis longtemps j'avais l'impression que Microsoft ne prenait pas correctement en compte la nécessité de fournir aux développeurs utilisant sa technologie .NET des moyens avancés utilisables via .NET permettant d'effectuer des analyses post-mortem, pas forcément couvertes par les moyens mis à disposition par l'éditeur lui-même au travers de Visual Studio ou de l'extension SOS (voire de PSSCOR) : il semble que les choses évoluent dans le bon sens avec la mise à disposition de cette librairie.

Une des premières phrases du post de Lee Culver semble en tout cas montrer la prise en compte de ces besoins :

"We understand that this API won’t be for everyone -- hopefully debugging .NET crash dumps is a rare thing for you. However, our .NET Runtime team has had so much success automating complex diagnostics tasks with this API that we wanted to release it publicly."

Au passage, il est fait mention des crash dumps, j'aurais parlé de dumps tout court : les dumps ne sont pas seulement intéressants pour les cas de crashes, loin de là !
En effet dans les cas où l'environnement de déploiement des applications n'est pas parfaitement maitrisé par l'éditeur et où l'analyse porte sur un comportement non reproduit en environnement de test, il n'est en général pas possible (ni souhaitable/souhaité) d'obtenir un accès administrateur temporaire à une machine vouée à retourner en production pour y utiliser un débuggeur (même s'il ne laisse pas de traces de son passage) : obtenir une série de dumps peut s'avérer plus facile car les développeurs n'ont pas besoin d'accès au serveur, et des outils comme ProcDump pouvant être "facilement" utilisés par les personnes gérant la production (en collaboration avec les développeurs, bien sûr).

J'ai bien conscience du fait que les développeurs du runtime .NET avaient sans doute envie de partager ce genre d'outils depuis longtemps (les développeurs ont tendance à aimer fournir des jouets à d'autres développeurs), je pense que la mise à disposition publique devait coincer à d'autres niveaux. Je ne connais pas très bien l'organisation interne de Microsoft sur ce type de décision, mais je suppose qu'il y a toujours un manager pour poser un tampon Yes/No (voire un passage par une section juridique) et je ne parle même pas de l'aspect budget : bref, je pense que cette mise à disposition publique est un bon signe pour l'avenir.

En tout cas j'espère que l'équipe recevra suffisamment de retours positifs pour les motiver à continuer sur cette lancée !

Bon coding/debug/analyse !

 

* : En plus d'après ce que je sais, avant l'apparition de la version 4.5 de l'API de debug du CLR, on ne pouvait pas énumérer les objets présents en mémoire, ce qui est légèrement génant : la documentation de ICorDebugProcess::EnumerateObjects arbore un joli "This method has not been implemented."
Ce problème serait maintenant résolu par l'apparition de ICorDebugProcess5::EnumerateHeap mais comme dit plus haut il m'est actuellement assez difficile de tester.

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 :
Posted: samedi 11 mai 2013 22:21 par coq
Classé sous : , ,

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Office 365: Nettoyage des versions de List Item avant migration depuis SharePoint On Premise vers SharePoint Online par Blog Technique de Romelard Fabrice le 08-08-2017, 15:36

- Office 365: Comment supprimer des éléments de liste SharePoint Online via PowerShell par Blog Technique de Romelard Fabrice le 07-26-2017, 17:09

- Nouveau blog http://bugshunter.net par Blog de Jérémy Jeanson le 07-01-2017, 16:56

- Office 365: Script PowerShell pour assigner des droits Full Control à un groupe défini par Blog Technique de Romelard Fabrice le 04-30-2017, 09:22

- SharePoint 20XX: Script PowerShell pour exporter en CSV toutes les listes d’une ferme pour auditer le contenu avant migration par Blog Technique de Romelard Fabrice le 03-28-2017, 17:53

- Les pièges de l’installation de Visual Studio 2017 par Blog de Jérémy Jeanson le 03-24-2017, 13:05

- UWP or not UWP sur Visual Studio 2015 ? par Blog de Jérémy Jeanson le 03-08-2017, 19:12

- Désinstallation de .net Core RC1 Update 1 ou SDK de Core 1 Preview 2 par Blog de Jérémy Jeanson le 03-07-2017, 19:29

- Office 365: Ajouter un utilisateur ou groupe dans la liste des Site collection Administrator d’un site SharePoint Online via PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-24-2017, 18:52

- Office 365: Comment créer une document library qui utilise les ContentTypeHub avec PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-22-2017, 17:06