[Archives des newsletters ^] [Volume 1, Numéro 2 >]
Bulletin d’information The Systems Internals Volume 1, numéro 1
14 avril 1999 – Dans ce numéro :
NOUVEAUTÉS DE SYSTEMS INTERNALS
- VolumeID pour Windows 9x
- EFSDump
- ListDLs pour Compaq Alpha
- « À l’intérieur du processus de démarrage, partie 2 »
- Mon article du magazine Windows NT d’avril
- Aucun crédit en cas d’échéance
- Nouveautés pas si nouvelles
ACTUALITÉS INTERNES
- Vérificateur de pilotes Win2K
- Test Y2K avec Boot.ini
NOUVEAUTÉS À VENIR
- Spinlocks en file d’attente dans Win2K
- Tokenmon
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 le premier volet du bulletin d’information Systems Internals. J'ai le plaisir de vous annoncer que la lettre d'information a déjà gagné 1 000 abonnés depuis son annonce il y a un peu plus d'une semaine.
Mon objectif dans le bulletin d’informations est de vous fournir des informations en temps opportun sur les nouveaux utilitaires et articles qui apparaissent dans Systems Internals, ainsi que de vous donner des informations sur les internes Windows qui n’ont pas de forum approprié sur le site web Systems Internals. Si vous avez des commentaires ou des suggestions concernant le bulletin, n’hésitez pas à me les transmettre à mark@.... En outre, veuillez transférer le bulletin à toute personne que vous connaissez et qui pourrait être intéressée par celui-ci. Des instructions sur l’abonnement, la désinscription ou la modification de votre abonnement sont fournies à la fin de la newsletter.
Merci !
- Mark
NOUVEAUTÉS DE SYSTEMS INTERNALS
VOLUMEID POUR WINDOWS 9X
Bien que Windows NT et Windows 9x vous permettent de modifier l’étiquette sur un lecteur logique ou une disquette à l’aide de la commande « étiquette », ils ne vous permettent pas de modifier les ID de volume qu’ils attribuent arbitrairement lorsque vous formatez des lecteurs. Le programme VolumeID, disponible pour Windows NT sur le site Systems Internals depuis plus d’un an, vient d’être porté vers Windows 9x. Cette applet vous permet de modifier les ID de volume sur les disques durs et les disquettes comme vous le souhaitez.
VolumeID utilise des API qui permettent aux applications de lire et d’écrire directement sur des lecteurs logiques, et sur Win9x, des lecteurs physiques (disquettes), en contournant les systèmes de fichiers. Sur Windows NT/2K VolumeID utilise ReadFile et WriteFile standard pour accéder aux données du lecteur brut. L’astuce consiste à spécifier le nom du volume auquel il souhaite accéder. Vous pouvez découvrir comment accéder à des lecteurs physiques ou logiques à partir d’une application sous Windows NT/2K dans l’article de la Base de connaissances Microsoft Q100027. Pour l’accès Windows 9x aux lecteurs logiques, vous pouvez baser votre code sur l’exemple de code fourni dans l’article de la Base de connaissances Microsoft Q174569. Si vous devez effectuer un accès direct au lecteur de disquette à partir de votre application sur Windows 9x, utilisez le VWIN32_DIOC_DOS_INT13 IOCTL Win32, qui est documenté dans MSDN.
Télécharger VolumeID à l’adresse http://www.sysinternals.com/misc.htm.
EFSDUMP
Windows 2000 sera le début de la technologie de chiffrement de fichiers intégrée de Microsoft, le système de fichiers de chiffrement. Avec EFS viennent un certain nombre de nouvelles API pour manipuler des fichiers chiffrés, dont une, QueryUsersOnEncryptedFile, qui vous permet de voir quels utilisateurs sont inscrits pour avoir accès aux fichiers chiffrés et quels utilisateurs sont inscrits en tant qu’agents de récupération pour ces fichiers. J’ai écrit un petit programme appelé EFSDump qui vous permet de voir facilement ces informations pour les fichiers chiffrés sur votre système.
Bien que je parle des API EFS, il existe un certain nombre de nouvelles API qui n’ont pas été documentées à partir de MSDN d’avril, ce qui est assez troublant à ce stade avancé du cycle de publication de Windows 2000. Plus particulièrement, OpenEncryptedFileRaw, ReadFileEncryptedRaw, WriteFileEncryptedRaw et CloseEncryptedFileRaw (tous exportés par le ADVAPI32.DLL de Win2K) ne sont actuellement pas documentés. L'utilisation de ces API est requise par toute application souhaitant sauvegarder des fichiers cryptés, ce qui signifie que soit Microsoft ne transmet des informations à leur sujet qu'à des partenaires sélectionnés, soit les éditeurs de logiciels de sauvegarde vont devoir faire des pieds et des mains pour sortir leurs produits lorsque Microsoft finira par les documenter publiquement. Une chose est certaine, les développeurs du programme NTBACKUP de Windows 2000 ont déjà eu accès à la documentation de l’API : NTBACKUP de Win2K Beta 3 utilise activement les API.
Si les aspects internes de l'EFS vous intéressent, n'oubliez pas de consulter ma prochaine série en deux parties de juin/juillet sur l'EFS dans ma rubrique « NT Internals » de Windows NT Magazine. Dans cet article, je décris exactement où les FEK (File Encryption Keys) et les clés EFS des utilisateurs sont stockées, comment le processus de cryptage est effectué par NTFS, le pilote EFS et LSASRV (Local Security Authority Subsystem Server), et bien sûr, comment fonctionne le décryptage.
Téléchargez EFSDump avec le code source complet à l’adresse http://www.sysinternals.com/misc.htm.
LISTDLLS POUR COMPAQ ALPHA
Le nombre d’utilitaires disponibles pour l’Alpha chez Systems Internals continue de croître. Le dernier ajout est ListDLLs, un utilitaire de ligne de commande qui vous permet d’afficher les informations dll pour les processus en cours d’exécution. Mon outil HandleEx vous permet de voir ces informations, ainsi que des informations sur les handles (fichiers, processus, threads, objets de synchronisation) que les processus ont ouverts, mais HandleEx est un outil GUI qui n'est pas toujours pratique (il ne peut pas être exécuté dans un fichier batch par exemple).
Êtes-vous curieux de connaître le rapport entre les téléchargements de la version x86 de l’utilitaire Systems Internals classique et sa version Alpha correspondante ? Son environ 20:1, qui suit de près les estimations de l’industrie de la base d’utilisateurs Alpha NT installés comme étant 5% du marché total NT.
Vous pouvez télécharger ListDLLs et d’autres ports Alpha, y compris HandleEx, à l’adresse http://www.sysinternals.com/alpha.htm.
« À L’INTÉRIEUR DU PROCESSUS DE DÉMARRAGE, PARTIE 2 »
Ma colonne « NT Internals » de janvier de Windows NT Magazine est désormais disponible en ligne sur le site web de Windows NT Magazine. Vous trouverez un lien vers celle-ci, ainsi que vers les colonnes « NT Internals » de la partie 1 et des anciennes colonnes « NT Internals », dans la page Publications à l’adresse Systems Internals : http://www.sysinternals.com/publ.htm.
MON ARTICLE DU MAGAZINE WINDOWS NT AVRIL
Ne manquez pas non plus de lire mon article de fond dans le numéro d'avril de Windows NT Magazine, intitulé « Linux and the Enterprise ». Je révèle plusieurs problèmes importants concernant les applications de noyau et de serveur réseau Linux 2.2 (« applications d’entreprise ») qui empêcheront finalement cette version du noyau Linux de concurrencer NT et d’autres variantes UNIX en termes de performances.
AUCUN CRÉDIT À L’ÉCHÉANCE
Sur une note connexe, vous avez peut-être entendu parler de la publication récente de D.H. Brown (une société d’analyste) sur Linux en tant que système d’exploitation d’entreprise. Il s'avère que l'auteur du rapport a largement « emprunté » un de mes courriels que quelqu'un a publiquement posté sur le groupe de discussion Usenet du noyau Linux en janvier dernier. Si vous avez accès au rapport et lisez les pages (44 et 45) qui traitent de Linux et des multiprocesseurs (le rapport n'est pas accessible au public - il faut l'acheter pour une somme importante), et que vous lisez ensuite mon courriel à Deja News, vous verrez un parallèle direct, jusque dans les moindres détails.
NOUVEAUTÉS PAS SI NOUVELLES
J’utilise cette section du bulletin d’informations pour faire état des modifications récentes apportées au site Systems Internals que vous ne connaissez peut-être pas, et/ou pour fournir plus d’informations sur un utilitaire que ce qui est disponible sur le site. Par exemple, il y a quelques semaines, nous avons publié Filemon v4.1. Cette version de Filemon est capable de surveiller à la fois l’activité du canal nommé et de l’emplacement de messagerie sous Windows NT/2K. L’amélioration du code nécessaire à la prise en charge de cette opération était relativement mineure, car les canaux nommés et les Mailslots sont implémentés en tant que pilotes de système de fichiers. La partie difficile (fastidieuse) a été de déterminer les IOCTL privés (commandes de contrôle d’E/S) que ces systèmes de fichiers spéciaux prennent en charge afin que Filemon puisse les montrer. Vous pouvez télécharger Filemon (qui fonctionne sur Windows NT/2K et Windows 9x) à l’adresse http://www.sysinternals.com/filemon.htm.
Si vous souhaitez en savoir plus sur le fonctionnement interne de Filemon, consultez ma colonne « Internes NT » du Magazine Windows NT de février, intitulée « Inside NT Utilities ». L’article explique comment utiliser Filemon, Regmon, NTFSDOS, NewSID et HandleEx, et vous explique un peu comment ils fonctionnent.
ACTUALITÉS INTERNES
VÉRIFICATEUR DU PILOTE WINDOWS 2000
Windows 2000 Bêta 3 introduit une aide au développement de pilote d’appareil très puissante appelée Driver Verifier. Cet outil fonctionne avec le code dans le noyau pour prendre le contrôle de votre pilote et l’exercer pour le respect des règles de mode noyau d’une manière qui n’était pas possible auparavant. Les pilotes de périphériques buggy sont de loin la contribution la plus importante à la réputation de nombreuses personnes que NT est un système d’exploitation instable, et cet outil est destiné à réparer cette réputation en aidant les rédacteurs de pilotes à trouver leurs bogues avant que les utilisateurs ne le fassent.
Plusieurs types de problèmes subtils peuvent passer par des tests de conduite occasionnels (le type le plus courant d’essais effectués dans des délais de commercialisation serrés) et même passer par des tests de résistance sérieux. Un type de problème de pilote courant est un pilote qui accède à la mémoire paginée à « IRQL élevé » (priorité d’interruption élevée). Si la mémoire accessible par le pilote est physiquement présente au moment de l’accès (elle n’a pas été paginée dans le fichier de pagination), l’accès non autorisé passe inaperçu. Relâchez un pilote qui viole cette règle dans le monde sauvage des utilisateurs et sa limite d’apparaître, ce qui entraîne un plantage de l’écran bleu.
Un autre type d’erreur de programmation de pilote courante consiste pour un développeur à écrire le code en supposant que la mémoire paginée et/ou non paginée sera toujours disponible, c’est-à-dire qu’ils ne vérifient pas les valeurs de retour pour les allocations. Si le pool s’exécute et que le pilote reçoit une adresse de mémoire tampon NULL, le pilote déréférence le système en écran bleu. Bien que l’épuisement du pool soit rare, ce n’est pas quelque chose qui devrait donner un écran bleu à un administrateur système. Un bogue de mémoire associé est un dépassement ou une sous-exécution de mémoire tampon, où un pilote lit ou écrit en dehors d’une mémoire tampon qu’il a allouée.
Le vérificateur de pilotes résout les problèmes IRQL en remplaçant les appels à toutes les fonctions qui manipulent des IRQL dans un pilote (par exemple KeRaiseIrql, KeAcquireSpinLock) par des fonctions de noyau de vérificateur correspondantes (VerifierKeRaiseIrql, VerifierKeAcquireSpinLock) au moment du chargement du pilote. Chaque fois que l’IRQL est élevé à DISPATCH_LEVEL ou à une valeur supérieure, le code du vérificateur appelle une fonction Memory Manager interne, MmTrimAllPageableSystemMemory(), pour forcer toutes les données paginées à sortir de la mémoire physique. Par conséquent, au moment où un pilote interrompt la règle IRQL de ne pas accéder aux données ou au code paginables à partir de DISPATCH_LEVEL ou à partir d’une version ultérieure, le Gestionnaire de mémoire détecte la tentative d’accès à une page non présente et lève un écran bleu. Cela permet au développeur de détecter rapidement ce type de bogues avant que le pilote ne sorte, puisqu'il peut déboguer la panne et voir son pilote sur la pile de fautes.
Le vérificateur de pilotes effectue des tests d’utilisation de la mémoire en corrigeant la table d’importation du pilote à vérifier afin que le pilote appelle les fonctions de mémoire du vérificateur au lieu des versions standard du noyau. Dans l'exemple ci-dessus, l'appel à ExAllocatePool est remplacé par un appel à VerifierAllocatePool. Le vérificateur utilise deux techniques pour aider un développeur à trouver rapidement des bogues de mémoire. La première est qu’il utilise un pool de mémoire spécial où une page de garde (une page de garde est une page non valide) est placée juste après la fin de la mémoire tampon. En outre, la partie de la page dans laquelle la mémoire tampon est allouée qui précède la mémoire tampon est remplie d’une signature. Les dépassements qui se trouvent dans une page au-delà de la fin d’une mémoire tampon sont détectés immédiatement, car ils entraînent des erreurs de page illégales sur la page de protection. Les sous-exécutions qui impliquent une modification des données précédant une mémoire tampon sont détectées par le vérificateur lorsque le pilote libère la mémoire, car la signature aura changé.
Les pilotes qui s’attendent toujours à ce que le pool non vide soit trompé dans la génération de plantages par le vérificateur avec l’utilisation de son « injection d’erreur de mémoire ». Vous pouvez configurer le vérificateur pour qu’il échoue de manière aléatoire les allocations de pool d’un pilote.
Il existe quelques autres types d’erreurs que le vérificateur de pilotes recherche, notamment la cohérence IRP (E/S Request Packet) et la protection en lecture seule des pages de code système et de pilote.
Si vous êtes développeur de pilotes d’appareil, vous serez favorable à vous-même, à votre entreprise et à la communauté NT en testant avec le vérificateur. Notez que vous devez également tester vos pilotes NT 4.0 compatibles avec Win2K dès que vous avez accès au vérificateur de pilotes (la plupart des développeurs l’obtiendront avec l’envoi de Win2K Beta 3 par MSDN fin avril ou mai).
Pour plus d’informations, consultez Type de débogage.
TEST Y2K AVEC BOOT.INI
Si vous consultez fréquemment le site Web Systems Internals, vous êtes probablement déjà au courant du nouveau commutateur BOOT.INI non documenté de Win2K, /YEAR. Je n’ai pas mentionné sur le site web que le commutateur est également pris en charge par NT 4.0 Service Pack 4. Ce commutateur vous permet de faire croire à NT et à tous les logiciels d'un système NT qu'il s'agit d'une autre année. Par exemple, /YEAR=2001 ferait croire au système qu’il s’agissait de 2001 au lieu de 1999. Par conséquent, le commutateur est idéal pour tester les problèmes Y2K à n’importe quel niveau de logiciel, et l’avantage de l’utiliser au lieu de réinitialiser manuellement l’horloge du BIOS (par le biais de l’applet Horloge, par exemple) est que la modification est temporaire et active uniquement lorsque vous démarrez une installation sur laquelle le commutateur est présent dans sa ligne de BOOT.INI. Cela facilite la création d’une installation Y2K spéciale en prenant simplement une ligne de démarrage existante à partir du BOOT.INI, en la dupliquant et en ajoutant le commutateur /YEAR.
NOUVEAUTÉS À VENIR
Attendez-vous à la prochaine lettre d’information dans quelques semaines. L’astuce interne que je vais avoir pour vous la prochaine fois concerne les spinlocks en file d’attente, un nouveau type de spinlock que Windows 2000 utilise pour ses spinlocks globaux. Voici les spinlocks globaux qui existent dans Windows 2000 :
- KiDispatcherLock : verrou de base de données du planificateur
- KiContext-SwapLock : verrou d’échange de la marche
- MmPfnLock : verrou de base de données de trame de page physique
- MmSystemSpaceLock : verrou d’espace d’adressage en mode noyau
- CcMasterSpinLock : le spinlock global du Gestionnaire de cache
- CcVacbSpinLock : verrou du tableau de mappage du Gestionnaire de cache
Au lieu d’utiliser des spinlocks de noyau standard (KeAcquireSpinLock, KeReleaseSpinLock) pour ces verrous globaux comme NT 4.0 l’a fait, le noyau Windows 2000 utilise des spinlocks en file d’attente (KeAcquireQueuedSpinLock, KeReleaseQueuedSpinLock). Ces verrous ont des propriétés intéressantes qui réduisent l’activité du bus sur les SPM. La prochaine fois, je vais vous dire comment les spinlocks en file d’attente sont implémentés.
Tokenmon est bientôt disponible chez Systems Internals, encore un autre outil de supervision. Tokenmon affiche des informations détaillées sur toutes les activités liées aux jetons sur votre système, notamment les connexions, les déconnexions, l’utilisation des privilèges et l’emprunt d’identité.
Merci d’avoir lu le bulletin d’information Systems Internals.
Publié le mercredi 14 avril 1999 à 19:16 par ottoh