Partager via

  • Article

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

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

http://www.sysinternals.com
Copyright (C) 1999 Mark Russinovich

19 juin 1999 : Dans ce numéro :

  1. NOUVEAUTÉS DE SYSTEMS INTERNALS

    • SDelete v1.1
    • Chaînes v2.0
    • LoggedOn
    • Filemon v4.13
    • DebugView/EE v3.1
    • « À l’intérieur de la mise en réseau NT »
    • Juin « NT Internals »
    • État de la mise à jour NTFrob
    • Nouveautés pas si nouvelles

  2. ACTUALITÉS INTERNALS

    • Numega DriverStudio publié
    • Kit de développement logiciel (SDK) de plateforme de juin disponible
    • Win2K System File Protector (SFP)
    • Fermeture des fichiers ouverts à partir du réseau

  3. NOUVEAUTÉS À VENIR

    • Une API Win2K « AWE »some

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.

Winternals Software annonce la sortie des éditions Regmon et Filemon Enterprise. Ces utilitaires fournissent toutes les fonctionnalités des logiciels gratuits Filemon et Regmon, et ajoutent ces fonctionnalités puissantes :

  • afficher l’activité du registre et du système de fichiers sur des systèmes Win9x/NT distants
  • sortie de journal dans un fichier en temps réel
  • copier des lignes de sortie dans le Presse-papiers
  • mettre en surbrillance des lignes qui correspondent à un filtre
  • afficher simultanément la sortie de différents ordinateurs
  • imprimer la sortie directement sur une imprimante
  • rappeler facilement vos 5 dernières sélections de filtres

Obtenir des informations sur les commandes et les prix à l’adresse http://www.winternals.com.

Bonjour,

Bienvenue dans la troisième édition du bulletin d’informations Systems Internals. Le bulletin compte actuellement 4 400 abonnés.

Dans le dernier bulletin d’informations, j’ai souligné comment Microsoft a fait disparaître l’écran bleu de la mort comme nous le connaissons en passant à Windows 2000 (Win2K). Le nouvel écran bleu Win2K n’a pas les informations de vidage de la pile et du pilote chargés qui sont présentes sur l’écran bleu des versions antérieures de Windows NT. J'ai demandé si vous trouviez utiles les informations que Microsoft a dépouillées et si vous auriez préféré qu’ils laissent les choses en l'état. La réponse a été pratiquement unanime, tous les répondants (à l’exception d’un) se demandant pourquoi Microsoft choisit le plus petit dénominateur commun. Voici une opinion typique, envoyée par Tony Lavinio :

En d’autres termes, il s’agit de la réponse du client sur laquelle Microsoft base sa décision :

« Je ne le comprends pas, donc ça doit être mauvais; fais en sorte que ça parte. »

Pourquoi ne pas simplement supprimer tout l’écran et mettre en place un message indiquant « Débrancher, rebrancher, recommencer » ? Pourquoi nous enlèvent-ils l'un des rares indices dont nous disposons pour comprendre pourquoi les choses ont mal tourné ?

Au moins avant, s’il s’agissait d’un scanneur de virus ou d’un défragmenteur ou d’un pilote de bogue, nous avions un point à partir duquel commencer la recherche.

Si cet outil n’aide que 1 sur 10 000 d’entre nous, avec la large base de déploiement NT, cela en vaut la peine. D’autant plus que nous -01 % soutenons une bonne partie des autres 99,99 %.

Qui était le seul dissident ? Il n'est pas très surprenant que ce soit quelqu'un de Microsoft qui remplisse les rapports de panne de l'écran bleu. Voici leur inclinaison sur le changement, ce qui confirme les spéculations de Tony quant à la raison de celui-ci :

Je travaille dans le groupe d’installation de NT dans PSS chez MS (qui gère la résolution des problèmes d’écran bleu). Je peux vous assurer que la majorité des personnes à qui je parle ne savent pas quoi faire avec les informations sur un écran bleu 4.0. Je suis sûr que si vous avez vu un arrêt 0xA avec NAIFILTR.SYS partout dans la pile, vous savez qu’il faut mettre à jour votre antivirus, mais la plupart des gens n’effectuent pas cette connexion, et ils ne se rendent vraiment pas compte que le code d’arrêt et les paramètres sont utiles pour eux. Les personnes qui comprennent comment interpréter les données d’écran bleu seront probablement agacées, mais malheureusement ils sont une minorité.

Comme je l'ai indiqué dans la dernière lettre d'information, je pense que Microsoft devrait reprendre l'écran bleu de NT 4.0, en conservant la liste des pilotes chargés et le vidage de la pile. Je pense aussi qu’ils pourraient améliorer l’écran bleu en fournissant plus d’informations, pas moins. Par exemple, pourquoi ne pas afficher le nom du processus en cours d’exécution au moment de l’incident ? Ou avez-vous d’autres appels BugCheck passer l’adresse du responsable de l’erreur, pas seulement l’adresse qui a été défaillante ? L’une des principales raisons pour lesquelles PSS a rencontré tant de clients qui ne connaissent pas l’écran bleu est que Microsoft n’a jamais écrit de documentation sur la façon de le lire. Au moins une partie du blâme pour l’ignorance des utilisateurs repose donc sur les propres épaules de Microsoft.

Si vous voulez en savoir plus sur la façon dont les écrans bleus se produisent et ce qu’il y a sur le (NT 4.) Écran bleu, consultez mon article de décembre 1997, « Inside the Blue Screen », de Windows NT Magazine (vous pouvez accéder à la version en ligne à partir de http://www.sysinternals.com/publ.htm).

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

SDELETE V1.1

Dans le dernier bulletin d’informations, j’ai présenté SDelete, un utilitaire de suppression sécurisée que vous pouvez utiliser pour détruire irrémédiablement des données de fichier, ainsi que pour nettoyer l’espace libre d’un disque de données précédemment supprimées. La première version de SDelete n’a pas pu remplacer de manière sécurisée les noms des fichiers que vous supprimez avec elle. Le nom d’un fichier révèle souvent des informations sensibles, et l’utilisation de SDelete pour supprimer un fichier avec un nom révélateur peut laisser ces informations exposées. Pour résoudre cette faille, j’ai mis à jour SDelete pour remplacer les données de fichier de manière sécurisée, mais également pour les noms de fichiers. SDelete supprime en toute sécurité un nom de fichier en renommant le fichier 26 fois, en remplaçant chaque lettre du nom du fichier par des lettres successives de l’alphabet, de « A » à « Z ».

Téléchargez SDelete v1.1 avec le code source complet à l’adresse http://www.sysinternals.com/sdelete.htm.

STRINGS V2.0

Les fichiers exécutables et dll contiennent souvent des chaînes incorporées qui peuvent révéler des valeurs de Registre non documentées et des messages d’erreur qui indiquent des fonctionnalités non documentées. Malheureusement, la plupart des DLL système Windows NT/2K et EXEs sont écrites pour utiliser des chaînes de caractères Unicode, tandis que les outils de recherche de chaînes traditionnels comme Grep extraient uniquement des chaînes ASCII. J’ai écrit la première version de mon utilitaire Strings il y a quelques années pour analyser les fichiers binaires à la recherche de chaînes de caractères ASCII ou Unicode. Je l’ai utilisé à de nombreuses reprises dans mes recherches sur NT internals pour aider à comprendre des choses que Microsoft ne documente pas.

Les chaînes ont toujours eu un défaut majeur, mais c’était son incapacité à prendre une expression carte générique en tant que spécificateur de fichier afin que vous puissiez analyser plusieurs fichiers en une seule fois. Je voulais cette fonctionnalité afin que, compte tenu du nom d’une valeur de Registre par exemple, je puisse facilement déterminer les DLL système qui la référencent.

Enfin, j'ai mis à jour Strings pour qu'il prenne en compte tous les noms de fichiers, ainsi que la récursivité des répertoires. Si vous spécifiez une expression de caractère générique, Strings préfixe automatiquement les lignes de sortie avec le nom du fichier dans lequel la chaîne est trouvée, ce qui vous permet de faire quelque chose comme ceci :

strings *.dll | grep SafeBoot

L’affichage de la sortie de cette expression (une version de Grep est disponible dans les utilitaires Posix du Kit de ressources Windows NT) vous indique quelles DLL système vérifient la clé de registre SafeBoot sur Windows 2000. Strings sont également extrêmement utiles pour voir quelles nouvelles valeurs de Registre les DLL système Win2K, les pilotes et les exécutables utilisent. Pour instance, j’ai utilisé Strings pour comparer les valeurs de Registre référencées dans la pile TCP/IP NT 4.0 SP4 (tcpip.sys) à celles référencées par la pile TCPIP Windows 2000. Voici environ la moitié des valeurs qui sont nouvelles dans la pile TCPIP de Win2K (je suppose qu'elles se trouvent toutes sous HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters) :

ReservedPorts
DefaultGatewayMetric
InterfaceMetric
TempLeaseExpirationTime
TempIpAddress
TempMask
DhcpDefaultGateway
TcpWindowSize
TcpInitialRTT
TcpDelAckTicks
EnableTrafficControl
EnableTOSetting
MaxNormLookupMemory
MaxSendSegments
MaxFreeConnections
MaxFreeTWTcbs
FFPFastForwardingCacheSize

Je ne retiendrai pas mon souffle en attendant que Microsoft documente tous les nouveaux paramètres de configuration de la pile.

Vous pouvez télécharger Strings v2.0 à l’adresse http://www.sysinternals.com/misc.htm.

LOGGEDON

Avez-vous déjà voulu savoir qui s’est connecté à un système NT distant ? Si c’est le cas, vous souhaiterez télécharger LoggedOn. LoggedOn est un utilitaire simple qui vous indique quels utilisateurs sont connectés de manière interactive à l’ordinateur local ou distant, ainsi que les utilisateurs connectés via des connexions de ressources (par exemple, un partage de fichier ou d’imprimante). Voici un exemple de sortie LoggedOn :

C:\>loggedon main

LoggedOn v1.0 - Logon Session Displayer
Copyright (C) 1999 Mark Russinovich
Systems Internals - http://www.sysinternals.com

Users logged on locally:
MAIN\Administrator

Users logged on via resource shares:
MAINDOM\MARK

Windows NT et Win2K ne fournissent pas d’API que les applications peuvent utiliser pour déterminer qui est connecté à un ordinateur, mais LoggedOn le détermine en examinant les clés de Registre chargées dans l’arborescence du Registre d’un système HKEY\USERS. Les profils de tout utilisateur connecté de manière interactive sont chargés dans cette clé, et les profils ont des noms qui identifient le SID (ID de sécurité) du compte d’utilisateur associé du profil. Par exemple, si vous ouvrez Regedit et regardez en dessous HKEY_USERS , vous verrez quelque chose comme :

HKEY_USERS\.DEFAULT\S-1-5-21-734676951-386466661-1233803906-500

Ici, un seul utilisateur est connecté de manière interactive. Vous pouvez indiquer à l’administrateur local ou à l’administrateur de domaine, car le RID (ID relatif) est 500, qui est la réserve RID NT pour les comptes d’administrateur.

En utilisant des API qui permettent à un système d’examiner le Registre d’un autre système, LoggedOn lit la clé HKEY_USERS d’un ordinateur distant et convertit les SID qu’il trouve en noms de compte. Pour déterminer qui est connecté via le partage de ressources, LoggedOn utilise l’API NET, qui est documentée dans le Kit de développement logiciel (SDK). L’outil en ligne de commande Net utilise largement l’API NET. Un effet secondaire de LoggedOn accédant au Registre d’un système distant est que le compte dans lequel vous exécutez LoggedOn apparaît toujours comme étant connecté à un système distant via un partage de ressources dans la sortie de LoggedOn.

Vous pouvez télécharger LoggedOn avec le code source complet à l’adresse http://www.sysinternals.com/misc.htm.

FILEMON V4.13

Filemon v4.13 vient d’être publié, une mise à jour qui reflète les modifications apportées au pilote de filer Windows NT et corrige un bogue que j’ai introduit par inadvertance dans le pilote 4.12. Le pilote de filtre 4.13 présente les modifications suivantes :

  • il utilise le type de synchronisation de ressources pour protéger certaines de ses structures de données internes
  • il gère le nouveau Win2K IRP, IRP_MJ_PNP_POWER

Le type de synchronisation de ressources n’est pratiquement pas documenté dans les kits de développement de pilotes de périphérique (DDK) Windows NT 4.0 et Win2K. Le Guide de conception ne mentionne même pas les ressources, tandis que leurs fonctions sont documentées dans la référence sous la section « Routines de support exécutif ». Les ressources sont un mécanisme utile pour protéger des structures de données qui peuvent être lues simultanément par différents threads, mais qui nécessitent un accès exclusif par un thread pendant une mise à jour. Par conséquent, il s’agit de verrous de lecture/d’écriture qui sont acquis pour un accès partagé par les lecteurs et un accès exclusif par les rédacteurs. Les pilotes de système de fichiers utilisent largement les ressources. Il m’a donc semblé approprié de mettre à jour Filemon pour les utiliser le cas échéant.

Filemon v4.13 gère également la nouvelle IRP_MJ_PNP_POWER de sorte qu'il s'agit d'un pilote de filtre compatible avec l'alimentation et le plug-and-play lorsqu'il fonctionne sous Win2K. La seule exigence d’un pilote de filtre de système de fichiers dans la gestion des IRP de ce type consiste à les transmettre aux périphériques de système de fichiers auxquels le filtre est attaché.

Vous pouvez télécharger Filemon v4.13 avec le code source complet à l’adresse http://www.sysinternals.com/filemon.htm.

DEBUGVIEW/EE V3.1

DebugView/EE est un moniteur de sortie de débogage polyvalent que vous pouvez utiliser pour capturer la sortie de débogage locale ou distante générée par les programmes Win32 ou les pilotes de périphérique en mode noyau sous Win95, Win98, WinNT et Win2K. Son utilité est toutefois limitée dans les environnements où un utilisateur rencontre un incident à l’aide d’un pilote de périphérique. Toutefois, toutes les données de débogage capturées par DebugView avant un crash sont perdues. La dernière version de DebugView/EE résout ce problème sur Windows NT/2K. Si un utilisateur capture la sortie en mode noyau générée par un pilote de périphérique et que l’utilisateur a configuré NT pour enregistrer un vidage sur incident, DebugView/EE peut extraire la sortie de débogage du fichier de vidage lorsque le système redémarre. Utilisez la modification de DebugView/EE |Sélection du menu Traiter le vidage sur incident pour qu’il analyse un vidage de la mémoire à la recherche de la sortie de débogage. Cette fonctionnalité permet aux utilisateurs de vous renvoyer un fichier texte contenant la sortie de débogage que votre pilote a générée jusqu’au moment de l’incident.

Téléchargez DebugView/EE v3.1 à l’adresse http://www.sysinternals.com/debugview.htm.

« À L’INTÉRIEUR DE LA MISE EN RÉSEAU NT »

Ma colonne « NT Internals » du magazine Windows NT de mars 1999 est désormais en ligne. Découvrez l’architecture réseau de NT de haut en bas, notamment les API qu’il implémente, comment les piles de protocole s’interfacent avec les API et comment les fournisseurs de matériel écrivent des pilotes réseau pour qu’ils fonctionnent avec des pilotes de protocole. Découvrez également certaines nouvelles fonctionnalités de la mise en réseau de Win2K, notamment la prise en charge désérialisée de NDIS et atm.

Lisez « Inside NT Networking » et d’autres colonnes NT Internals passées en ligne à l’adresse http://www.sysinternals.com/publ.htm.

JUIN « NT INTERNALS »

La version de juin de ma colonne Windows NT Magazine est « Inside EFS, Part 1 ». Cet article décrit l’architecture du système de fichiers EFS (Encrypting File System) de Microsoft et vous guide dans une procédure détaillée à suivre par EFS lors du chiffrement d’un fichier. EFS fournit une fonctionnalité de chiffrement transparente pour les lecteurs NTFS Win2K et Microsoft l’a développée spécifiquement pour répondre à la capacité de notre outil NTFSDOS à lire les fichiers NTFS sans tenir compte de leur sécurité. Cette colonne sera disponible en ligne dans trois mois.

Il y a deux bulletins d’information, j’ai parlé de la façon dont les API EFS nécessaires pour sauvegarder et restaurer des fichiers chiffrés ne sont pas documentées. Malheureusement, ces API ne sont toujours pas documentées dans l’édition actuelle de MSDN. Toutefois, j’ai été informé que Microsoft envoie la documentation, marquée comme « Confidentiel Microsoft », à ses partenaires et aux fournisseurs de logiciels de sauvegarde. David Golds, responsable du programme systèmes de fichiers chez Microsoft, a également présenté une présentation sur les améliorations apportées au système de fichiers Win2K lors de la récente conférence Microsoft TechEd à Dallas. Dans sa présentation, dont vous pouvez consulter les diapositives en ligne à l'adresse http://www.teched99.com/slides/1-337.ppt, il mentionne que les API de sauvegarde ne sont pas documentées, mais que vous pouvez l'interroger si vous souhaitez obtenir la documentation. Malheureusement, son adresse e-mail n’est pas indiquée sur les diapositives.

Visitez http://www.winntmag.com pour obtenir des informations sur l’abonnement Windows NT Magazine.

ÉTAT DE LA MISE À JOUR NTFROB

NTFrob est un utilitaire que j’ai publié il y a quelques années qui vous permet de configurer précisément les longueurs quantiques des processus de premier plan et d’arrière-plan sur NT 4.0. NTFrob modifie les structures de données internes au noyau NT, de sorte qu’il est très spécifique au Service Pack. Depuis la publication de NT 4.0 Service Pack 5, des requêtes me demandent quand je vais publier NTFrob v1.5, la mise à jour SP 5. La réponse est que la mise à jour est à venir. J’attends que Microsoft fournisse aux abonnés MSDN SP5, y compris des informations de débogage. J’ai besoin d’informations de débogage pour mettre à jour NTFrob pour les nouveaux Service Packs.

Vous pouvez télécharger NTFrob pour NT 4 SP0-4 à l’adresse http://www.sysinternals.com/ntfrob.htm.

NOUVEAUTÉS PAS SI NOUVELLES

Il y a quelques mois, j’ai publié un moniteur de port en série et parallèle Win9x/NT/2K chez Systems Internals. Portmon vous permet de voir exactement comment les applications interagissent avec les ports série et parallèle, y compris les données qu’elles envoient et reçoivent. Vous pouvez l’utiliser pour observer des sessions d’accès à distance, des connexions série laplink ou une activité d’imprimante. Portmon a été un énorme succès, et il a récemment obtenu 5 étoiles de la bibliothèque de logiciels Ziff-Davis, la plus haute cote possible. Parmi les autres outils Systems Internals qui ont obtenu 5 étoiles, citons Regmon, NTFSDOS et BlueSave.

Téléchargez Portmon à l’adresse http://www.sysinternals.com/portmon.htm.

ACTUALITÉS INTERNALS

PUBLICATION DE DRIVERSTUDIO

NuMega Labs de CompuWare a publié DriverStudio, un kit de ressources complet pour les développeurs de pilotes d’appareil Windows 9x/NT/2K. Il inclut SoftICE 4.0, BoundsChecker pour les pilotes, VtoolsD, DriverAgent, DriverWorks, FieldAgent pour les pilotes et, à l’avenir, ajoutera TrueTime pour les pilotes et TrueCoverage pour les pilotes. Comme je l’ai dit dans le dernier bulletin d’informations, il s’agit d’un kit de ressources de développement indispensable. NuMega a également lancé un site web orienté développeur de pilotes de périphérique appelé « Driver Central » - http://www.numega.com/drivercentral/default.asp.

PUBLICATION DU KIT DE DÉVELOPPEMENT LOGICIEL (SDK) DE LA PLATEFORME JUIN

Vous pouvez télécharger la version de juin du Kit de développement logiciel (SDK) de plateforme Microsoft dès maintenant à l’adresse http://www.msdn.microsoft.com/developer/sdk/platform.asp.

WIN2K SYSTEM FILE PROTECTOR (SFP)

L’une des plus grandes prises en main des administrateurs et des utilisateurs de systèmes NT est « DLL Hell » de NT. DLL hell est le résultat de nombreuses applications mettant à jour des DLL système clés avec les versions qu’elles regroupent. Les applications le font généralement de sorte qu’elles puissent garantir qu’elles fonctionnent correctement. Toutefois, lorsqu’elles remplacent une DLL, elles arrêtent souvent d’autres applications en installant des versions incompatibles, ou même en « mettant à jour » une DLL vers une version antérieure.

Microsoft a résolu les problèmes de contrôle de version des DLL dans Win2K avec l’introduction du protecteur de fichiers système (SFP). En fait, son nom va bientôt passer à Windows File Protector (WFP), mais à partir de la bêta 3 (build 2031), il est toujours SFP. SFP est implémenté dans une DLL nommée sfc.dll que le processus Winlogon (winlogon.exe) charge au démarrage du système. SFP inclut une liste intégrée d’environ 3 000 dll système Win2K standard, exécutables (.exe), fichiers d’installation (.inf), pilotes (.sys) et fichiers de police (.fon) installés dans 30 à 40 répertoires différents. Lorsque SFP initialise, il exécute une opération de notification de modification du répertoire sur chaque répertoire contenant les fichiers qu’il protège. Lorsqu’il détecte la falsification d’un fichier, une boîte de dialogue s’affiche pour informer l’utilisateur actuel, écrit un objet pair dans le journal des événements et remplace le fichier modifié par une sauvegarde stockée dans %systemroot%\system32\dllcache. Si le fichier de sauvegarde que SFP recherche dans dllcache est manquant ou a également été falsifié, SFP récupère une nouvelle copie à partir du support d’installation Win2K.

Pour voir quels fichiers SFP protège, vous pouvez utiliser l’utilitaire Strings mentionné ailleurs dans ce bulletin d’informations pour vider les noms de chaîne Unicode incorporés dans %systemroot%\system32\sfc.dll.

Les seuls utilitaires qui peuvent mettre à jour les fichiers système sont les hotfix.exe, les Service Packs (update.exe), les installations de mise à niveau et le service Win2K Update. Comment ces outils contournent-ils le SFP ? Ils la désactivent temporairement en appelant la fonction de sfc.dll exportée SfcTerminateWatcherThread, et veillent à refléter les mises à jour dans le sous-répertoire dllcache. Notez que Win2K nécessite que tous les fichiers système soient signés numériquement par Microsoft. Il n’est donc généralement pas possible de mettre à jour un fichier système avec une version arbitraire du vôtre.

Les programmes Win32 peuvent surveiller les modifications apportées à un répertoire en utilisant les API Win32 FindFirstChangeNotification et FindNextChangeNotification. Toutefois, ces API informent simplement une application que quelque chose a changé ; ils n’indiquent pas exactement à l’application ce qui a changé. Une application est donc nécessaire pour analyser un répertoire entier afin de déterminer quels fichiers ou sous-répertoires ont été modifiés. SFP utilise l’API native NT pour effectuer une demande de notification de modification où NT lui indique exactement quels fichiers ou sous-répertoires changent dans les répertoires surveillés. La fonction que SFP utilise est nommée NtNotifyChangeDirectoryFile et, comme 90 % de l’API native de NT, elle n’est pas documentée. Recherchez une applet dans System Internals dans un avenir proche qui vous montre comment utiliser NtNotifyChangeDirectoryFile.

Ma colonne « NT Internals » de septembre, « Inside Win2K Reliability Enhancements, Part 2 » décrit SFP plus en détail.

FERMETURE DES FICHIERS OUVERTS À PARTIR DU RÉSEAU

L’une des questions les plus fréquentes que je reçois des visiteurs de Systems Internals est « comment puis-je fermer les fichiers que les utilisateurs ont ouverts à partir du réseau ? » Si un utilisateur a un fichier ou un répertoire ouvert à distance, il n’est pas possible de supprimer, de renommer ou de mettre à jour le fichier ou le répertoire localement. Une question similaire est la suivante : « Comment voir quels fichiers les utilisateurs ont ouverts à partir du réseau ? » L’utilitaire de ligne de commande Net fourni avec Windows NT/2K répond à ces deux questions. Pour voir quels fichiers sont ouverts, entrez simplement « fichier net ». Vous obtiendrez une liste des noms de fichiers ouverts, des identificateurs de nom de fichier correspondants et les noms des utilisateurs qui ont des fichiers ouverts. Pour fermer l’un des fichiers ouverts, entrez net file <id> /close. Pour afficher les fichiers ouverts localement, vous pouvez utiliser mes outils NTHandle ou HandleEx.

Les API qui sous-tendent la fonctionnalité d’affichage et de fermeture des fichiers de la commande Net sont documentées dans le Kit de développement logiciel (SDK) de plateforme et dans MSDN Library. Utilisez l’API NetFileEnum pour énumérer les fichiers ouverts et l’API NetFileClose pour fermer un fichier ouvert. Les API vous permettent en fait d’énumérer les fichiers ouverts sur les serveurs distants, ce que la commande Net n’autorise pas.

NTHandle est disponible à l’adresse http://www.sysinternals.com/nthandle.htm. HandleEx est disponible à l’adresse http://www.sysinternals.com/handleex.htm.

NOUVEAUTÉS À VENIR

UNE API WIN2K « AWE »SOME

Win2K introduit une nouvelle API appelée AWE (Address Window Extensions) que les applications gourmandes en mémoire peuvent utiliser pour accéder et gérer directement de grandes quantités de RAM physique , voire plus de 3 Go, la limite supérieure de la RAM qu’une application Windows NT peut traiter dans son espace d’adressage virtuel. En fait, si un système x86 a PSE (Pages Size Extensions) et plus de 4 Go de RAM, une application peut utiliser AWE pour tirer parti de toute la mémoire de l’ordinateur. Cette API est donc idéale pour les applications gourmandes en mémoire comme les serveurs web et les serveurs de base de données. La prochaine fois, je vous expliquerai comment utiliser les API, à partir d’applications Win32 et de pilotes de périphérique.

Pendant que je parle des applications gourmandes en mémoire, voici un conseil pour quiconque écrit une application qui met en cache des fichiers (comme un serveur web). Le Gestionnaire de cache Windows NT divise sa mémoire cache en emplacements de 256 Ko appelés « vues ». Si un fichier d’une taille inférieure à 256 Ko est mis en cache, le Gestionnaire de cache doit toujours affecter au fichier un emplacement entier de 256 Ko, ce qui signifie qu’une partie de la mémoire virtuelle du cache est gaspille. Ainsi, il est généralement plus efficace de mettre en cache des fichiers d’une taille inférieure à 256 Ko dans la mémoire virtuelle de votre propre application et de s’appuyer sur le système de fichiers pour mettre en cache des fichiers d’une taille supérieure à 256 Ko. IIS 5.0 utilise cette astuce.

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

Publié le samedi 19 juin 1999 à 19:14 par ottoh

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