[Archives des newsletters ^] [< Volume 1, Numéro 4] [Volume 2, Numéro 1 >]
Bulletin d’information Systems Internals Volume 1, numéro 5
http://www.sysinternals.com
Copyright (C) 1999 Mark Russinovich
12 octobre 1999 – Dans ce numéro :
NOUVEAUTÉS DE SYSTEMS INTERNALS
- NTFS pour Windows 98/NTFSDOS Professionnel
- DebugView v3.21
- Filemon et Regmon v4.21
- Diskmon v1.1
- Systems Internals sur www.microsoft.com
- Octobre « NT Internals »
- Nouveautés pas si nouvelles
ACTUALITÉS INTERNES
- Win2K RC2 DDK publié
- Nouvelles API du noyau Win2K RC
- Développement de logiciels '99 East
- Utilisation de DiskEdit
NOUVEAUTÉS À VENIR
- Explosion de l’API Win2K
SPONSOR : WINTERNALS SOFTWARE
Le bulletin d’informations Systems Internals est parrainé par Winternals Software, sur le web à l’adresse http://www.winternals.com. Winternals Software est le principal développeur et fournisseur d’outils de systèmes avancés pour Windows NT/2K. Les produits Winternals Software incluent FAT32 pour Windows NT 4.0, ERD Commander (fonctionnalité de disque de démarrage pour Windows NT) et NTRecover.
La récupération à distance de Winternals Software vous permet d’accéder aux lecteurs d’un ordinateur non démarrable par le biais de TCP/IP depuis n’importe où dans votre entreprise. Gagnez du temps et des dollars de support en corrigeant à distance les problèmes de pilote, de système de fichiers et de configuration qui empêchent les systèmes NT ou Win9x hors ligne. Vous pouvez même effectuer des opérations de partitionnement ou de chkdsk à distance à l’aide de la récupération à distance, ce qui en fait un outil de récupération d’urgence polyvalent. Téléchargez une version d’évaluation en lecture seule gratuite sur http://www.sysinternals.com/rrecover.htm, puis achetez la version en lecture/écriture à l’adresse http://www.winternals.com.
Bonjour,
Bienvenue dans le bulletin Systems Internal. Le bulletin compte actuellement 10 000 abonnés.
La version de Windows 2000 (Win2K) semble suivre un modèle de devenir imminente, puis d’être repoussée. Les dernières rumeurs sont qu’il sera disponible en février. Et les seules informations sur la date d’expédition de Win2K sont dans les rumeurs, car Microsoft ne dit même pas aux fabricants OEM ou partenaires quand il sera livré. Eh bien, ils sont : « il expédiera quand il sera prêt » (je ne forcerai pas le dit daté sur la vente de vin sur vous ici).
La chose irritante à propos de Microsoft est que la presse qu’ils génèrent sur leurs produits donne toujours l’impression qu’ils sont au bord de l’expédition, même lorsque les produits sont des vaporwares. L’exemple le plus récent est Millennium, le successeur de Windows 98. Il n’y a pas si longtemps, Microsoft a fait une grosse poussée dans la presse pour lui comme s’il s’agissait d’un produit fini, prêt à convertir tous vos appareils ménagers en appareils intelligents. L’ironie est que des articles peu de temps plus tard ont révélé que Microsoft n’a pas encore complètement défini le produit, et il va probablement s’agir d’un an ou plus avant que nous le voyions sur les étagères des magasins.
Ce modèle n’est pas nouveau et je ne suis pas le premier à écrire à ce sujet. Mais cela ne m’empêche pas de spéculer sur la quantité de la see-sawing est un plan soigneusement orchestré, et combien est le résultat d’un manque total de principes de génie logiciel. Si vous achetez dans l’ancien angle, comme le font les théoriciens du complot, Microsoft étouffe brillamment la concurrence en séduisant les clients avec ce produit incroyable qui, s’ils attendent un peu plus longtemps, rendra leur attente utile et évite tout besoin de se tourner vers un produit non-Microsoft. Ce dernier angle indique que Microsoft n’apprendra jamais le processus de développement de logiciels et sous-estime continuellement les efforts d’ingénierie et surestime la qualité du code bêta.
Je suis assis sur la clôture de la théorie à laquelle je me suis inscris. Je pense en fait que le modèle est dû à un peu des deux. Je pense qu’il a aidé Microsoft à agir comme Active Directory a été presque prêt depuis deux ans maintenant. Il y a sûrement des clients qui se seraient tournés vers les services d’annuaires Novell il y a longtemps s’ils avaient su à l’avance combien de temps ils auraient à attendre pour Win2K. D’autre part, Microsoft a obtenu des yeux noirs répétés dans la presse à partir de la livraison de produits prometteurs, puis retardant. Je pense que la direction de Microsoft ne comprend tout simplement pas à quel point il est difficile de reproduire, d’isoler et de corriger que les 5 % derniers bogues.
En parlant des pratiques de développement de Microsoft, leur schéma de nommage en préversion est l’un des plus déconcertants que j’ai vus. Leurs bêtas sont vraiment des alphas et leurs versions candidates sont en fait des bêtas. Et même l’utilisation de ces définitions est une étendue : Microsoft n’a aucun problème à extraire des fonctionnalités de son logiciel en passant d’une version release candidate à l’autre, ou même en ajoutant de nouvelles. Ils l’ont fait avec NT 4.0 et ils le font avec Win2K. Cette pratique n’accélère certainement pas un cycle de mise en production.
Win2K sera-t-il livré en février ? Je pense que nous voyons la lumière au bout du tunnel. Après tout, il n’y a qu’une poignée de nouvelles API dans RC2...
Dans le suivi du dernier bulletin d’informations où j’ai parlé de la confusion des acronymes chez Microsoft, le lecteur George Janczuk a trouvé un autre exemple. Dans la section intitulée « Extension au monde Transaction-Processing mainframe », l’article fait référence à http://msdn.microsoft.com/library/backgrnd/html/msdn_windnapps.htm CISC – Complex Instruction Set Computing. Il est évident pour toute personne familiarisée avec les applications mainframe que l’acronyme prévu est CICS – Customer Information Control System. Une séquence de lettres inversées et vous êtes dans un domaine technologique totalement différent.
Comme d’habitude, s’il vous plaît transmettre le bulletin à des amis que vous pensez trouver intéressant.
Merci !
- Mark
NOUVEAUTÉS DE SYSTEMS INTERNALS
NTFS POUR WINDOWS 98/NTFSDOS PROFESSIONNEL
On l’a enfin fait. Depuis que Bryce et moi avons publié NTFSDOS 1.0 au printemps 1996, nous sommes à la recherche du Saint-Graal de la compatibilité avec les systèmes de fichiers Windows : l’accès en lecture/écriture pour NTFS à partir de Windows 9x et DOS. Nous avons déterminé il y a longtemps que la rétro-ingénierie du format NTFS et l’écriture d’un pilote pour ce système de fichiers de journalisation complexe serait une proposition difficile et risquée. Même si l’on détermine précisément chaque nuance du format, une mise à jour du format, comme NTFS v5.0 de Win2K, nécessite un tout nouvel effort de rétro-ingénierie et de développement. En outre, la validation de l’exactitude d’un pilote de système de fichiers pour un format aussi complexe que celui de NTFS est une proposition décourageante.
Alors on a triché.
NTFS pour Windows 98 fournit un accès complet en lecture/écriture aux lecteurs NTFS à partir de Windows 95 ou Windows 98, et NTFSDOS Professional fournit un accès complet en lecture/écriture NTFS à partir de DOS. Ni NTFS pour Windows 98 ni NTFSDOS Professionnel ne connaissent le format du système de fichiers NTFS. Au lieu de cela, ils s’appuient sur le pilote NTFS d’une installation Windows NT ou Windows 2000 pour implémenter ces connaissances. Les deux utilitaires utilisent la même base de code qui sert de wrapper d’environnement pour le pilote de système de fichiers NTFS. NTFS pour Windows 98 fournit une interface à l’API de système de fichiers Windows 9x au-dessus de NTFS et aux services de disque Windows 9x sous NTFS. L’interface NTFS pour Windows 98 présente à NTFS ressemble à l’environnement Windows NT/2K natif de NTFS, avec des irps, le Gestionnaire d’E/S, le Gestionnaire de cache, les appareils de disque de style NT et d’autres sous-systèmes NT/2K avec lesquels NTFS interagit.
NTFSDOS Professional fonctionne de la même façon que NTFS pour Windows 98, sauf qu’il interface NTFS aux services DOS ci-dessus et aux services de disque BIOS Interruption 13 ci-dessous. Pour faciliter la création de l’environnement de type NT/2K, nous nous appuyons sur de nombreuses fonctions dans NTOSKRNL, le fichier de noyau NT/2K. Les deux utilitaires chargent NTOSKRNL en conjonction avec NTFS, de sorte que NTFS puisse utiliser directement certains des services natifs du noyau.
Nous avons eu tellement de plaisir à construire l’environnement NTFS que nous sommes allés plus loin : nous avons fait la même chose avec l’utilitaire chkdsk de démarrage de NT, Autochk. NTFSDOS Professional et NTFS pour Windows 98 sont fournis avec un utilitaire ntfs chkdsk nommé NTFSCHK. NTFSCHK fonctionne sur le même principal que le wrapper du système de fichiers NTFS, où il crée un environnement de type NT pour le programme Autochk afin que Autochk s’exécute sous Windows 95/98 et DOS. Le résultat de cette astuce est une prise en charge complète de la lecture/écriture NTFS pour Windows 95/98 et pour DOS.
Vous pouvez télécharger une version gratuite en lecture seule de NTFS pour Windows 98 à l’adresse et http://www.sysinternals.com/ntfs98.htm une version en lecture seule gratuite de NTFSDOS Professional à l’adresse http://www.sysinternalscom/ntfspro.htm. Vous pouvez acheter les versions complètes en lecture/écriture des deux outils sur Winternals Software, http://www.winternals.com.
DEBUGVIEW V3.21
DebugView est un moniteur de débogage-sortie qui capture à la fois le noyau et la sortie de débogage Win32 sous Windows 95, Windows 98, NT 4.0 et Windows 2000. Il dispose de fonctionnalités avancées de filtrage, de mise en surbrillance et de journalisation, et peut même capturer la sortie de débogage d’un système sur un réseau. Sa dernière version, 3.21, introduit la possibilité de surveiller la sortie OutputDebugString 16 bits sous Windows 95 et Windows 98.
Vous pouvez télécharger DebugView v3.21 à l’adresse http://www.sysinternals.com/dbgview.htm.
FILEMON ET REGMON V4.21
Filemon et Regmon sont des utilitaires d’espionnage de système de fichiers et de registre pour Windows 95, 98, NT 4.0 et Win2K. Ils continuent d’évoluer avec de nouvelles fonctionnalités d’utilisation et avec la version 4.21 (Filemon et Regmon ont synchronisé les numéros de version), ils introduisent un filtrage plus avancé avec des listes de filtres récents, la possibilité de définir un filtre de surbrillance (avec même des couleurs personnalisées), la police personnalisable, la prise en charge du Presse-papiers et plus de touches d’accès rapide compatibles CUI. Le code source du pilote a également été retravaillé et inclut une validation des paramètres plus robuste dans les fonctions d’interface graphique graphique.
Téléchargez Filemon v4.21 à l’adresse http://www.sysinternals.com/filemon.htm et Regmon v4.21 à l’adresse http://www.sysinternals.com/regmon.htm.
DISKMON V1.1
Diskmon est un outil qui surveille et affiche l’activité des disques logiques et physiques. La version 1.1 met à jour Diskmon pour qu’il fonctionne avec Windows 2000 et introduit de nouvelles améliorations de la facilité d’utilisation. En outre, Diskmon interprète désormais un grand nombre de codes de contrôle d’E/S de disque et de stockage de masse, en traduisant leurs codes hexadécimaux en représentations textuelles dans la fenêtre de sortie Diskmon.
Diskmon v1.1 fonctionne non seulement comme un moniteur de disque, mais vous pouvez également l’utiliser comme un disque léger basé sur un logiciel. Lorsque vous le définissez en mode disque léger, Diskmon se réduit dans la barre d’état système sous la forme d’un voyant vert lorsqu’il existe un accès en lecture sur disque et rouge en cas d’accès en écriture sur disque.
Téléchargez Diskmon v1.1 à l’adresse http://www.sysinternals.com/diskmon.htm.
SYSTEMS INTERNALS SUR WWW.MICROSOFT.COM
Compte tenu de l’histoire de Systems Internals (anciennement NT Internals), c’est une grande flatterie que Microsoft fasse référence à sysinternals.com comme ressource pour ses clients. Il existe un nombre croissant d’articles de la Base de connaissances Microsoft qui pointent vers Les utilitaires systèmes internes. Voici les dernières nouveautés :
Q183060 INFO : Guide de résolution des problèmes pour les 80004005 et autres messages d’erreur http://support.microsoft.com/support/kb/articles/Q183/0/60.ASP
Cet article explique que vous pouvez utiliser Filemon pour case activée la cause des erreurs d’accès aux données dans OLE DB, ActiveX Data Objects et Remote Data Service.Q196453 – Résolution des erreurs de démarrage NTVDM et WOW http://support.microsoft.com/support/kb/articles/Q196/4/53.ASP
Cet article pointe également vers Filemon comme outil pour déterminer quels fichiers manquants sont à l’origine d’erreurs de démarrage pour NTVDM (l’environnement de compatibilité Win16/DOS dans NT).Q216368 : PRB : Violation d’accès lors de l’installation de l’application lors de l’utilisation du fichier http://support.microsoft.com/support/kb/articles/Q216/3/68.ASP
HandleEx et DLLView sont des outils recommandés pour déterminer la cause des erreurs lors de l’exécution des programmes d’installation générés par l’Assistant Installation de Visual Basic et l’Assistant Déploiement.Q232830 –HOWTO : Déterminer la propriété du handle de fichier http://support.microsoft.com/support/kb/articles/Q232/8/30.ASP
HandleEx obtient à nouveau la référence dans cet article qui explique quel processus a un fichier ou un répertoire ouvert.
OCTOBRE « NT INTERNALS »
Ma colonne « NT Internals » dans le numéro d’octobre de Windows NT Magazine est « Inside Win2K Reliability Enhancements, Part 3 ». Ce troisième d’une série en trois parties décrit deux fonctionnalités Win2K puissantes qui aident les développeurs et les administrateurs à identifier les pilotes bogues : la mémoire du noyau protégée en écriture et le vérificateur de pilotes.
Les lecteurs russes peuvent maintenant lire mes articles dans leur langue maternelle. Accédez à l’édition russe de Windows NT Magazine et http://www.osp.ru/win2000/ case activée la première colonne NT Internals traduite, Inside the Boot Process (http://www.osp.ru/win2000/1999/10/59.htm). Merci à Ivan Rouzanov de m’en avoir fait part.
Depuis le début du mois d’août, les versions en ligne des articles du Magazine Windows NT sont accessibles uniquement aux abonnés, et les articles sont publiés en ligne à chaque nouveau problème. Si vous ne vous êtes pas abonné, veuillez parcourir le lien d’abonnement à l’adresse pour http://www.sysinternals.com/publ.htm obtenir la remise d’abonnement Systems Internals.
NOUVEAUTÉS PAS SI NOUVELLES
WinObj est un outil puissant pour explorer l’espace de noms Windows NT/2K Object. L’espace de noms Object est l’un des trois espaces de noms dans NT/2K : l’espace de noms Object, l’espace de noms Registry et l’espace de noms du système de fichiers. Vous accédez aux espaces de noms registre et système de fichiers par le biais des objets dans l’espace de noms Object. Par exemple, lorsqu’un programme Win32 ouvre la clé HKEY_LOCAL_MACHINE\Software\Microsoft de Registre, la bibliothèque ADVAPI32.DLL transforme le nom en avant d’appeler \Registry\Machine\Software\Microsoft le service noyau NtCreateKey. Si vous examinez la racine de l’espace de noms Object dans WinObj, vous verrez un objet de type « key » nommé Registry. Le nom du Registre correspond au premier composant du nom de clé et, par conséquent, le Gestionnaire d’objets NT/2K transmet le reste du nom, \Machine\Software\Microsoft, au sous-système qui définit l’objet clé. Le sous-système du noyau Configuration Manager conserve les objets registre et clé, de sorte qu’il analyse le reste du nom pour localiser la clé souhaitée.
Vous pouvez explorer l’espace de noms Object et afficher ou définir des propriétés de sécurité d’objet à l’aide de WinObj. Téléchargez Winobj à l’adresse http://www.sysinternals.com/winobj.htm. Je parle de l’espace de noms du Gestionnaire d’objets et de WinObj dans ma colonne d’octobre 1997 NT Internals, « Inside the Object Manager ». Suivez un lien vers la version en ligne de la chronique à l’adresse suivante : http://www.sysinternals.com/publ.htm.
ACTUALITÉS INTERNES
WIN2K RC2 DDK PUBLIÉ
Vous pouvez télécharger la version Win2K RC2 du Kit de développement de pilotes de périphériques (DDK) de Microsoft à l’adresse http://www.microsoft.com/ddk/ddkRC2.htm. Vous pouvez télécharger le kit gratuitement ou parcourir la documentation en ligne.
NOUVELLES API WIN2K RC2 DU NOYAU
Les choses semblent se stabiliser dans le dernier noyau Win2K. Il n’y a que quatre nouvelles API de noyau exportées dans RC3, au lieu d’une douzaine qui sont apparues (et une autre demi-douzaine qui ont disparu) passant de bêta 3 à RC1. Plusieurs des nouvelles fonctions sont quelque peu intéressantes, donc j’ai décidé de les documenter pour vous. Le premier est MmGetSystemRoutineAddress, et bien qu’il ne soit pas documenté, son prototype est inclus dans le fichier d’en-tête ntddk.h du DDK RC2 :
NTKERNELAPI
PVOID
MmGetSystemRoutineAddress (
IN PUNICODE_STRING SystemRoutineName
);
Son utilisation est aussi simple qu’elle en a l’air. Transmettez le nom d’une fonction qui réside dans NTOSKRNL.EXE ou HAL.DLL et vous obtiendrez son adresse de point d’entrée. Cette fonction est en fait inutile dans la première version de Win2K, mais peut devenir très utile par la suite, et il s’agit d’une fonction que Microsoft aurait dû inclure dans la première version de NT (3.1). Comme GetProcAddress dans l’espace utilisateur pour les applications Win32, cette fonction permet à un pilote de déterminer dynamiquement la disponibilité d’une API. Si Microsoft ajoute de nouvelles API aux Service Packs Win2K (et je suis sûr qu’ils le feront), les pilotes peuvent être écrits pour tirer parti des API, mais aussi pour échouer correctement sur les anciennes versions de Win2K ou pour s’exécuter dans un mode où ils n’utilisent pas les API. La clé pour qu’un pilote puisse effectuer cette opération est la possibilité de case activée pour la présence des API après le chargement. Sans cette fonctionnalité, un pilote doit établir un lien statique avec les fonctions qu’il utilise, et si les fonctions ne sont pas présentes lors du chargement du pilote, le chargeur du noyau signale une erreur laide à l’utilisateur et ne parvient pas à charger le pilote.
La deuxième nouvelle API est MmGetPhysicalMemoryPages. Là encore, son prototype se trouve dans le RC2 ntddk.h, mais il n’est pas documenté. Son prototype est :
NTKERNELAPI
PPHYSICAL_MEMORY_RANGE
MmGetPhysicalMemoryRanges (
VOID
);
Où est PHYSICAL_MEMORY_RANGE :
typedef struct _PHYSICAL_MEMORY_RANGE {
PHYSICAL_ADDRESS BaseAddress;
LARGE_INTEGER NumberOfBytes;
} PHYSICAL_MEMORY_RANGE, *PPHYSICAL_MEMORY_RANGE;
Cette fonction retourne un tableau d’entrées PHYSICAL_MEMORY_RANGE avec la fin du tableau marquée par une entrée qui a 0 pour BaseAddress et NumberOfBytes. Comme MmGetSystemRoutineAddress, il s’agit d’une API assez simple. Il vous renvoie une description de toute la mémoire physique que Win2K connaît. Win2K prend en charge l’ajout et la suppression de mémoire à la volée avec les MmAddPhysicalMemory API et MmRemovePhysicalMemory . Cela motive la raison de l’existence d’une API qui vous permet d’interroger des plages de mémoire. MmAddPhysicalMemory a été ajouté dans RC1 et MmRemovePhysicalMemory dans RC2. Ces deux fonctions sont également prototypes dans ntddk.h.
Quelles sont les autres nouvelles API RC2 ? Voir PoShutdownBugCheck et RtlInvertRangeList. PoShutdownBugCheck vous permet de bloquer le système et d’effectuer une action liée à l’alimentation, comme la suspension. Il est utilisé à quelques endroits par le noyau RC2. Les plages sont des spécifications de début génériques définies par l’utilisateur et prises en charge par un certain nombre d’API de noyau pour la gestion, le tri et l’itération sur celles-ci. Les arbitres de ressources Plug-and-Play Win2K les utilisent pour suivre et organiser les besoins en ressources matérielles. Même si les API de liste de plages ne sont pas documentées, toutes leurs prototypes et définitions de structure sont inclus dans ntddk.h. Vous pouvez donc probablement utiliser l’API pour gérer vos propres données orientées start-end.
Restez à l’écoute pour plus de plaisir avec les API non documentées dans les bulletins d’informations suivants.
DÉVELOPPEMENT DE LOGICIELS 99 EAST
L’édition 1999 du développement logiciel sur la côte Est aura lieu à Washington D.C. du 8 au 12 novembre. Je présente trois présentations le dernier jour : Nouveautés de Windows 2000 pour les développeurs, À l’intérieur de l’écran bleu Windows NT/2000 et à l’intérieur de Windows NT/2000 Networking. En outre, Dave Solomon, auteur de Inside Windows NT 2nd Edition et un voisin (il habite à seulement 20 minutes de moi, de tous les endroits, Danbury, CT), et j’héberge une table ronde des internes Windows NT/2K. Nous serons ensemble pour répondre à vos questions les plus difficiles sur les composants internes de Windows NT/2K. Dites bonjour et mention la newsletter et je vais vous donner un t-shirt system Internals gratuit !
Visitez le site Web développement logiciel à l’adresse http://www.sdexpo.com.
UTILISATION DE DISKEDIT
Vous ne le savez peut-être pas, mais il existe un utilitaire d’éditeur de disque pour Windows NT dans le style du vénérable Norton Disk Edit pour DOS. De plus, l’utilitaire comprend FAT et NTFS et il est gratuit. Microsoft semble avoir livré accidentellement DiskEdit, un outil qui doit être un outil de débogage interne pour ses équipes de systèmes de fichiers, sur le CD-ROM Windows NT 4.0 Service Pack 4. DiskEdit a une interface particulière qui prendrait un petit manuel pour documenter, mais je vais vous aider à démarrer avec une procédure pas à pas simple. Je vais me concentrer sur l’utilisation de DiskEdit pour détricotage du format du système de fichiers NTFS, car DiskEdit est le seul outil disponible publiquement que je connais qui comprend NTFS.
Vous devez d’abord obtenir DiskEdit à partir du CD-ROM Service Pack 4 (SP4). Il vous suffit de le copier à partir du répertoire \i386 vers votre disque dur. Si vous souhaitez utiliser DiskEdit sous Win2K, vous devez créer un répertoire privé pour celui-ci et copier les DLL suivantes à partir d’un répertoire WINnt\system32 SP4 (ou SP4 CD) dans le même répertoire que DiskEdit : IFSUTIL.DLL, ULIB.DLL, UNTFS.DLL et UFAT.DLL. Vous pouvez maintenant démarrer DiskEdit.
Pour cette procédure pas à pas, créez un répertoire appelé TEMP à la racine d’un lecteur NTFS et créez un fichier appelé OUT.TXT dans ce répertoire en tapant la commande suivante dans une fenêtre d’invite de commandes avec TEMP comme répertoire actif : echo hello > out.txt. Sélectionnez le lecteur avec votre nouveau fichier OUT.TXT dans DiskModifier en choisissant Le fichier |Ouvrez l’élément de menu et entrez la lettre du lecteur dans le champ Nom du volume de la boîte de dialogue résultante. Veillez à inclure les deux-points, par exemple « d: ». Pratiquement toutes les fonctionnalités de DiskEdit nécessitent que vous ayez ouvert un lecteur.
Nous allons localiser le fichier OUT.TXT en commençant dans le répertoire racine du lecteur NTFS. Sélectionnez l’entrée de menu Lecture|Enregistrement de fichier NTFS pour ouvrir une boîte de dialogue qui vous permet d’afficher n’importe quelle entrée d’enregistrement MFT en entrant simplement son numéro. Les 16 premières entrées d’enregistrement MFT de chaque lecteur NTFS sont réservées et correspondent à des fichiers de métadonnées NTFS prédéfinis. Voici les attributions de nombre (notez que DiskEdit interprète toutes les entrées comme hexadécimales) :
0: $MFT - MFT
1: $MFTMirr - MFT Mirror (a copy of the first 4 entries of the MFT)
2: $LogFile - NTFS LogFile
3: $Volume - volume information file
4: $AttrDef - the attribute definition file
5: . - the root directory
6: $Bitmap - the volume allocation bitmap file
7: $Boot - the boot sector
8: $BadClus - the bad cluster database file
9: $Secure - new to SP4, the security attribute database
A: $UpCase - the lower-to-upper case mapping file
B: $Extend - new to Win2K, the directory that contains
the reparse, object ID, and quota metadata files
C-F: Unused as of NTFS v5.0 (Win2K)
Allez-y et examinez certaines de ces entrées MFT. Vous commencerez à remarquer un thème commun : ils se composent tous d’attributs tels que $INDEX_ROOT, $FILE_NAMEet $DATA. Il se trouve dans les attributs où sont stockées les données spécifiques à un fichier. Lorsque les données d’attribut sont de petite taille, NTFS stocke les données dans l’enregistrement MFT du fichier en tant que données « résidentes », et lorsque les données sont volumineuses, NTFS stocke les données externes à l’enregistrement dans les clusters sur le disque en tant que données « non résidentes ».
Entrez maintenant « 5 » comme numéro de fichier et vous allez afficher le fichier du répertoire racine. Nous allons examiner les fichiers et les répertoires qui se trouvent dans le répertoire racine en affichant l’attribut du $INDEX_ALLOCATION répertoire, un attribut spécifique aux répertoires qui enregistre le contenu d’un répertoire. Pour ce faire, sélectionnez Lire|Entrée de menu Attribut NTFS, qui ouvre une autre boîte de dialogue. DiskEdit est sensible à la casse, alors entrez ce qui suit exactement comme je l’ai listé :
Base Frs Number: 5
Base Frs (segment d’enregistrement de fichier de base) est un autre nom pour le numéro MFT. Vous entrez la valeur 5 pour spécifier que vous souhaitez lire un attribut à partir du répertoire racine.
Attribute Type: $INDEX_ALLOCATION
Cela indique à DiskEdit que vous souhaitez lire les données de contenu du répertoire. Je vous recommande d’utiliser le menu déroulant pour choisir l’attribut souhaité, car DiskEdit est très pointilleux quant à la façon dont le type d’attribut est entré.
Attribute Name: $I30
Si vous affichez l’attribut $INDEX_ALLOCATION du répertoire racine, vous verrez que « $I30 » est répertorié comme son nom dans sa ligne « Type code, name », c’est ce que vous entrez comme nom d’attribut.
Appuyez sur OK pour voir un vidage hexadécimal du contenu de l’attribut. Nous voulons voir quelque chose de plus intelligible, donc sélectionnez l’affichage|Entrée du menu Mémoire tampon d’index NTFS. Vous recevrez la liste du contenu du répertoire. Faites défiler la liste jusqu’à ce que vous voyiez l’entrée qui porte le nom « TEMP ». Si vous ne le voyez pas, l’entrée peut se trouver dans l’attribut du $INDEX_ROOT répertoire racine, un type d’attribut également associé aux répertoires, et dont la valeur est toujours stockée dans l’enregistrement MFT. Les entrées racines d’index et les entrées d’allocation forment ensemble une arborescence B+ qui stocke toutes les entrées d’un répertoire. Si vous devez afficher l’attribut $INDEX_ROOT, suivez simplement les mêmes étapes pour afficher cet attribut que pour afficher l’attribut $INDEX_ALLOCATION . Lorsque vous faites défiler une mémoire tampon d’index, vous pouvez rencontrer deux lignes d’astérisque : celles-ci désignent la fin d’une mémoire tampon d’index et le début de la suivante.
Une fois que vous avez trouvé l’entrée du répertoire TEMP, notez sa référence de fichier (FRS). Sélectionnez Lecture|Fichier NTFS Enregistrez et entrez FRS de TEMP. Vous examinez maintenant l’enregistrement MFT pour le répertoire TEMP. Nous voulons trouver le fichier OUT.TXT. Nous devons donc parcourir le contenu de TEMP pour le trouver. Affichez l’attribut $INDEX_ALLOCATION (ou $INDEX_ROOT) du répertoire TEMP, basculez vers l’affichage des données en tant que mémoire tampon d’index NTFS et recherchez le fichier OUT.TXT. N’oubliez pas d’entrer le FRS de TEMP comme numéro FRS de base dans la boîte de dialogue de sélection d’attributs. Si vous venez de créer TEMP, il n’y aura qu’un $INDEX_ROOT (si vous tapez mal quelque chose que vous aurez le plaisir de voir dans les boîtes de dialogue d’erreur vides de DiskEdit).
Lorsque vous avez trouvé OUT.TXT et déterminé son FRS, utilisez Read|Enregistrement de fichier NTFS pour examiner son entrée MFT. Faites défiler jusqu’à trouver l’attribut $DATA. Vous examinez maintenant l’emplacement des données de OUT.TXT. Étant donné que nous avons créé un petit fichier, les données sont stockées dans l’enregistrement MFT. Si vous essayez d’afficher l’attribut de OUT.TXT à l’aide de $DATA DiskEdit, vous ne verrez rien, car DiskEdit n’affiche pas correctement les données résidentes (l’un des nombreux bogues de DiskEdit). Copiez donc un gros fichier texte (> 2 Ko) dans le dossier \TEMP\ OUT.TXT. Vous pouvez maintenant afficher les données OUT.TXT de l’une des deux manières suivantes : vous pouvez examiner le début des données (ou la totalité si elles sont stockées de manière contiguë sur le disque) à l’aide de Read|Cluster NTFS et en spécifiant la première valeur « lcn » que vous voyez dans l’attribut de OUT.TXT « Liste d’étendues $DATA » ; ou vous pouvez utiliser Read|NTFS Attribut et entrez « $DATA » comme type d’attribut et rien (comme dans ne tapez rien dans ce champ) comme nom d’attribut.
Les listes d’étendues décrivent l’emplacement des données non résidentes d’un attribut. Chaque bloc contigu de données d’une longueur maximale de 16 clusters est décrit par une entrée de liste d’étendues. Une entrée de liste d’étendues spécifie un numéro de cluster virtuel (vcn), un numéro de cluster logique (lcn) et une longueur d’exécution. Un Vcn est le cluster dans le fichier où commencent les données décrites par l’entrée. Un Lcn désigne le cluster logique où les données sont stockées sur le disque, et le runlength correspond au nombre d’octets de données d’attribut à cet emplacement (n’oubliez pas que DiskEdit affiche des valeurs hexadécimales).
Je vous ai guide tout au long de la recherche de l’enregistrement MFT du fichier OUT.TXT en vous montrant comment analyser le contenu du répertoire. Il existe toutefois un raccourci : sélectionnez Crack|Chemin NTFS et entrez TEMP\OUT.TXT. Vous recevrez le FRS de OUT.TXT et vous pouvez utiliser Read|Enregistrement de fichier NTFS pour y accéder directement.
Cela m’amène à la fin de mon primer DiskEdit. Je vous encourage à utiliser cet outil pratique en parcourant vos disques FAT ou NTFS. Il est très peu probable que vous trouviez jamais l’occasion d’utiliser DiskEdit pour modifier des données afin de sortir votre disque d’un blocage, mais si vous êtes curieux de connaître le format NTFS sur disque (le format FAT est bien documenté), il s’agit de l’outil parfait pour examiner.
NOUVEAUTÉS À VENIR
EXPLOSION DE L’API WIN2K
Bien qu’il n’y ait que 4 nouvelles API exportées en mode noyau qui ont fait leurs débuts dans RC2, le nombre total d’API que Microsoft a introduites depuis NT 4.0, à la fois dans le noyau et dans les DLL Win32 principales, a explosé. Le mois prochain, je vais vous dire exactement combien il y a de nouvelles API et où elles sont apparues, et malheureusement en même temps donner aux gens qui croient que Win2K est un monstre gonflé quelques grandes munitions pour leurs alt.advocacy.linux usenet rants.
Merci d’avoir lu le bulletin d’information Systems Internals.
Publié le mercredi 20 octobre 1999 à 19 h 10 par ottoh
[Archives des newsletters ^] [< Volume 1, Numéro 4] [Volume 2, Numéro 1 >]