Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article explique comment créer et afficher différents types de fichiers de vidage de mémoire Linux. Pour afficher les vidages de la mémoire sous Linux, vous devez disposer de WinDbg version 1.2402.24001.0 ou supérieure.
Lors de l’ouverture d’un core dump Linux, non Windows, dans WinDbg, les commandes de débogueur de base devraient toutes fonctionner correctement, mais les extensions et les commandes spécifiques à Windows qui référencent les structures Windows ne fonctionneront pas.
Fichiers de vidage de la mémoire pris en charge
Dumps du noyau Linux
Le débogueur Windows permet d'ouvrir des fichiers KDUMP compressés du noyau Linux et d'effectuer un débogage et une analyse post-mortem avec tous les symboles DWARF privés.
WinDbg prend uniquement en charge les fichiers KDUMP compressés ZLIB. Les fichiers KDUMP compressés au format LZO et Snappy ne sont pas pris en charge.
Pour des informations générales sur les Linux KDUMPs, voir la page Wikipédia KDump (Linux) et Core dump.
Dumps du noyau ELF
Dans le cadre de la prise en charge d'Open Enclave, WinDbg peut ouvrir des dumps ELF et des fichiers binaires, ainsi que des symboles DWARF (DWARF 5 n'est pas pris en charge) provenant d'Enclaves et d'applications Linux. Pour plus d’informations sur Open Enclave, consultez Débogage d’Open Enclave.
Dumps de processus
Les dumps de processus uniques sont pris en charge. Il existe plusieurs façons de collecter un vidage de processus, notamment l’utilitaire Linux Sysinternals ProcDump pour Linux . Une autre option consiste à utiliser le débogueur GNU - GDBServer pour générer un core dump. Pour plus d’informations sur GDBServer, consultez https://en.wikipedia.org/wiki/Gdbserver. La documentation relative au débogage gdb distant est disponible sur le site web Sourceware - Débogage de programmes distants.
Activer la visualisation NATVIS Linux et la traversée de liens DML
L’extensibilité de la bibliothèque de modèles standard (STL) dans les débogueurs Windows est fournie par un fichier NatVis, stl.natvis qui comprend de nombreuses versions de la stl fournie avec Visual Studio et Windows. Pour obtenir des informations générales sur NATVIS, consultez Objets débogueur natifs dans NatVis. Les versions de stl utilisées pour les composants Linux (GCC ou LLDB) sont très différentes.
Pour activer la visualisation NATVIS et le parcours de liaison DML optimisés pour Linux, commencez par décharger le fichier natvis par défaut, .scriptunloadstl.natvis.
Ensuite, chargez le fichier gstl.natvis à l'aide de la commande .scriptload. Utilisez .scriptlist pour confirmer qu’il gstl.natvis est actif.
0: kd> .scriptlist
Command Loaded Scripts:
...
NatVis script from 'C:\Users\Bob\AppData\Local\dbg\UI\2402.24001.0\amd64\Visualizers\gstl.natvis'
Pour plus d’informations sur l’utilisation de DML, consultez Personnalisation de la sortie du débogueur à l’aide de DML.
Dump du noyau d'un processus unique de l'application DisplayGreeting
Cet exemple montre comment créer un vidage de mémoire d'un processus unique en utilisant gdb. Pour plus d’informations sur l’utilisation de GDBServer avec WinDbg et un aperçu détaillé du code, consultez débogage de processus à distance en direct sous Linux. Pour obtenir l’exemple de code pour DisplayGreeting, consultez la procédure pas à pas de l’application C++.
Localiser le processus souhaité
Nous pouvons répertorier tous les processus dans Linux à l’aide de la ps -A commande ou utiliser l’option -f avec pgrep, car nous savons que nous recherchons l’application DisplayGreeting.
$ pgrep -f DisplayGreeting
9382
Dans cet exemple de procédure pas à pas, il affiche un ID de processus de 9382.
Attacher au processus avec gdb et générer un core dump
Utilisez gdb pour l’attacher au processus.
$ gdb -p 9382
Affichez l'aide pour la commande generate-core-file gdb.
(gdb) help generate-core-file
Save a core file with the current state of the debugged process.
Argument is optional filename. Default filename is 'core.<process_id>'.
À l'invite (gdb), générez un fichier de vidage de la mémoire centrale du processus avec le nom de fichier par défaut.
(gdb) generate-core-file
Saved corefile core.9382
(gdb) quit
Charger et examiner le dump du processus Linux
Utilisez l’option de menu Ouvrir le fichier de vidage dans WinDbg pour charger le vidage principal généré.
Ajouter les chemins d’accès aux sources et aux symboles à la session de débogage
Pour afficher le code source et les variables, définissez les symboles et le chemin d’accès source. Pour obtenir des informations générales sur la définition du chemin des symboles, consultez Utilisation de symboles. Pour plus d’informations sur les symboles Linux, consultez les symboles et sources Linux.
Utilisez .sympath pour ajouter le chemin d’accès au symbole à la session du débogueur. Dans cet exemple Ubuntu WSL Linux, le code et les symboles DisplayGreetings sont disponibles à cet emplacement, pour un utilisateur nommé Bob.
\\wsl$\Ubuntu\mnt\c\Users\Bob\
Dans WSL, ce répertoire est mappé à l’emplacement du système d’exploitation Windows : C:\Users\Bob\ ces deux commandes sont donc utilisées.
.sympath C:\Users\Bob\
.srcpath C:\Users\Bob\
Pour plus d’informations sur l’accès au système de fichiers WSL dans Windows, consultez Autorisations de fichier pour WSL.
Pour bénéficier de symboles de système d’exploitation Linux supplémentaires, ajoutez les symboles DebugInfoD à l’aide de l’emplacement .sympath.
.sympath+ DebugInfoD*https://debuginfod.elfutils.org
Utilisez la .reload commande pour recharger les symboles.
Il est également pris en charge le téléchargement automatique de sources à partir de serveurs DebugInfoD, qui prennent en charge le retour de ce type d’artefact. Pour tirer parti de cette fonctionnalité, ajoutez le serveur elfutils à l’aide de .srcpath.
.srcpath+ DebugInfoD*https://debuginfod.elfutils.org
Examen du dump du processus
Utilisez la lm commande pour confirmer que le fichier de vidage contient l’application DisplayGreeting.
0:000> lm
start end module name
00005555`55554000 00005555`55558140 DisplayGreeting T (service symbols: DWARF Private Symbols) c:\users\bob\DisplayGreeting
00007fff`f7a54000 00007fff`f7a732e8 libgcc_s_so (deferred)
00007fff`f7a74000 00007fff`f7b5a108 libm_so (deferred)
00007fff`f7b5b000 00007fff`f7d82e50 libc_so T (service symbols: DWARF Private Symbols) C:\ProgramData\Dbg\sym\_.debug\elf-buildid-sym-a43bfc8428df6623cd498c9c0caeb91aec9be4f9\_.debug
00007fff`f7d83000 00007fff`f7fae8c0 libstdc___so (deferred)
00007fff`f7fc1000 00007fff`f7fc1000 linux_vdso_so (deferred)
00007fff`f7fc3000 00007fff`f7ffe2d8 ld_linux_x86_64_so T (service symbols: DWARF Private Symbols) C:\ProgramData\Dbg\sym\_.debug\elf-buildid-sym-9718d3757f00d2366056830aae09698dbd35e32c\_.debug
Notez que la première exécution de commande peut prendre un peu de temps, car les symboles de débogage sont chargés dans le cache. En plus de rechercher des symboles et des fichiers binaires via le serveur de symboles ou votre chemin de recherche local, en raison de l’intégration de GDBServer, il peut charger ces fichiers à partir d’un système de fichiers distant s’ils ne sont pas trouvés localement. Cette opération est généralement plus lente que l’acquisition de symboles à partir de symsrv ou d’un chemin de recherche local.
Utilisez la x commande pour afficher les fonctions disponibles dans DisplayGreeting.
0:000> x /D /f DisplayGreeting!*
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
*** WARNING: Unable to verify timestamp for DisplayGreeting
00005651`7935b331 DisplayGreeting!_GLOBAL__sub_I__Z17GetCppConGreetingPwm (void)
00005651`7935b2db DisplayGreeting!__static_initialization_and_destruction_0 (int, int)
00005651`7935b37b DisplayGreeting!std::__array_traits<wchar_t, 50>::_S_ptr (wchar_t (*)[50])
00005651`7935b368 DisplayGreeting!std::array<wchar_t, 50>::size (std::array<wchar_t, 50> *)
00005651`7935b34a DisplayGreeting!std::array<wchar_t, 50>::data (std::array<wchar_t, 50> *)
00005651`7935b225 DisplayGreeting!main (void)
00005651`7935b1e9 DisplayGreeting!GetCppConGreeting (wchar_t *, size_t)
Utilisez la dx commande pour afficher le message d’accueil de la variable locale.
0:000> dx greeting
...
Error: Unable to bind name 'greeting'
Comme le paramètre greeting n'était pas encore utilisé lors de la création du dump, il n'est pas disponible dans le fichier dump.
Utilisez la dx commande pour examiner les processus disponibles dans le fichier de vidage.
:000> dx @$cursession.Processes.Take(30)
@$cursession.Processes.Take(30)
[0x24a6] : DisplayGreeting [Switch To]
Click on the `[Switch To]` DML link to switch to the 9382 process.
```dbgcmd
0:000> dx -s @$cursession.Processes.Take(30)[9382].SwitchTo()
0:000> dx -r1 @$cursession.Processes.Take(30)[9382]
@$cursession.Processes.Take(30)[9382] : DisplayGreeting [Switch To]
Name : DisplayGreeting
Id : 0x24a6
Index : 0x0
Handle : 0x24a6
Threads
Modules
Environment
Direct3D
Attributes
Devices
Io
Memory
TTD
GroupedStacks
Pour afficher des informations sur les threads et les modules, cliquez sur le lien DML généré dans la sortie ou tapez des commandes similaires à celle-ci pour votre vidage de la mémoire.
0:000> dx -r1 @$cursession.Processes.Take(30)[9382].Threads
@$cursession.Processes.Take(30)[9382].Threads
[0x24a6] [Switch To]
0:000> dx -r1 @$cursession.Processes.Take(30)[9382].Modules
@$cursession.Processes.Take(30)[9382].Modules
[0x0] : /mnt/c/Users/Bob/DisplayGreeting
[0x1] : /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
[0x2] : /usr/lib/x86_64-linux-gnu/libm.so.6
[0x3] : /usr/lib/x86_64-linux-gnu/libc.so.6
[0x4] : /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30
[0x5] : /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
[0x6] : linux-vdso.so.1
Utilisez les extensions de diagnostic ELF/CORE pour afficher les informations du fichier dump.
Veuillez utiliser les extensions de diagnostic Linux - ELFBinComposition.dll pour afficher les informations du fichier dump. Par exemple, utilisez !dumpdebug pour confirmer qu’il s’agit d’un core dump utilisateur ELF et afficher des informations supplémentaires.
0:000> !dumpdebug
Dump Diagnostics: Format = ELF User Core
********************************************************************************
File Mapping Size: 0x151d78 (1 Mb)
Highest Memory Offset: 0x14e5f0 (1 Mb)
...
Utilisez !ntprpsinfo pour afficher les données NT_PRPSINFO.
0:000> !ntprpsinfo
NT_PRPSINFO (process info):
state: 0, sname: t, zomb: 0, nice: 0, flag: 0x4040000019999999
uid: 1000, gid: 1000, pid: 9382, ppid: 388, pgrp: 9382, sid: 388
fname: DisplayGreeting
psargs: ./DisplayGreeting
Vidage de la mémoire par le noyau KDump
Il existe plusieurs méthodes pour créer un fichier de vidage de la mémoire sous Linux. Par exemple, une option sous Ubuntu Linux est décrite dans Vidage de la mémoire du noyau.
D’autres options incluent l’utilisation de kexectools pour activer Kdump. Pour plus d’informations, consultez KDump (Linux). Si kdump est activé, vous pouvez vérifier que kdump est actif et en cours d’exécution à l’aide systemctl status kdumpde .
Une fois que le plantage du système d'exploitation est déclenché sur un système de test, le fichier de vidage de la mémoire est créé.
Charger et examiner le vidage de la mémoire du système d'exploitation Linux
Utilisez l’option de menu Ouvrir le fichier de vidage pour charger le kdump généré.
Comme décrit dans la section précédente, activez la visualisation NATVIS et la traversée de liens DML optimisées pour Linux, en chargeant le gstl.natvis fichier.
Utiliser les commandes de composition ELF Bin pour analyser un vidage du noyau Linux
Pour pouvoir utiliser d’autres commandes de composition ELF Bin, utilisez la commande .chain pour confirmer que le ELFBinComposition.dll est chargé.
0: kd> .chain
Extension DLL chain:
ELFBinComposition: image 10.0.27606.1000, API 0.0.0,
[path: C:\Users\Bob\AppData\Local\dbg\UI\Fast.20240423.1\amd64\winext\ELFBinComposition.dll]
...
Si ELFBinComposition n’est pas chargé, utilisez .load pour le charger. Pour plus d’informations, consultez .load, .loadby (DLL d’extension de chargement)
Utilisez la !ELFBinComposition.dumpdebug commande pour afficher des informations sur le fichier de vidage chargé. Dans cet exemple, un fichier de dump du noyau utilisateur ELF a été chargé.
0: kd> !ELFBinComposition.dumpdebug
Dump Diagnostics: Format = Kernel KDump
********************************************************************************
File Mapping Size: 0x3b34090 (59 Mb)
Highest Memory Offset: 0x3b34090 (59 Mb)
Utilisez ELFBinComposition !vmcoreinfo pour afficher la table VMCOREINFO à partir du dump du noyau Linux (KDUMP) en cours de débogage.
0: kd> !vmcoreinfo
VMCOREINFO:
OSRELEASE=6.5.0-25-generic
BUILD-ID=8567ad7c7c2f78f3654f6cc90a9e1b3f9c3a4b32
PAGESIZE=4096
SYMBOL(init_uts_ns)=ffffded86e11b388
OFFSET(uts_namespace.name)=0
SYMBOL(node_online_map)=ffffded86dcceb40
SYMBOL(swapper_pg_dir)=ffffded86d143000
SYMBOL(_stext)=ffffded86ace0000
SYMBOL(vmap_area_list)=ffffded86de48140
SYMBOL(mem_section)=ffff0f2e1efe4600
LENGTH(mem_section)=8192
...
Utilisez le !kdumppagerange pour vider la première partie du fichier de vidage, en commençant à zéro.
0: kd> !kdumppagerange 0
PFNs [0x540e0, 0x55643) -> Descs [0x0, 0x1563): File Offsets [0x307430, 0xeeb37a) 0xbe3f4a bytes across 5475 pages as ZLIB
PFNs [0x55643, 0x55650) -> Descs [0x1563, 0x1570): File Offsets [0x306430, 0x307430) 0x1000 bytes across 13 duplicate pages as Uncompressed
PFNs [0x55650, 0x556d6) -> Descs [0x1570, 0x15f6): File Offsets [0xeeb37a, 0xf0c405) 0x2108b bytes across 134 pages as ZLIB
PFNs [0x556d6, 0x556dc) -> Descs [0x15f6, 0x15fc): File Offsets [0xf0c405, 0xf12405) 0x6000 bytes across 6 pages as Uncompressed
PFNs [0x556dc, 0x55e98) -> Descs [0x15fc, 0x1db8): File Offsets [0xf12405, 0x1216d1b) 0x304916 bytes across 1980 pages as ZLIB
PFNs [0x55e98, 0x55ea4) -> Descs [0x1db8, 0x1dc4): File Offsets [0x1216d1b, 0x1222d1b) 0xc000 bytes across 12 pages as Uncompressed
PFNs [0x55ea4, 0x56542) -> Descs [0x1dc4, 0x2462): File Offsets [0x1222d1b, 0x14ba138) 0x29741d bytes across 1694 pages as ZLIB
PFNs [0x56542, 0x56543) -> Descs [0x2462, 0x2463): File Offsets [0x306430, 0x307430) 0x1000 bytes across 1 pages as Uncompressed
PFNs [0x56543, 0x56544) -> Descs [0x2463, 0x2464): File Offsets [0x14ba138, 0x14ba194) 0x5c bytes across 1 pages as ZLIB
PFNs [0x56544, 0x5654f) -> Descs [0x2464, 0x246f): File Offsets [0x306430, 0x307430) 0x1000 bytes across 11 duplicate pages as Uncompressed
La sortie de !kdumppagerange affiche différentes valeurs de cadre de page (PFN). Nous pouvons sélectionner un élément d'intérêt et utiliser le !kdumppfn <PFN> pour afficher des informations sur le PFN et l'endroit de ses données dans le KDUMP.
0: kd> !kdumppfn 0x540e0
Page frame 0x540e0 = File offset [0x307430, 0x307b9f) 0x76f bytes as ZLIB...
Veuillez examiner le fichier dump.
Utilisez la k commande pour afficher la pile des appels pour examiner le code en cours d’exécution lorsque le blocage s’est produit.
6: kd> k
# Child-SP RetAddr Call Site
00 ffff0000`0bc3bc90 ffff0000`085161f8 vmlinux!sysrq_handle_crash+0x24 [/usr/src/kernel/drivers/tty\sysrq.c @ 147]
01 ffff0000`0bc3bca0 ffff0000`08516824 vmlinux!__handle_sysrq+0x88 [/usr/src/kernel/drivers/tty\sysrq.c @ 583]
02 ffff0000`0bc3bcb0 ffff0000`08308990 vmlinux!write_sysrq_trigger+0xb4 [/usr/src/kernel/drivers/tty\sysrq.c @ 1110]
03 ffff0000`0bc3bcf0 ffff0000`08290070 vmlinux!proc_reg_write+0x80 [/usr/src/kernel/fs/proc\inode.c @ 245]
04 ffff0000`0bc3bd10 ffff0000`0829039c vmlinux!__vfs_write+0x60 [/usr/src/kernel/fs\read_write.c @ 490]
05 ffff0000`0bc3bd50 ffff0000`08290704 vmlinux!vfs_write+0xac [/usr/src/kernel/fs\read_write.c @ 550]
06 ffff0000`0bc3be00 ffff0000`082907a4 vmlinux!ksys_write+0x74 [/usr/src/kernel/fs\read_write.c @ 599]
07 (Inline Function) --------`-------- vmlinux!__do_sys_write+0xc [/usr/src/kernel/fs\read_write.c @ 608]
08 (Inline Function) --------`-------- vmlinux!__se_sys_write+0xc [/usr/src/kernel/fs\read_write.c @ 608]
09 ffff0000`0bc3be40 ffff0000`08095904 vmlinux!__arm64_sys_write+0x24 [/usr/src/kernel/fs\read_write.c @ 608]
0a ffff0000`0bc3be90 ffff0000`080834c8 vmlinux!el0_svc_handler+0x94
0b ffff0000`0bc3beb0 00000000`00000000 vmlinux!el0_svc+0x8
Utilisez la commande dx pour examiner le fichier dump. Par exemple, examinez les 30 premiers processus à l’aide de cette commande.
6: kd> dx @$cursession.Processes.Take(30)
@$cursession.Processes.Take(30)
[0x0] : swapper/0 [Switch To]
[0x1] : systemd [Switch To]
[0x2] : kthreadd [Switch To]
[0x3] : rcu_gp [Switch To]
[0x4] : rcu_par_gp [Switch To]
[0x5] : kworker/0:0 [Switch To]
[0x6] : kworker/0:0H [Switch To]
[0x7] : kworker/u16:0 [Switch To]
[0x8] : mm_percpu_wq [Switch To]
[0x9] : ksoftirqd/0 [Switch To]
[0xa] : rcu_sched [Switch To]
[0xb] : rcu_bh [Switch To]
[0xc] : migration/0 [Switch To]
...
Cliquez sur les liens DML ou utilisez des commandes similaires à celles-ci pour examiner les threads sur un processus d’intérêt.
6: kd> dx @$cursession.Processes[0x1a].Threads
@$cursession.Processes[0x1a].Threads
[0x1a] [Switch To]
6: kd> dx @$cursession.Processes[0x1a].Threads[0x1a]
@$cursession.Processes[0x1a].Threads[0x1a] [Switch To]
KernelObject [Type: thread_struct]
Id : 0x1a
Stack
Registers
Environment
Analysis
WaitChain
Scheduling
IRPs
...
Des informations supplémentaires pour chaque thread sont disponibles, comme indiqué ci-dessous.
6: kd> dx @$cursession.Processes[0x1a].Threads[0x1a].KernelObject
@$cursession.Processes[0x1a].Threads[0x1a].KernelObject [Type: thread_struct]
[+0x000] cpu_context [Type: cpu_context]
[+0x070] uw [Type: <unnamed-tag>]
[+0x290] fpsimd_cpu : 0x100 [Type: unsigned int]
[+0x298] sve_state : 0x0 [Type: void *]
[+0x2a0] sve_vl : 0x0 [Type: unsigned int]
[+0x2a4] sve_vl_onexec : 0x0 [Type: unsigned int]
[+0x2a8] fault_address : 0x0 [Type: long unsigned int]
[+0x2b0] fault_code : 0x0 [Type: long unsigned int]
[+0x2b8] debug [Type: debug_info]
6: kd> dx -s @$cursession.Processes[0x1a].Threads[0x1a].SwitchTo()
Process ffff8008`0f894380 has invalid page directories
Utiliser le script LinuxKernel.js pour analyser un vidage du noyau Linux
L’extension de débogueur LinuxKernel.js contient un ensemble de commandes conçues pour fonctionner de la même façon que celles trouvées dans l’utilitaire d’incident Linux utilisée pour ouvrir et analyser les blocages du mode noyau Linux.
Pour utiliser le script, chargez d’abord le script.
0: kd> .scriptload LinuxKernel.js
JavaScript script successfully loaded from 'C:\Users\Bob\AppData\Local\dbg\UI\Fast.20240423.1\amd64\winext\LinuxKernel.js'
Pour plus d’informations sur l’utilisation des scripts de chargement, consultez le scriptage du débogueur JavaScript.
!files
Utilisez l’option !files pour afficher des informations sur la structure de fichiers Linux dans le fichier de vidage. Elle est similaire à la commande crash files.
6: kd> !files
@$files() : Files for process 'sh' (pid 545) root dir = '/' working dir = '/home/root'
[0x0] : /dev/ttyS0 [Type: file]
[0x1] : /proc/sysrq-trigger [Type: file]
[0x2] : /dev/ttyS0 [Type: file]
[0xa] : /dev/ttyS0 [Type: file]
[0xff] : /dev/ttyS0 [Type: file]
Syntaxe !files :
!files [<arg>]
Sans [<arg>]- Équivalent à « fichiers » - donne la liste des fichiers de processus en cours
[<arg>]:
pid - Donne la liste des fichiers pour l’ID de processus donné
64-bit num - Donne la liste des fichiers pour la tâche à l’adresse donnée
<task struct [*]> - Fournit la liste des fichiers pour la structure de tâche spécifiée par objet
<process object> - Donne la liste de fichiers pour la tâche représentée par l’objet de processus
!mount
Utilisez l’option !mount pour afficher des informations sur la structure de fichiers Linux dans le fichier de vidage.
6: kd> !mount
@$mount()
[0x0] : (rootfs) rootfs at / [Type: mount]
[0x1] : (squashfs) /dev/mapper/nested_rootfs at / [Type: mount]
[0x2] : (sysfs) sysfs at /sys [Type: mount]
[0x3] : (proc) proc at /proc [Type: mount]
[0x4] : (devtmpfs) devtmpfs at /dev [Type: mount]
[0x5] : (securityfs) securityfs at /kernel/security [Type: mount]
Syntaxe !mount :
Sans [<arg>]- Équivalent à la commande « mount » - affiche les systèmes de fichiers montés
[<arg>]:
pid - Renvoie les systèmes de fichiers montés pour l'espace de noms du processus avec le pid spécifié.
64-bit num - Renvoie les systèmes de fichiers montés pour l'espace de noms de la structure task_struct indiquée par l'adresse.
<task struct [*]> - Donne les systèmes de fichiers montés pour l’espace de noms du task_struct donné
<process object> - Renvoie les systèmes de fichiers montés pour l'espace de noms de la tâche représentée par le processus.
!net
Utilisez l’option !net pour afficher la liste réseau système.
6: kd> !net
@$net()
[0x0] : lo (127.0.0.1) [Type: net_device]
[0x1] : enP8p1s0f0np0 (192.168.3.19) [Type: net_device]
[0x2] : enP8p1s0f1np0 [Type: net_device]
Syntaxe !net :
!net [<arg>]
Sans [<arg>] - Équivalent à 'net' - donne la liste des réseaux du système
[<arg>]:
pid - Fournit la liste réseau du namespace du processus identifié par le pid spécifié.
64-bit num - Donne la liste des nœuds pour l'espace de noms de la structure task_struct donnée par l'adresse.
<task struct [*]> - Fournit la liste des réseaux pour le namespace du task_struct donné
<process object> - Fournit la liste des nœuds pour l'espace de noms de la tâche représentée par le processus.
!runq
Utilisez l’option !runq pour afficher des informations sur les tâches de la file d’attente d’exécution.
0: kd> !runq
@$runq()
[0x0] : CPU 0 run queue [current = 'bash' (17ca)]
Cpu : 0x0
RunQueue [Type: rq]
CurrentTask : bash [Type: task_struct]
RTTasks
CfsTasks
[0x16b3] : kworker/0:7 [Type: task_struct]
[0x1] : CPU 1 run queue [current = 'swapper/1' (0)]
Cpu : 0x1
RunQueue [Type: rq]
CurrentTask : swapper/1 [Type: task_struct]
RTTasks
CfsTasks
Syntaxe !runq :
!runq
!runq n’a aucun paramètre de commande.
Commandes de vidage de noyau supplémentaires
!dev - Affiche les données de l'appareil concernant le caractère et le bloc, les affectations, l'utilisation du port E/S et l'utilisation de la mémoire E/S.
!log - Affiche le contenu du noyau log_buf.
!vm - Affiche un résumé de l’utilisation de la mémoire virtuelle.
!timer - Affiche les entrées de la file d'attente du retardateur.
Commande dx et objets Linux
La commande dx peut être utilisée pour examiner les kdumps. Pour voir les différents objets enfants disponibles, visualisez l’objet Sessions.
0: kd> dx -r3 Debugger.Sessions[0]
Debugger.Sessions[0] : Target Composition Target
Processes
[0x0] : swapper/0 [Switch To]
KernelObject : swapper/0 [Type: task_struct]
Name : swapper/0
Id : 0x0
Index : 0x0
Threads
Modules
Environment
Direct3D
Attributes
Devices
Io
Memory
GroupedStacks
...
L’objet noyau cursession contient l’objet PrintKLog qui peut être utilisé pour afficher le journal du noyau.
6: kd> dx @$cursession.Kernel.PrintKLog.Take(4)
@$cursession.Kernel.PrintKLog.Take(4)
[0x0] : [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
[0x1] : [ 0.000000] Linux version 4.19.90-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Fri Mar 27 14:25:24 UTC 2020..
[0x2] : [ 0.000002] sched_clock: 64 bits at 125MHz, resolution 8ns, wraps every 4398046511100ns
[0x3] : [ 0.000003] 17.250901928 MSFT: kernel boot start
Cette commande dx montre l’utilisation de .Contains() pour rechercher des chaînes spécifiques dans le journal.
6: kd> dx @$cursession.Kernel.PrintKLog.Where(le => le.ToLower().Contains("oops") || le.ToLower().Contains("crash"))
@$cursession.Kernel.PrintKLog.Where(le => le.ToLower().Contains("oops") || le.ToLower().Contains("crash"))
[0x0] : [ 0.000493] crashkernel reserved: 0x00000000dc600000 - 0x00000000fc600000 (512 MB)
[0x1] : [ 0.078790] Kernel command line: console=ttyS0,115200n8 earlycon=uart8250,mmio32,0x68A10000 crashkernel=512M enforcing=0 ipe.enforce=0
[0x2] : [ 26.621228] sysrq: SysRq : Trigger a crash
[0x3] : [ 26.621254] Internal error: Oops: 96000044 [#1] SMP
[0x4] : [ 26.656655] pc : sysrq_handle_crash+0x24/0x30
[0x5] : [ 26.753494] sysrq_handle_crash+0x24/0x30
[0x6] : [ 26.801441] Starting crashdump kernel...8J»=.
Permet .Reverse() d’afficher les derniers événements enregistrés.
2: kd> dx @$cursession.Kernel.PrintKLog.Reverse().Take(5).Reverse()
@$cursession.Kernel.PrintKLog.Reverse().Take(5).Reverse()
[0x0] : [3147944.378367] kthread+0x118/0x2a4
[0x1] : [3147944.381876] ret_from_fork+0x10/0x18
[0x2] : [3147944.385747] Code: 78002507 36000042 39000107 d65f03c0 (cb0803e4)
[0x3] : [3147944.392221] SMP: stopping secondary CPUs
[0x4] : [3147944.397539] Starting crashdump kernel...
Pour plus d’informations sur l’utilisation de requêtes LINQ avec la commande dx, consultez Utilisation de LINQ avec les objets du débogueur.
Extensions de diagnostic Linux - ELFBinComposition.dll
Les extensions de diagnostic de fichier dump Linux suivantes sont disponibles dans ELFBinComposition.dll.
Commandes de fichier dump
Ces commandes peuvent être utilisées sur la plupart des fichiers dump.
!dumpdebug - Affiche les diagnostics pour le core dump en cours de débogage. Cela inclut la sortie de diverses autres commandes.
!ntprstatus - Affichez les enregistrements NT_PRSTATUS du dump du noyau en cours de débogage.
!vmcoreinfo - Affiche la table VMCOREINFO à partir du dump du noyau (KDUMP) en cours de débogage.
Commandes de dump ELF
Ces commandes ne peuvent être utilisées que sur des fichiers de dump de noyau ELF.
!corephdrs - Affiche la table d'en-tête du programme pour le dump de mémoire en cours de débogage.
!ntprpsinfo - Affichez les données NT_PRPSINFO à partir du dump du noyau en cours de débogage.
!ntfile - Affiche les données NT_FILE provenant du dump du noyau en cours de débogage.
!ntauxv - Affichez les données NT_AUXV du dump du noyau en cours de débogage.
Commandes relatives au fichier de vidage de la mémoire du noyau
Ces commandes peuvent être utilisées uniquement sur les fichiers de vidage du noyau (KDUMP).
!kdumpdescs - Afficher la liste des plages de pages et des descripteurs de page dans un KDUMP.
!kdumppagerange <n> - Affichez les informations relatives au n-ième regroupement de pages dans le KDUMP.
!kdumppfn <pfn> - Affichez des informations sur le cadre <pfn> de page et l’emplacement où ses données se trouvent dans le KDUMP.
Autres commandes de diagnostic
!cppex - Affiche des informations sur les exceptions C++ en cours (non interceptées et « juste » interceptées) pour le thread actuel, à l'aide des structures internes de libstdc++ et des symboles DWARF.
!cppfilt [-n] <mangled name> - Démêle un nom C++ manglé comme s'il avait été traité par l'outil c++filt. Pour plus d’informations sur l’outil C==filtr, consultez la page de manuel c++filt(1) — Linux.
!rustdemangle <mangled name> - Démêle un nom altéré par Rust. Pour plus d'informations sur la modification des noms de symboles dans Rust, veuillez consulter Rust Symbol Mangling - RFC 2603.