Petit souci avec Windbg

Version imprimable

12/01/2008, 15h29
johan_b

Petit souci avec Windbg

Bonjour à tous,
alors voilà, mon probleme est que j'aimerais afficher certaines structures systeme et on (Neista, encore merci à lui :) ) m'a conseillé d'utiliser windbg.
J'ai don ctéléchargé Windbg via la page debugging tools (http://www.microsoft.com/whdc/devtoo...nstallx86.mspx) et les symboles pour winXp SP2 (http://www.microsoft.com/whdc/devtoo...symbolpkg.mspx) dans le répertoire par défaut (c:\WINDOWS\SYMBOLS).
Quand je démarre Windbg:

Citation:

file> symbols Path = c:\WINDOWS\SYMBOLS

donc le path semble correct. Après,

Citation:

file>kernel Debug... > Local > OK

Et la console s'affiche avec le message suivant:

Citation:

Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Symbol search path is: c:\WINDOWS\SYMBOLS
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntkrnlpa.exe -
*******************************************************************************
WARNING: Local kernel debugging requires booting with kernel
debugging support (/debug or bcdedit -debug on) to work optimally.
*******************************************************************************
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.070227-2254
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805533a0
Debug session time: Sat Jan 12 15:24:47.468 2008 (GMT+1)
System Uptime: 1 days 15:37:45.070

Je ne comprend pas pourquoi Windbg n'arrive pas à charger les symbols, et donc je suis bloqué. Si je rentre une commande, j'ai un message d'erreur.
Ex:

Citation:

lkd> dt _IRP
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: _IRP ***
*** ***
*************************************************************************
Symbol _IRP not found.

Ce qui me pose soucis au passage, c'est le prompt lkd au lieu du kd théorique.

Quelqu'un pourrait m'aider svp?
13/01/2008, 11h50
Neitsa
Bonjour johan_b,

Citation:

alors voilà, mon probleme est que j'aimerais afficher certaines structures systeme et on (Neista, encore merci à lui ) m'a conseillé d'utiliser windbg.

De rien ;)

Citation:

Quand je démarre Windbg:

Citation:
file> symbols Path = c:\WINDOWS\SYMBOLS

donc le path semble correct

Non, en fait c'est un problème de symbol path.

La syntaxe du symbol path est de ce type :
Code:

1 2 srv*DownstreamStore*http://msdl.microsoft.com/download/symbols
Ou "DownStreamStore" et le chemin dur disque, donc pour toi :
Code:

1 2 srv*c:\WINDOWS\SYMBOLS*http://msdl.microsoft.com/download/symbols
Je te conseille aussi de mettre la variable d'environnement _NT_SYMBOL_PATH avec ce chemin :

Démarrez > Panneau de contrôle > Système > onglet "Avancé" > bouton "Var. d'env."

Tu crée une nouvelle var. d'env. en l'appelant exactement :
_NT_SYMBOL_PATH

Et en lui mettant comme valeur :
srv*c:\WINDOWS\SYMBOLS*http://msdl.microsoft.com/download/symbols

Pour plus d'infos, tu peux taper la commande suivante au prompt de windbg (ou kd / lkd) :
Code:

1 2 .hh Symbol Path
Citation:

Ce qui me pose soucis au passage, c'est le prompt lkd au lieu du kd théorique.

En fait si tu travailles en kernel debug local, tu travailles sur un "snapshot" du kernel, à l'instant 't' où tu as demandé à faire un debug local. Tu travailles donc, en quelque sorte, sur une version statique et figée du kernel (avec live kd).

Pour faire du "vrai" kernel debug, il faut débugger un autre système :
- soit réel / physique ( avec un cable série ou firewire).
- soit virtuel, en se connectant par pipe sur une machine virtuelle (type VMWare).

Si on y pense, c'est normal de travailler sur une version figée: Lorsque l'on débug le kernel , c'est tout l'O.S qui est "gelé"... donc Windbg / kd ne pourrait pas fonctionner. [n.b : un programme comme Softice fonctionne différemment puisqu'il est "sous le kernel" donc il ne dépend pas de ce dernier pour fonctionner].

Voilà, en espérant que cela t'aide. Si tu as d'autres problèmes, n'hésites pas.

[edit]

Lorsque tu aura mis ton symbol path correctement, il est possible que windbg veuille mettre les symboles à jour lors de ta prochaine session de debug. Et là, ça peut prendre un temps conséquent suivant ta connexion et la charge du serveur de Microsoft. Si Windbg apparaît "bloqué", ne t'inquiète pas et patiente...

Encore merci pour tout :)
ça y est ça fonctionne. J'ai encore quelques souci pour manipuler tout ça mais ça va rentrer au fur et a mesure.

Par contre j'ai toujours un souci pour déterminer quel membre d'une structure est utilisé sur cet exemple:

Code:

1
2
mov     edx, @Irp->CurrentStackLocation  ; =@Irp+60h
mov     eax, [edx+0Ch]  ; eax =??

Si je fais un dt _IRP

Code:

1
2
3
4
5
6
7
8
9
10
11
12
...
+0x040 Tail             : __unnamed
      +0x000 Overlay          : __unnamed
         +0x000 DeviceQueueEntry : _KDEVICE_QUEUE_ENTRY
         +0x000 DriverContext    : [4] Ptr32 Void
         +0x010 Thread           : Ptr32 _ETHREAD
         +0x014 AuxiliaryBuffer  : Ptr32 Char
         +0x018 ListEntry        : _LIST_ENTRY
         +0x020 CurrentStackLocation : Ptr32 _IO_STACK_LOCATION //@irp+60h
         +0x020 PacketType       : Uint4B
         +0x024 OriginalFileObject : Ptr32 _FILE_OBJECT

Je regarde donc la structure IOstackLocation:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
lkd> dt _IO_STACK_LOCATION
ntdll!_IO_STACK_LOCATION
   +0x000 MajorFunction    : UChar
   +0x001 MinorFunction    : UChar
   +0x002 Flags            : UChar
   +0x003 Control          : UChar
   +0x004 Parameters       : __unnamed
   +0x014 DeviceObject     : Ptr32 _DEVICE_OBJECT
   +0x018 FileObject       : Ptr32 _FILE_OBJECT
   +0x01c CompletionRoutine : Ptr32     long 
   +0x020 Context          : Ptr32 Void

L'offset 0x0c se trouve donc dans le membre Parameters. Je fais donc:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
lkd> dt _IO_STACK_LOCATION Parameters.
ntdll!_IO_STACK_LOCATION
   +0x004 Parameters  : 
      +0x000 Create      : __unnamed
      +0x000 CreatePipe  : __unnamed
      +0x000 CreateMailslot : __unnamed
      +0x000 Read        : __unnamed
      +0x000 Write       : __unnamed
      +0x000 QueryDirectory : __unnamed
      +0x000 NotifyDirectory : __unnamed
      +0x000 QueryFile   : __unnamed
      +0x000 SetFile     : __unnamed
      +0x000 QueryEa     : __unnamed
      +0x000 SetEa       : __unnamed
      +0x000 QueryVolume : __unnamed
      +0x000 SetVolume   : __unnamed
      +0x000 FileSystemControl : __unnamed
      +0x000 LockControl : __unnamed
      +0x000 DeviceIoControl : __unnamed
      +0x000 QuerySecurity : __unnamed
      +0x000 SetSecurity : __unnamed
      +0x000 MountVolume : __unnamed
      +0x000 VerifyVolume : __unnamed
      +0x000 Scsi        : __unnamed
      +0x000 QueryQuota  : __unnamed
      +0x000 SetQuota    : __unnamed
      +0x000 QueryDeviceRelations : __unnamed
      +0x000 QueryInterface : __unnamed
      +0x000 DeviceCapabilities : __unnamed
      +0x000 FilterResourceRequirements : __unnamed
      +0x000 ReadWriteConfig : __unnamed
      +0x000 SetLock     : __unnamed
      +0x000 QueryId     : __unnamed
      +0x000 QueryDeviceText : __unnamed
      +0x000 UsageNotification : __unnamed
      +0x000 WaitWake    : __unnamed
      +0x000 PowerSequence : __unnamed
      +0x000 Power       : __unnamed
      +0x000 StartDevice : __unnamed
      +0x000 WMI         : __unnamed
      +0x000 Others      : __unnamed

à partir de cet endroit comment puis-je déterminer à quel sous-membre appartiens ma valeur?

Par xpérience, je sais qu'il s'agit de:

Code:

1
2
3
4
5
+0x000 DeviceIoControl : 
         +0x000 OutputBufferLength : Uint4B
         +0x004 InputBufferLength : Uint4B
         +0x008 IoControlCode : Uint4B //_IO_STACK_LOCATION->Parameters(+04h).DeviceIoControl.IoControlCode(+08h) ce qui donen bien 0ch
         +0x00c Type3InputBuffer : Ptr32 Void

Mais dans l'absolu, comment savoir qu'il s'agit bien ce ce membre?

Citation:
Envoyé par johan_b
à partir de cet endroit comment puis-je déterminer à quel sous-membre appartiens ma valeur?

Par xpérience, je sais qu'il s'agit de:
Code:

1 2 3 4 5 +0x000 DeviceIoControl : +0x000 OutputBufferLength : Uint4B +0x004 InputBufferLength : Uint4B +0x008 IoControlCode : Uint4B //_IO_STACK_LOCATION->Parameters(+04h).DeviceIoControl.IoControlCode(+08h) ce qui donen bien 0ch +0x00c Type3InputBuffer : Ptr32 Void
Mais dans l'absolu, comment savoir qu'il s'agit bien ce ce membre?
Il n'y a pas de moyen de le dégager "comme ça". En fait tu as bien résumer la chose : "Par expérience".

La seule chose qui puisse t'aider c'est analyser le contexte dans lequel le membre de la structure est utilisé et de dégager une forte probabilité (voire une certitude) que ce soit bien celui-là et pas un autre. C'est là que s'arrête la limite des outils et qu'entre en jeu l'expérience de l'opérateur humain derrière l'outil :D

13/01/2008, 18h10
johan_b

En fait, c comme une analyse de trame si on peut faire une analogie.
Genre en fonction des valeurs lues dans une entete, le contenu de la trame aura une signification différente selon le protocole utlisé, mais sera stockée dans le même "buffer" quelque soit le protocole utilisé.

C'est bien dommage qu'il n'y ait pas d'explications sur le contexte dans lequel tel ou tel nom (et donc structure) est utilisée.

En tout cas merci beaucoup pour cette aide précieuse :king:, ça va faire progresser le shmilblick beaucoup plus rapidement maintenant :D, et je me coucherai moins bête :p