Partager via

  • Article

[Archives des newsletters ^] [< Volume 1, Numéro 1] [Volume 1, Numéro 3 >]

Bulletin d’information System Internals Volume 1, Numéro 2

http://www.sysinternals.com

15 mai 1999 : Dans ce numéro :

  1. NOUVEAUTÉS DE SYSTEMS INTERNALS

    • SDelete
    • Mise à jour Win2K de l’économiseur d’écran BlueScreen
    • « Linux et l’entreprise »
    • « À l’intérieur des utilitaires NT »
    • Ma colonne du magazine Windows NT de mai
    • Nouveautés pas si nouvelles

  2. ACTUALITÉS INTERNALS

    • Les mauvaises manières du Dr. GUI
    • WinDev '99 Est
    • Mise en production imminente du pilote Numega Works
    • DDK bêta 3 publié
    • Win2K Spinlocks en file d’attente

  3. NOUVEAUTÉS À VENIR

    • Win2K System File Protector (SFP)

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.

Bonjour,

Bienvenue dans la deuxième édition du bulletin d’informations Systems Internals. Le bulletin d’informations compte actuellement 2700 abonnés, avec des abonnements toujours forts.

Depuis la dernière lettre d’information, Microsoft a officiellement publié Windows 2000 Bêta 3. Le numéro de build du noyau bêta 3 est 2031, tandis que celui du noyau de version initiale de NT 4.0 était 1381 et que NT 3.51 avait un numéro de build de 1025. . Ce que je trouve étrange (et quelque peu ennuyeux), c’est que Microsoft incrémente le numéro de build chaque fois qu’il effectue une build complète du système d’exploitation (chaque jour de travail), cependant, le numéro de build signalé du noyau reflète celui de sa version publique initiale. Par exemple, même si le numéro de build réel du noyau NT 4.0 Service Pack 5 est beaucoup plus élevé que 1381, le noyau indique toujours 1381 comme numéro de build.

La version bêta 3 de Windows 2000 est destinée à être un appel de veille pour la communauté des développeurs. Microsoft a annoncé qu’il expédiera Windows 2000 en octobre, et que bêta 3 représente la version complète des fonctionnalités de ce qui sera livré, afin que les développeurs puissent commencer à écrire de nouveaux produits sans craindre que les choses changent en dessous.

Windows 2000 est fourni avec un grand nombre de nouvelles API, de services en couches et d’améliorations du noyau. Une modification qui sera particulièrement visible pour les développeurs de pilotes d’appareil est que l’écran bleu de la mort (BSOD) a changé. Dans les versions précédentes de NT, le BSOD affichait les informations d’heure de liaison et d’adresse de chargement pour tous les pilotes d’un système, ainsi qu’un vidage de la pile telle qu’elle existe au moment de l’incident. Dans Windows 2000, seuls le code stop et les lignes d’adresse associées (les lignes d’adresse traduisent un ou plusieurs paramètres de code d’arrêt en emplacements dans les pilotes de périphérique) sont affichés, ainsi qu’un message détaillé. Le message d'assistance vous suggère de vérifier les paramètres du BIOS et du disque dur, et de désactiver les logiciels de défragmentation et les scanners de virus afin d'éviter que le problème ne se reproduise. Les services de support Technique Microsoft Premier (PSS) ont déterminé, en fonction de leur expérience et des commentaires des clients, que le BSOD de style NT 4 n’est pas utile pour déterminer la cause d’un incident.

Personnellement, j'ai trouvé la liste des pilotes chargés, et en particulier le vidage de la pile (stack dump), utile pour obtenir des rapports de bogues de pilotes de la part des utilisateurs - il est beaucoup plus facile et rapide d'obtenir ces informations que de demander aux utilisateurs d'envoyer un crash dump de plusieurs mégaoctets. J’ai souvent isolé la cause du plantage en fonction du vidage de la pile et des versions de pilotes vérifiées que les utilisateurs ont chargées en fonction des informations de version affichées dans la liste des pilotes. Je suis curieux de savoir ce que vous en pensez : souhaiteriez-vous que la BSOD de type NT 4 soit reprise dans Windows 2000, ou le nouveau format de BSOD est-il suffisant ? Envoyez-moi un e-mail si vous avez un avis. Je vous ferai rapport des résultats de ce sondage informel dans le prochain bulletin. Puisque je parle de BSOD, ne manquez pas de jeter un coup d’œil à la mise à jour pour Windows 2000 de l'économiseur d'écran BlueScreen de Systems Internals, toujours très populaire, qui fait l'objet d'un article dans ce numéro.

Merci !

- Mark

NOUVEAUTÉS DE SYSTEMS INTERNALS

SDELETE

Dans le cadre de Windows NT 4.0 qui répond aux exigences de classification de sécurité C2, il implémente la « protection contre la réutilisation des objets ». Cela signifie que NT met à zéro les ressources de fichiers et de mémoire allouées par les applications lorsque celles-ci accèdent à ces ressources pour la première fois. Cela empêche une application, par exemple, de créer un fichier volumineux et d’examiner son contenu pour voir ce qui était précédemment stocké sur disque. Toutefois, la protection contre la réutilisation des objets ne permet pas de protéger les ressources accessibles par les applications qui contournent les API liées aux ressources standard ou qui contournent complètement le système d’exploitation. Par exemple, vous pouvez utiliser un éditeur de disque, tel que DiskProbe du Kit de ressources, pour examiner le contenu des parties non allouées d’un disque. Cela vous permet de voir les données qui appartenaient précédemment à des fichiers supprimés.

De nombreux environnements nécessitent une fonctionnalité de « suppression sécurisée ». Cette fonctionnalité permet aux utilisateurs de supprimer définitivement les données sensibles afin qu’elles ne soient pas visibles par les outils qui contournent les fonctionnalités de protection du système d’exploitation. L’avènement du système de chiffrement de fichiers (EFS) a mis en évidence la nécessité d’une fonctionnalité de suppression sécurisée dans Windows 2000. Lorsque vous chiffrez un fichier précédemment non chiffré, EFS n’efface pas le contenu des allocations de disque qui contenaient les données non chiffrées du fichier lorsqu’il libère les allocations de disque. Ainsi, même si la version active d’un fichier que vous chiffrez est sécurisée, l’ancienne version du fichier existe toujours dans les parties non allouées d’un disque jusqu’à ce qu’elle soit remplacée par de nouvelles données de fichier que NTFS attribue à ces parties.

Pour combler ce trou, j’ai écrit SDelete (Suppression sécurisée). Il s’agit d’un outil en ligne de commande qui vous permet non seulement de supprimer en toute sécurité des fichiers standard, mais également de supprimer en toute sécurité toutes les données précédemment supprimées qui existent dans les parties non allouées d’un disque. En outre, il fonctionne avec les fichiers compressés, chiffrés et épars de Windows NT/2000, ce qui nécessite l’utilisation de l’API de défragmentation. SDelete adhère à la norme DOD 5220.22-M du département de la Défense, afin que vous puissiez être sûr qu’une fois que vous avez supprimé des données, elles disparaissent pour toujours.

Je fournit à SDelete le code source complet et une description de son fonctionnement, afin que vous puissiez voir comment elle utilise l’API de défragmentation et que vous puissiez vérifier que mes revendications empêcheront vos données sensibles supprimées d’être récupérables.

Vous trouverez de la documentation sur l’API de défragmentation Windows NT/2000 à l’adresse http://www.sysinternals.com/defrag.htm. Téléchargez SDelete avec le code source complet à l’adresse http://www.sysinternals.com/sdelete.htm.

MISE À JOUR WIN2K DE L’ÉCONOMISEUR D’ÉCRAN BLUESCREEN

Les modifications apportées par Microsoft à l’écran de démarrage NT et à la disposition de l’écran bleu de la mort (BSOD) dans Windows 2000 ont fait en sorte que l’économiseur d’écran BlueScreen Systems Internals nécessite une mise à jour majeure. Afin de continuer à vous fournir le maximum de réalisme BSOD, j’ai publié la version 2.0 de l’économiseur d’écran. Il reflète non seulement les modifications apportées au format BSOD, mais imite également avec précision l’écran de démarrage de Windows 2000, avec la rotation de la bande de progression et des mises à jour de la barre de progression. Il est si réel que l’économiseur d’écran trompera même les utilisateurs et les développeurs experts de Windows 2000. Bien sûr, sous NT 4.0 l’écran de veille BlueScreen présente toujours les écrans BSOD et de démarrage NT 4.0.

Comment ai-je recréé l’écran de démarrage de Windows 2000 si parfaitement et en même temps ne pas violer les lois sur le droit d’auteur ? Je n'inclus pas les graphiques bitmap de démarrage de Windows 2000 dans l’écran de veille. Au lieu de cela, j’utilise DirectX pour basculer le mode graphique vers celui utilisé par Windows 2000 pendant la séquence de démarrage, puis je référence les ressources bitmap du fichier de noyau Windows 200, ntoskrnl.exe. Ces ressources (vous pouvez les afficher en ouvrant les ressources de ntoskrnl.exe dans Visual Studio) sont celles que le noyau affiche, ce qui est un changement par rapport à la façon de faire Windows 9x où les graphiques de démarrage sont en fait des fichiers distincts. Il ne semble pas que les OEM informatiques auront la possibilité de personnaliser l’expérience de démarrage dans Windows 2000...

Vous pouvez télécharger l’économiseur d’écran BlueScreen à l’adresse http://www.sysinternals.com/bluescreen.htm. Si vous avez une anecdote humoristique liée au fait d'avoir trompé quelqu'un avec l'économiseur d'écran, n'hésitez pas à la transmettre.

Vous trouverez plus d’informations sur le fonctionnement et le pourquoi des BSOD dans ma colonne interne de Windows NT Magazine NT de décembre 1997, « Inside the Blue Screen ». Un lien dans la page Publications de Systems Internals, http://www.sysinternals.com/publ.htm, vous permet d’accéder à la version en ligne de cette colonne. La page contient également des liens vers d’autres présentations en ligne d’articles et de colonnes que j’ai créés.

« LINUX ET L’ENTREPRISE »

L’énorme réponse de la communauté Linux à mon article dans le numéro d’avril de Windows NT Magazine sur les lacunes de scalabilité du noyau Linux a incité le magazine à publier la version en ligne de l’article avant la planification. Vous trouverez un lien vers l’article « Linux et l’Entreprise », dans la section « Articles » à l’adresse http://www.sysinternals.com/publ.htm. L’article décrit plusieurs limitations de la version actuelle du noyau Linux (2.2x), notamment l’absence d’un mécanisme efficace d’attente d’événements, la sérialisation significative des appels système, l’absence d’E/S asynchrones et une implémentation médiocre de l’API de socket sendfile (dans NT, son appelée TransmitFile). La combinaison de ces limitations empêche Linux de concurrencer NT et d’autres UNIX, en termes de performances, sur des applications de classe entreprise comme les serveurs web, les serveurs de base de données et les serveurs de messagerie.

« À L’INTÉRIEUR DES UTILITAIRES NT »

Si vous avez utilisé Filemon, Regmon ou HandleEx et que vous souhaitez en savoir plus sur ce qu’ils vous disent et la façon dont ils sont implémentés, vous serez intéressé par ma colonne du magazine Windows NT de février, « À l’intérieur des utilitaires NT ». Cette colonne décrit les éléments internes de ces outils, et pour Regmon et Filemon, vous indique un peu les codes d’erreur et les types de requêtes qu’ils consignent lors de la capture de l’activité du Registre ou du système de fichiers. Un lien vers la version en ligne de cet article, qui vient d’être disponible, se trouve à l’adresse http://www.sysinternals.com/publ.htm.

MA COLONNE DU MAGAZINE WINDOWS NT DE MAI

Vous êtes-vous déjà demandé comment Windows NT/2000 organisait le contenu du registre en mémoire ou sur disque ? Le numéro actuel (mai) de Windows NT Magazine inclut ma colonne « À l’intérieur du registre », qui vous indique ceci et bien plus encore. Par exemple, découvrez comment le Gestionnaire de configuration sous-système en mode noyau (le sous-système responsable de la gestion du Registre) recherche les clés, stocke les données de valeur, optimise la recherche et protège l’intégrité des fichiers sur disque du Registre. Windows NT Magazine, http://www.winntmag.com, est disponible sur Borders et Barnes and Nobles.

NOUVEAUTÉS PAS SI NOUVELLES

Peu de temps après la publication de Windows 2000 Bêta 2, j’ai pris la build Checked (débogage) du fichier image du noyau (ntoskrnl.exe), effectué une recherche sous forme de chaînes sur le noyau et fourni une liste des noms des fichiers sources utilisés pour générer le noyau. La build Checked du noyau NT/2000 contient de nombreuses instructions Assert (vérifications de cohérence) qui incluent le nom du fichier dans lequel se trouve l’Assert. En supposant que pratiquement tous les fichiers d’une importance quelconque dans la source du noyau ont au moins un Assert, la liste est assez complète. Le fait de vider la liste dans un script Java m’a donné une belle vue d’ensemble Explorer de la structure de répertoires de l’arborescence source Windows 2000. Voyez par vous-même sur http://www.sysinternals.com/nt5src.htm.

ACTUALITÉS INTERNALS

LES MAUVAISES MANIÈRES DE DR GUI

Dans le numéro de mars/avril de Microsoft Developer Network News, Dr. GUI pose une question à un lecteur qui demande comment un pilote peut affiner (forcer à utiliser un processeur spécifique) ses threads. Dr. GUI répond qu’il n’existe aucun moyen de déterminer le nombre de processeurs sur un système à partir d’un pilote, et qu’un thread de pilote ne peut pas dire sur quel processeur il s’exécute. Malheureusement, le Dr. GUI a fait échouer ce diagnostic (peut-être le Dr. GUI devrait-il s'en tenir aux GUI).

Le noyau NT (ntoskrnl.exe) exporte une variable nommée KeNumberProcessors définie dans NTDDK. H comme :

extern PCCHAR KeNumberProcessors;

Il peut être directement référencé dans un pilote comme suit :

CHAR    i;

for( i = 0; i < *KeNumberProcessors; i++ ) {

    // do processor specific stuff
}

Pour déterminer le processeur sur lequel un thread de pilote s’exécute, utilisez KeGetCurrentProcessorNumber(), une autre exportation de noyau qui n’est pas seulement définie dans NTDDK. H, mais est en fait documenté dans le DDK !

Le Dr GUI a prescrit le mauvais médicament pour cette maladie, et je l'ai poliment informé par e-mail. De manière surprenante, le Dr. GUI n'a même pas accusé réception de l'e-mail. Nous verrons si le Dr. avoue son erreur dans le prochain numéro...

WINDEV '99 EAST

L’édition 1999 de la côte Est de la première conférence pour les développeurs Windows approche à grands pas. WinDev '99 East aura lieu du 14 au 18 juin au Boston Cambridge Marriot. Un certain nombre de grands noms du développement Windows parlent, notamment Jeff Richter, Jeff Prosise et Don Box. Je serai là avec Jamie Hanrahan et Brian Catlin sur la piste des pilotes de périphérique. Mes présentations incluent un tutoriel d’une journée sur les composants internes NT, ainsi qu’un tutoriel sur l’écriture de pilotes de système de fichiers Windows NT/2K et un autre sur les problèmes de développement de pilotes de périphérique avancés. Venez dire bonjour !

MISE EN PRODUCTION IMMINENTE DU PILOTE NUMEGA

Compuware NuMega Labs est sur le point de publier un nouveau kit de développement de pilote de périphérique Windows 9x/NT/2K puissant, DriverStudio. DriverStudio combine tous les outils de pilote de périphérique existants de NuMega, notamment DriverAgent, DriverWorks, SoftICE et VtoolsD, et ajoute le nouveau BoundsChecker pour les pilotes et FieldAgent (Windows NT/2K uniquement).

La version du pilote de périphérique de BoundsChecker fournit une surveillance complète de chaque API de noyau que votre pilote utilise, et vous pouvez l’utiliser pour surveiller les interactions de votre pilote avec n’importe quel autre pilote de périphérique sur le système. FieldAgent vous permet de déployer la version du pilote de BoundsChecker sur les systèmes clients afin que les clients puissent collecter des traces pour vous que vous puissiez analyser. Bientôt une mise à jour gratuite pour les clients DriverStudio sont TrueTime pour les pilotes et TrueCoverage pour les pilotes, des outils qui vous permettent d’ajuster facilement les performances et de tester la couverture de vos pilotes de périphérique.

Ce package est le kit de développement de pilote ultime, et je le recommande vivement (je suis sur le programme bêta). Découvrez-en plus ici http://www.numega.com.

VERSION BÊTA 3 DDK PUBLIÉE

Conjointement avec la version de Windows 2000 Beta 3, Microsoft a mis à disposition en téléchargement gratuit le DDK Windows 2000 Beta 3 (Device Driver Kit). Vous pouvez récupérer le DDK à l’adresse http://www.microsoft.com/ddk/ddk2kb3.htm. J’espère que le SDK suivra bientôt, car il existe un certain nombre d’API Win32 dans la version bêta 3 qui ne sont pas documentées à partir de l’édition d’avril de MSDN.

SPINLOCKS EN FILE D’ATTENTE WIN2K

Windows 2000 utilise un nouveau type de spinlock appelé « spinlock en file d’attente » pour ses verrous globaux. Les verrous globaux dans Windows 2000 sont les mêmes que ceux de Windows NT 4.0 et incluent :

  • KiDispatcherLock : verrou de base de données du planificateur
  • KiContext-SwapLock : verrou d’échange de bande de roulement
  • MmPfnLock : verrou de base de données de trame de page physique
  • MmSystemSpaceLock : verrou d’espace d’adressage en mode noyau
  • CcMasterSpinLock : verrouillage global du gestionnaire de cache
  • CcVacbSpinLock : verrou de tableau de mappage du Gestionnaire de cache

Sur un uniprocesseur, les spinlocks en file d'attente fonctionnent exactement comme les spinlocks normaux. Toutefois, sur la build multiprocesseur de NT, les spinlocks en file d’attente sont considérablement différents. À l’instar des spinlocks standard, les spinlocks en file d’attente sont implémentés dans le HAL. Le noyau appelle la fonction HAL KeAcquireQueuedSpinlock pour acquérir un spinlock en file d’attente, et appelle KeReleaseQueuedSpinlock pour libérer un spinlock en file d’attente. KeAcquireSpinlock et KeReleaseSpinlock, les fonctions HAL que le noyau utilise pour acquérir et libérer des spinlocks standard, nécessitent l’adresse du spinlock spécifié en tant que paramètre. En revanche, les fonctions de spinlocks en file d’attente prennent le numéro d’index d’un spinlock global. Le noyau initialise les spinlocks globaux dans un tableau, où chaque spinlock a un numéro d’index prédéfini que le noyau utilise pour les identifier dans le HAL. Par conséquent, les spinlocks en file d’attente ne peuvent pas être définis et utilisés par les pilotes de périphérique, car il n’existe aucun moyen d’augmenter le tableau global de spinlocks mis en file d’attente.

Dans Windows 2000, chaque région de contrôle du processeur (PCR) dans un SMP (il y a un PCR pour chaque processeur) a un tableau avec autant d’entrées qu’il y a de spinlocks en file d’attente. Chaque entrée de tableau contient deux champs : un pointeur vers le spinlock en file d’attente auquel elle correspond (le champ « spinlock ») et le champ « file d’attente ». Dans la description suivante, lorsque je fais référence aux champs de spinlock et de file d’attente, je parle des champs associés à l’entrée de tableau pour le spinlock en cours d’acquisition ou de libération.

KeAcquireQueuedSpinlock Fonctionne comme suit : la fonction tente d’acquérir le verrouillage tournant à l’aide de l’instruction de processeur d’échange interblocage pour placer l’adresse de la PCR du processeur actuel dans le spinlock. Si le verrouillage tournant est maintenu, la fonction a, dans le cadre de l’opération d’échange, l’adresse du PCR d’un autre processeur. Ensuite, la fonction s’identifie comme « en attente » en basculant le bit inférieur du champ de spinlock dans son propre PCR. Ensuite, il place sa propre adresse PCR dans le champ de file d’attente du PCR qu’il a récupéré à partir du spinlock. Enfin, il attend dans une boucle occupée jusqu’à ce que le bit faible soit désactivé dans son champ de spinlock lorsque le bit est désactivé, puis que le processeur actuel a reçu le spinlock et qu’il retourne donc à l’appelant de la fonction d’acquisition.

Une fois qu’un processeur a acquis un spinlock en file d’attente et terminé le traitement qu’il voulait effectuer tout en maintenant le verrou, il appelle KeReleaseQueuedSpinlock. KeReleaseQueuedSpinlock examine le champ file d’attente pour le spinlock spécifié dans le PCR du processeur actuel. Si le champ de file d’attente n’est pas égal à zéro, un autre processeur y a « mis en file d’attente » son PCR. KeReleaseQueuedSpinlock Efface le bit faible du champ de spinlock pour le PCR en attente, puis efface son propre champ de file d’attente et retourne. En effaçant le bit faible dans le champ de spinlock de la PCR en attente, il vient de signaler au processeur suivant qu’il peut avoir le verrou. Si le champ de file d’attente était égal à zéro, aucun autre processeur n’attend le verrou et KeReleaseQueuedSpinlock effectue simplement une opération d’échange interblocage pour effacer le spinlock global.

L’opération des spinlocks mis en file d’attente est une opération dans laquelle les processeurs « alignent » en attente d’un spinlock qui est maintenu. Chaque processeur se met en file d'attente en indiquant à celui qui le précède qu'il attend. Cela fournit un ordre déterministe pour l’acquisition d’un processeur de spinlock en file d’attente que les processeurs acquièrent le spinlock dans l’ordre dans lequel ils le demandent. Pour les spinlocks standard, il n’existe aucun ordre de ce type. Les spinlocks en file d’attente présentent un autre avantage plus significatif. Comme un processeur tourne en attendant que son champ de spinlock ait le bit faible effacé, il tourne sur la mémoire privée vers son propre processeur. Lorsqu’un processeur occupé attend un spinlock standard, il tourne sur le spinlock global lui-même, qui est partagé par tous les processeurs. Ainsi, les spinlock mis en file d’attente ont de meilleures caractéristiques de bus multiprocesseur, car il n’y a pas d’accès à la ligne de cache partagée pendant l’attente occupée. En outre, en raison de la nature de la file d'attente des spinlocks, il y a généralement moins d'opérations de verrouillage du bus que pour les spinlocks standard lorsqu'un verrou est en concurrence avec plusieurs processeurs.

Les spinlocks en file d'attente sont l'une des nombreuses améliorations que Microsoft a apportées à l'évolutivité du multiprocessus de Windows 2000.

NOUVEAUTÉS À VENIR

Windows 2000 inclut de nombreuses fonctionnalités qui le rendent plus résilient aux erreurs d’opérateur et aux applications mal conduites. L’un d’eux est que la plupart des DLL et pilotes sous le %systemroot%\system32 répertoire et %systemroot%\system32\drivers sont protégés par un chien de garde appelé SFP (System File Protector). Vous pouvez vérifier son existence en accédant à ce répertoire system32 et en renommant ntoskrnl.exe. Le chien de garde se réveille et vous informe qu’il a détecté une falsification avec un fichier système protégé et qu’il est en cours de réparation. Si vous vérifiez à nouveau le répertoire, vous constaterez que ntoskrnl.exe a été remplacé par magie. La prochaine fois, je vais vous dire comment cela fonctionne.

Merci d’avoir lu le bulletin d’information Systems Internals.

Publié le samedi 15 mai 1999 19:15 par ottoh

[Archives des newsletters ^] [< Volume 1, Numéro 1] [Volume 1, Numéro 3 >]