Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

Extraction des binaires d’une application à partir d’un dump – debug avancé avec WinDBG

En cas de crash ou de mauvais fonctionnement d’une application en production, il est courant d’utiliser un dump afin de comprendre la cause du problème.

Un dump est une image mémoire du processus à un instant t. Celui-ci va contenir l’ensemble des informations du processus : le stack trace des différents threads, l’ensemble des variables du tas, etc … Pour en savoir plus sur les dump et windbg, je vous conseils les articles de Tess Fernandez -if broken it is, fix you should : .NET Debugging Demos - Information and setup instructions

Dans certains cas, il est intéressant de récupérer l’ensemble des assemblies chargées par l’application. A partir de ces binaires on peut effectuer une analyse plus précise du code grâce à Reflector par exemple. Ces fichiers sont présents dans les dumps.

Comment extraire ces fichiers ?

Pour lister ces fichiers, il faut d’abord charger le dump dans WinDBG (disponible ici : Debugging Tools for Windows). Puis, il faut utiliser la commande lm, cette commande permet de lister l’ensemble des modules chargés par l’application. La documentation sur la commande lm est disponible ici : [MSDN] lm (List Loaded Modules)

Exemple :

0:000> .loadby sos mscorkws
0:000> lm
start    end        module name
01110000 01134000   WebDev_WebServer20        (deferred)             
04740000 05238000   mscorlib_ni               (deferred)             
05c90000 05c98000   WebApplication23          (deferred)             
060e0000 06122000   SMDiagnostics_ni          (deferred)             
07440000 07448000   App_Web_8l9otbrp          (deferred)             
077b0000 079fe000   System_Web_Extensions_ni  (deferred)             
07a00000 07bc5000   System_Web_Services_ni    (deferred)
...

La première colonne correspond à l’adresse mémoire où est stocké le module, la troisième colonne correspond au nom du module.

L’une des options intéressante est l’option f. Cette option permet de connaitre le chemin complet d’où le module a été chargé.

Exemple :

0:000> lm f
start    end        module name
01110000 01134000   WebDev_WebServer20       C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\10.0\WebDev.WebServer20.exe
04740000 05238000   mscorlib_ni              C:\Windows\assembly\NativeImages_v2.0.50727_32\mscorlib\f58ab951b57c8526430486dcf7ee38fd\mscorlib.ni.dll
05c90000 05c98000   WebApplication23         C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\eaa0bd70\633d2a55\assembly\dl3\4d666377\583d14c9_f85ecb01\WebApplication23.DLL
060e0000 06122000   SMDiagnostics_ni         C:\Windows\assembly\NativeImages_v2.0.50727_32\SMDiagnostics\9de488bf62eebca425759ea94d9a70e8\SMDiagnostics.ni.dll
07440000 07448000   App_Web_8l9otbrp         C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\eaa0bd70\633d2a55\App_Web_8l9otbrp.dll
077b0000 079fe000   System_Web_Extensions_ni C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Web.Extensio#\0119cf02155b33d89fca6687c3e03705\System.Web.Extensions.ni.dll
07a00000 07bc5000   System_Web_Services_ni   C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Web.Services\ee24fe21a061801bb923bdc23c96388d\System.Web.Services.ni.dll
07fa0000 08274000   System_Data              C:\Windows\assembly\GAC_32\System.Data\2.0.0.0__b77a5c561934e089\System.Data.dll

Attention, si vous debuggez une application 32 bits sur un système 64 bits, WOW (Window On Window - la technologie Windows permettant d’exécuter des applications 32 bits sur un environnement 64 bits) sera utilisé par le système d’exploitation. Dans ce cas, les adresses mémoires ne seront pas les bonness, celles-ci seront préfixées par 0000000`. Il faut alors charger les extensions wow64 grâce à la command e.load wow64exts suivi de la commande !sw.

Exemple :

0:000> .load wow64exts
0:000> !sw
Switched to 32bit mode
0:000:x86> lm
...

La commande SaveModule permet d’extraire un module vers un fichier sur le disque dur. Le premier argument est l’adresse mémoire où est située le module, le second, le chemin où stocker le fichier.

Exemple :

0:000> !savemodule 05c90000 c:\tmp\WebApplication23.dll
3 sections in file
section 0 - VA=2000, VASize=774, FileAddr=200, FileSize=800
section 1 - VA=4000, VASize=390, FileAddr=a00, FileSize=400
section 2 - VA=6000, VASize=c, FileAddr=e00, FileSize=200

Le fichier peut alors être analysé avec Reflector.

Si vous souhaitez extraire tous les modules chargés par le processus, il faudra scripter windbg. Vous trouverez ci-dessous un exemple de script permettant d’extraire tous les modules dans le dossier c:\tmp\extract. Attention, ce dossier doit exister pour que windbg écrive les modules.

.foreach(moduleName {lm1m}) {   .foreach /pS 4 /ps 100 (address {lm m ${moduleName}}){     !SaveModule ${address} c:\tmp\extract\${moduleName}.dll   }
}

Ce script doit être enregistré dans le fichier c:\tmp\extract\script.txt. Pour l’exécuter, il faut alors utiliser la commande suivante dans WinDBG.

$><c:\tmp\extract\script.txt 
Posted: mardi 28 septembre 2010 16:59 par cyril
Classé sous : , , ,
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 :

Commentaires

coq a dit :

Sinon pour extraire tous les modules, pour du .NET 2.x/3.x comme dans ton exemple, tu peux utiliser la commande "SaveAllModules" de l'extension PSSCOR2 (http://blogs.codes-sources.com/coq/archive/2010/04/03/avis-aux-utilisateurs-de-sos-windbg-essayez-donc-psscor2.aspx) :-)

!SaveAllModules

<directory to="" save="">

!SaveAllModules will get all of the loaded modules in the process and write them to

to disk.  If you just want to save one module, you can use !SaveModule instead.

# septembre 28, 2010 19:12
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01

- SharePoint Online: Script PowerShell pour supprimer une colonne dans tous les sites d’une collection par Blog Technique de Romelard Fabrice le 11-27-2018, 18:01