ALERTE performance :  la classe Win32_OperatingSystem !

La  classe WMI Win32_OperatingSystem est très populaire (à juste titre) chez les administrateurs système. Elle est fréquemment utilisée par exemple pour exécuter des actions spécifiques ou appliquer des stratégies de groupes (GPO)  spécifiques à une version  de Windows.

Cette classe (cf http://msdn.microsoft.com/en-us/library/aa394239(v=vs.85).aspx ) semble bien anodine et ne « collecte » que des « informations statiques » .

C’est sans compter avec le champ NumberOfProcesses !

Pour déterminer la valeur de NumberOfProcesses, le provider WMI fait lui-même une requête WMI  « SELECT __RELPATH FROM Win32_Process  »  qui charge considérablement le système.

Par exemple sur un « large serveur » RDS/Citrix avec :

• Plusieurs GPOs ayant un filtre du type :Select * FROM Win32_OperatingSystem WHERE Version like '6.3%'

• De scripts de logon avec des « select * Win32_OperatingSystem »

• Des « brokers » ou des outils de monitoring exécutant des « Select * from Win32_Process »

• De nombreux « logon »

Vous observerez rapidement :

• une forte consommation CPU dans le process WMIPRVSE

• des temps de « logon » important

• une forte contention « kernel »  liée à l’énumération des processus qui peut avoir des conséquences diverses et variées (lenteur lors du lancement du gestionnaire de tâches,…)

La solution est de limiter les champs retournés par la requête WQL. Le provider de la classe Win32_OperatingSystem ne collecte alors que les infos demandées. La requête « select Version from   Win32_OperatingSystem » n’énumère pas  la liste des processus.

Tip :

L’activation du tracing « WMI-Activity » (http://msdn.microsoft.com/en-us/library/aa826686(v=vs.85).aspx) permet d’identifier ce type de problème.

Travaillons aujourd’hui sur un autre scénario assez simple : Celui de la suppression accidentelle d’une partition.

Supposons que cette partition

soit devenue

Comme d’habitude, on contrôle les secteurs habituels et on voit celui qui pourrait manquer.

Au secteur 0, on a un MBR montrant une partition GPT qui occupe tout le disque

Au secteur 1, on retrouve un GPT Header :

Données:

• Sector Signature : EFI PART
• Version 0.1
• Header Size : 5C
• CRC32 of the Header : 2153345396
• Current / Alternate GPT Header : 1 / 266338303
• First / Last Usable LBA : 34 / 266338270
• Disk GUID : {04D4F64A-0F7B-49CE-9013-CF4EF9121641}
• Partition Table Address : 2
• Partition Count : 128
• Partition Table Entry Size : 128
• CRC32 of Partition Table : 1583197318

Et le secteur 266338303 montre la même chose.

Le secteur 2 nous montre une table de partitions ne contenant que la partition MSR (comme quoi, rien n’est perdu), et le secteur 266338271 (Last usable +1) nous montre la même chose.

Allons donc voir si une partition NTFS pourrait trainer sur le disque.

Comme la partition MSR finit au secteur 262177, on devrait en trouver une plus loin, en principe aligné sur 64KB.

C’est au secteur 264192 que nous allons la trouver

Total Sectors : 266072063 (~126.8 GB) : Le secteur de fin devrait se trouver 266336255 ( = 266072063 + 264192 )

Clusters to MFT / MFTMirr : 786432 (LBA 6555648 = 264192 + 8*786432 ) / 2 (LBA 264208 = 264192 + 8*2)

Et ce sont bien des entrées de MFT que l’on trouve à ces secteurs:

Résumons-nous :

• LBA 0 : La partition GPT
• LBA 1 et Backup : Les GPT Headers
• LBA 2 et Backup : Une table de partition ne contenant que la partition MSR
• LBA 264192 et 266336255 : Encadrent la partition NTFS

En principe, comme pour une partition MBR :

• Sauvegarder le 1^er secteur de la partition NTFS
• Créer une partition occupant tout le disque sans la formater
• Ecraser le 1^er secteur de la nouvelle partition NTFS par celui précédemment sauvegardé.

Quand vient le moment de formater, ne pas formater.

A ce moment-là, le secteur 264192 a été vidé de son contenu (puisque nous n’avons pas fourni de file system)

En écrasant ce secteur par celui que nous avons sauvegardé, c’est comme si nous formatons la partition.

DskProbe.exe permet d’écraser un secteur du disque.

Après vérification rapide (secteur de fin de partition, MFT, MFTMirr) un rescan du disque fait revenir la partition comme par magie.

Serge Gourraud
55 AA

Maintenant que nous avons vu les structures qui décrivent les partitions des disques basiques GPT, voyons où nous pouvons rencontrer une corruption et comment la réparer (ou pas)

Si nous reprenons notre schéma, une corruption pourrait arriver :

• Dans le MBR
• Dans le GPT Header
• Dans la table de partition (qui occupe les secteurs 2 à 33)
• Dans les NTFS Boot Sectors
• Dans la MFT (utiliser chkdsk)

La structure GPT est très robuste en ceci que windows maintient une consistance entre les GPT Header de début et de fin, ainsi que dans les tables de partitions de début et de fin, de façon à ce que si quelqu’un vient à supprimer l’un d’eux, il sera réparé au moins au prochain reboot.

La partie non protégée est le MBR (secteur 0) et c’est jusqu’à présent la seule corruption que j’ai eu à réparer sur des disques GPT Basiques.

Nous n’allons donc voir que deux types de corruption

• MBR
• Partition Table
• NTFS : Déjà couvert dans les parties précédentes.

Premier type de corruption (le seul déjà rencontré au support) : Vidage du MBR

Voilà à quoi cela ressemble dans le gestionnaire de disque :

A l’éditeur hexa, on ne voit que des 00:

Le secteur 1 contient bien ce qui ressemble à un GPT Header

Ses données semblent correctes

Si on ouvre le GPT Header alternative, on retrouve les mêmes données :

Si on parcours la table de partition (LBA 2) on trouve une table de partition contenant la MSR et 3 partitions de données. Dans mon cas, je n’ai que 3 partitions sur mon disque donc, les autres LBAs (jusqu’au 33) sont vides.

On peut reporter les données dans ce tableau (pour l’interprétation, se référer au chapitre précédent)

Dans le cadre d’une réparation, il faut bien vérifier que les secteurs 264192/184416255 , 184416256/245854207 et 245854208/266334207 sont des secteurs NTFS et contrôler qu’ils pointent bien vers une MFT a priori correcte. (nous avons traité ces points dans les articles précédents)

Donc:

• Les "GPT Header" principal et secondaire sont Ok
• Les "GPT Entries" des "Partition Table" principale et secondaire sont Ok
• Les structures NTFS sont Ok

Seul le MBR est à reconstruire

Il ne nous reste plus qu’à réparer le MBR en se souvenant qu’ils sont tous identiques.

En utilisant un éditeur hexa il reste à écrire ces données :

Et c’est tout. Un rescan du disque et on n’en parle plus.

Serge Gourraud
55 AA

Maintenant que les disques basiques MBR (partitions primaires et étendues) n’ont plus de secrets pour nous, nous allons nous intéresser au disques basiques GPT.

Reprenons le schéma qui décrit la structure d’un disque basique GPT et essayons de voir à quoi cela ressemble concrètement.

Commençons par le secteur 0:

Remarques:

• Il n’y a plus de signature. Nous n’en avons plus besoin car nous identifions désormais le disque par GUID, et cette information sera stockée ailleurs.
• Il n’y a qu’une seule entrée dans la table de partition, et ses propriétés sont telles que tout le disque est occupé.

Le MBR est dit “protecteur” car il contient une partition qui couvre tout le disque (Relative Sector 1 / Total Sectors FFFFFFFF), et aussi car nous avons des secteurs importants

Voici ce à quoi ressemble le secteur 1 : 

Ce secteur est le GPT Header et contient ces informations :

Toutes les données sont importantes, mais celles qui nous intéressent pour faire des réparations sont :

• La signature ("EFI PART") : Pour reconnaitre le secteur (nous n’avons plus de 55 AA)
• Les CRC32 : Ceux-ci sont importants car ils permettent au système de vérifier que quelqu’un n’a pas modifié des entrées dans ses tables à la main, en by-passant le système.

• http://msdn.microsoft.com/en-us/library/dd905031(v=office.12).aspx

• L’adresse courante du header (1) et l’adresse du GPT Header alternatif (266338303)
• Le début de la table de partition (2) et le nombre de partition qu’elle peut contenir (128)
• Les 1ers et derniers secteurs utilisables (en général le dernier +1 contient le début de la table de partitions
• Un GUID qui représente le disque (sa signature)

Cette structure est décrite sur http://msdn.microsoft.com/en-us/library/windows/desktop/aa365449(v=vs.85).aspx

Regardons le secteur 2 : Début de la table de partition.

Il faut y voir 4 régions de 128 bytes chacune : Une entrée dans la table de partition fait 128 bytes

Dans le cas présent, les 2 premières entrées sont occupées et les autres sont vides

Première entrée

Seconde entrée

Vous pourrez trouver des informations complémentaires sur ces structures dans l’article http://msdn.microsoft.com/en-us/library/windows/desktop/aa365449(v=vs.85).aspx

Plus d’informations sur la Microsoft Data Partition (MSR) dans la FAQ GPT:

http://msdn.microsoft.com/en-us/library/windows/hardware/dn640535(v=vs.85).aspx#gpt_faq_what_is_msr

Donc, la première entrée est pour la MSR et la seconde pour la partition de données de type « Basic Data Partition ».

Puisqu’il s’agit d’une partition NTFS, nous pouvons trouver les NTFS Boot Sectors aux LBA 264192 et 266336255

Et voilà:

On peut y lire:

Déjà on retrouve notre signature 55 AA (qui commençait à manquer un des mes amis blogueurs)

• Le Relative Sector : 00 08 04 00 --> 00 04 08 00 = 40800 = 264192 LBA
• Total Sectors: FF EF DB 0F 00 00 00 00 --> FDBEFFF = 266072063 Secteurs

Le NTFS Boot sector de backup montrera la même information.

Le GPT Header nous avait parlé du Last Usable LBA (266338270)

Le LBA juste après montre bien une copie de la table de partition (266338270 + 1 = 266338271 )

Un espace de 128 entrées (si on en prend 4 par secteur de 512 ça fait 32 secteurs) est reservé pour y stocker toute la table de partitions

Les angoissés qui aiment que tout soit bien aligné éprouveront sans doute un plaisir non caché en constatant que 26638271 + 32 = 266338303 : C’est exactement l’emplacement du GPT Header alternatif.

C’est vrai que c’est rassurant quand même _{… quelque part … moi, je trouve ça rassurant.}

Comme on adore les schémas qui montre la beauté de l’alignement des secteurs, en voici un qui reprend les valeurs que nous avons trouvées.

Voilà, vous savez désormais tout sur la façon dont les partitions sont référencées dans des disques GPT. Dans le prochain article, nous allons voir où peuvent se glisser des corruptions et comment les réparer (ou pas).

Serge Gourraud
55 AA

Supposons maintenant que ce disque qui contient ces 3 partitions :

Se soit transformé en ceci:

Ce sont des choses qui arrivent quand le MBR (secteur 0 du disque) a été vidé.

Rappelons la structure d’un disque contenant 3 partitions et essayons de voir ce qu’on a concrètement sur le disque

Le secteur 0 est vide: Pas de signature, pas de code, pas de table de partitions

Sur des disques MBR Basiques c’est au secteur 2048 que démarre la première partition (sur les anciennes architectures, on aurait cherché au secteur 63 voire 31 mais ça nous ramené à NT4.0)

Le secteur 2048 nous montre ceci :

Et nous pouvons y lire ces informations :

• OEM ID (offset 30) : NTFS
• Bytes per Sector (offset 0B) : 00 02 -> 512
• Sectors per cluster (offset 0D) : 08
• Cluster per MFT Record (offset 40) : F6 -> 1K
• Total Sectors (offset 28) : FF 67 C5 09 00 00 00 00 -> 163932159 sectors (~78GB
  • Backup NTFS Boot Sector = 163932159 + 2048 = 163934207
• Clusters to MFT (offset 30) : 00 00 0C 00 00 00 00 00 -> 78643
  • La partition démarrant en 2048 : on trouvera la MFT en 2048 + 8 * 786432 = 629350
• Clusters to MFTMirr (offset 38) : 02 00 00 00 00 00 00 00 -> 2
  • 2048 + 8 * 2 = 2064

Pour résumer :

• Le dernier secteur de la partition devrait se trouver en 163934207
• La MFT en 786432 (et son "backup" en 2064
• Le champ $Volume en 6293510 ( = 6293504 + 2*3)

Le NTFS Boot Sector de backup en 163934207

Le secteur 786432 ressemble à un début de MFT

Et visiblement, on retrouve le nom du volume

Nous savons désormais que notre première partition démarre au secteur 2048 et finit au secteur 163934207

Comme tout est aligné, la seconde partition devrait démarrer au secteur 163934207 + 1 = 163934208

Fantastique!

On peut également y lire:

• OEMID (offset 30) : NTFS
• Bytes per Sector (offset 0B) : 00 02 -> 512
• Sectors per cluster (offset 0D) : 08
• Cluster per MFT Record (offset 40) : F6 -> 1 record MFT = 1K
• Total Sectors (offset 28) : FF 7F A9 03 00 00 00 00 : 61439999 sectors (~29 GB)
  • Backup NTFS Boot Sector : 61439999 + 163934208 = 225374207
• Clusters to MFT (offset 30) : 00 00 0C 00 00 00 00 00 : 786432 -> 163934208 + 8 * 786432 = 170225664
• Clusters to MFTMirr (offset 38) : 02 00 00 00 00 00 00 00 : 2 -> 163934208 + 8 * 2 = 163934224

De même, la 3ième partition sensé démarrer un secteur plus loin y est bien présente :

225374207 + 1 = 225374208

Total sectors: 0270FFFF = 40959999 = 40959999 *512 = 20971519488 Bytes

Backup Boot Sector : 40959999 + 225374208 = 266334207

Il faudra faire un contrôle complet de chaque secteur important (NTFS / Backup NTFS / MFTMirr / MFT / MFT.$Volume) et on peut dresser cette carte du disque :

• Première Partition :
  • Nom du volume Part1
  • Taille en secteurs: 163932159
  • Démarre au secteur: 2048
  • MFT localisée au secteur: 6293504
  • Termine au secteur: 16393420
• Deuxième Partition :
  • Nom du volume: Part2
  • Taille en secteurs: 61439999
  • Démarre au secteur: 163934208
  • MFT localisée au secteur: 170225664
  • Termine au secteur: 225374207
• Troisième Partition :
  • Nom du volume: Part3
  • Taille en secteurs: 40959999
  • Démarre au secteur: 225374208
  • MFT localisée au secteur: 231665664
  • Termine au secteur: 266334207

Il est très important de tout bien verifier: Si vous faites une erreur d’un secteur et que votre partition ne trouve pas sa MFT, notre  vieil ami chkdsk se fera un plaisir d’un générer automatiquement une toute nouvelle MFT, tout vide, juste pour vous. 

Et nous pouvons démarrer notre réparation

Première étape: Initialiser le disque (le code, la signature et une table de partition vide seront écrites)

Maintenant, il nous faut reprendre notre éditeur hexa préféré, le mien s’appelle DskProbe.exe car il permet d’appliquer un masque au données affichés par les secteurs.

(Pour information ce lien http://fr.wikipedia.org/wiki/%C3%89diteur_hexad%C3%A9cimalpropose une liste de produits)

Le secteur 0 que nous venons de réécrire (par initialisation) ressemble désormais à cela :

Avec DskProbe, nous pouvons faire paraitre la table de partition de ce secteur.

Les valeurs de début et fin de Head (=Side), Secteur et Cylindre dépendent de l’architecture, mais sont souvent les mêmes et voici celle qui convient de mettre pour la première partition de notre disque.

(Si vous avez plusieurs disques identiques sur votre ordinateur, ou un autre ordinateur avec le même disque qui n’a pas eu de soucis, vous pouvez récupérer les mêmes données)

Note : Il faut ajouter un secteur au Total Sectors du MBR par rapport au Total Sectors du NTFS Boot Sector puisqu’à cet endroit il faut compter les deux NTFS Boot Sector qui encadrent la partition, alors que dans le NTFS Boot Sector, on ne compte pas le dernier.

En récrivant « 07 » à l’offset du FileSystem de la première entrée de la table de partition.

Un rescan disk dans le Disk Manager nous fait reparaitre la partition comme par miracle:

On peut faire reparaitre les deux autres partitions en remplissant mes Start/End Side/Sector/Cylinder comme suit, et en adaptant les Relative et Total Sectors aux données relevées et en plaçant le type de système à NTFS (07) aux offset 01C2, 01D2, 01E2, 01F2 correspondant aux partitions respectives.

Si une des partitions par en chdksk, pas de chances : Soit vous vous êtes trompés dans vos calculs, soit la MFT avait besoin d’une réparation avant vos opérations.

Comme expliqué au premier article, toutes ces opérations sont des opérations de dernier recours, et ne garantissent aucunement la récupération de vos données.

Dans la prochaine série, nous nous intéressons aux disques GPT.

Serge Gourraud
55 AA