[Archives des newsletters ^] [< Volume 2, Numéro 4] [Volume 3, Numéro 1 >]
Bulletin d’information The Systems Internals Volume 2, numéro 5
www.sysinternals.com
Copyright (c) 2000 Mark Russinovich
30 novembre 2000 – Dans ce numéro :
ÉDITORIAL
NOUVEAUTÉS DE SYSINTERNALS
- PsLoggedOn v1.2
- PsShutdown v1.0
- PsTools v1.1
- BgInfo v1.1
- Tokenmon v1.0
- Filemon v4.32
- Regmon v4.32
- Dans Windows 2000, 3e édition.
- Magazine Windows 2000 de novembre et d’hiver
- Sysinternals chez Microsoft
- Licences Sysinternals
INFORMATIONS INTERNES
- NFI
- Clés de Registre Win9x masquées
NOUVEAUTÉS À VENIR
- Nouveaux appels système Whistler
SPONSOR : WINTERNALS SOFTWARE
Le bulletin Sysinternals est sponsorisé par Winternals Software, sur le Web à 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, NTFSDOS Professional Edition (un pilote NTFS en lecture/écriture pour DOS) et la récupération à distance.
La commande netstat, qui est fournie avec toutes les versions de Windows 9x et Windows NT/2000, vous indique quels ports TCP/IP sont ouverts sur votre système, mais elle ne vous indique pas quel processus a le port ouvert. TCPView Pro, le dernier outil de surveillance de Winternals, est fourni non seulement avec un outil en ligne de commande équivalent à netstat, Tcpvstat, qui vous indique quel processus a chaque port ouvert, mais inclut une interface graphique qui affiche les mêmes informations ainsi qu’une trace en temps réel de l’activité TCP/IP. La trace en temps réel révèle l’application qui effectue un accès réseau, les adresses IP locales et distantes de l’accès avec la résolution de noms DNS facultative, le type d’accès, la réussite de l’accès et la quantité de données transférées. TCPView Pro est seulement de 69 $. Téléchargez la version d’évaluation entièrement fonctionnelle de 14 jours de TCPView Pro dès aujourd’hui à www.winternals.com/products/monitoringtools/tcpviewpro.shtml.
Bonjour,
Bienvenue dans le bulletin Sysinternals. Le bulletin compte actuellement 28 000 abonnés.
L’un des avantages du passage de Windows NT à Windows 2000 est la fiabilité considérablement améliorée. J’ai écrit sur les raisons des améliorations dans plusieurs articles, et elles sont principalement le résultat d’un outil appelé Driver Verifier. Vous pouvez configurer le vérificateur, que vous lancez en tapant « vérificateur » dans la boîte de dialogue Exécuter du menu Démarrer, pour regarder étroitement l’exécution de pilotes de périphériques spécifiques, en recherchant une violation de l’une des règles de programmation de pilotes. Cependant, le vérificateur va plus loin que la surveillance passive , il aggrave également le potentiel; conditions d’erreur, par exemple, en allouant des blocs de mémoire pour le pilote qui sont à cheval avec des régions non valides, et en mettant à zéro des champs spécifiques dans les structures de données qui sont passées au pilote. Si vous souhaitez vraiment être difficile, vous pouvez demander au vérificateur de simuler des conditions de mémoire faibles pour le pilote.
Microsoft tire parti du vérificateur via son programme de signature de pilote, qui exige que tout pilote signé numériquement par Microsoft réussisse les tests stricts du vérificateur de pilotes. Lorsqu’un pilote est installé, l’Assistant matériel vérifie si le pilote est signé. Si ce n’est pas le cas, il vous avertit ou ne parvient pas à installer le pilote, en fonction des paramètres que vous avez entrés dans la boîte de dialogue Options de signature du pilote, qui est accessible à partir de la page Matériel de l’applet système dans le Panneau de configuration.
Le fait que la stratégie de signature de pilote par défaut avertit les utilisateurs finaux des pilotes non signés est suffisant pour que la plupart des fournisseurs de matériel se mettent à la peine de rendre leurs pilotes robustes et de les faire signer. Toutefois, les pilotes de périphérique peuvent se faufiler sur votre système sans être détectés par la stratégie de signature de pilote. Seuls les pilotes installés à l’aide de fichiers INF (fichiers d’installation de pilotes qui se terminent par l’extension .inf) sont vérifiés pour rechercher les signatures. Les applications d’installation peuvent installer manuellement les pilotes à l’aide des API d’installation directement ou en configurant manuellement les paramètres du Registre du pilote. Les applications Sysinternals en sont d’excellents exemples : Filemon, Regmon et d’autres outils Sysinternals qui ont des composants de pilote qui installent leurs pilotes manuellement, ce qui explique pourquoi vous n’êtes pas averti qu’ils ne sont pas signés par Microsoft.
Les pilotes qui ne sont pas couramment installés avec les fichiers INF incluent des antivirus, des logiciels de chiffrement et des logiciels de gravure de CD-ROM. Toutefois, cela n’empêche pas les pilotes liés au matériel de passer à travers. Le pilote Sysinternals Ctrl2cap pour Windows 2000 (www.sysinternals.com/ctrl2cap.htm est un exemple de pilote matériel qui s’installe de manière à contourner les vérifications de signature des pilotes. Cette faille entraîne la présence de pilotes sur votre système qui n’ont pas été vérifiés, ce qui peut compromettre la stabilité du système (je vérifie tous les pilotes Sysinternals sur les paramètres les plus élevés). Microsoft doit forcer tous les pilotes, pas seulement ceux qui s’installent avec des fichiers INF, à passer par la signature case activée.
Pourquoi suis-je sur ce coup de gueule ? Mon logiciel de gravure de CD-ROM, qui est le plus populaire de ce type de logiciel sur le marché, a un pilote qui bloquera de façon reproductible mon système Windows 2000 SP1. Si je configure le vérificateur de pilotes pour l’case activée, le système ne termine même pas le démarrage avant que le vérificateur détecte la première violation du pilote et plante le système. Le pilote installé sans fichier INF n’a donc pas été averti qu’il n’était pas signé. Je vous garantis que si la politique de Microsoft était plus stricte, ce fournisseur réfléchirait à deux fois avant d’expédier un pilote non signé (et buggy).
Veuillez transmettre le bulletin d’informations à des amis que vous pensez être intéressés par son contenu.
Merci !
Mark
NOUVEAUTÉS DE SYSINTERNALS
PSLOGGEDON V1.2
Outre un changement de nom évident de LoggedOn à PsLoggedOn, cet outil en ligne de commande, qui a la possibilité de vous montrer qui est connecté localement et via des partages de ressources sur le système local ou distant, dispose de nouvelles fonctionnalités. Le premier est le commutateur de ligne de commande '-l’qui a résulté des commentaires des utilisateurs. De nombreuses personnes utilisent PsLoggedOn pour voir si un compte est connecté localement à leurs serveurs. Il peut y avoir des utilisateurs connectés via des partages de fichiers, par exemple, mais cela n’est pas pertinent lors de la prise de décision sur le moment où un compte peut être mis à jour ou le serveur peut être administré à distance.
La deuxième nouvelle fonctionnalité de PsLoggedOn vous indique non seulement qui est connecté, mais également l’heure à laquelle l’ouverture de session a eu lieu. PsLoggedOn obtient gratuitement les heures d’ouverture de session des partages de ressources lorsqu’il utilise une API Win32, NetSessionEnum, pour énumérer les connexions de partage de ressources (la commande Net de ligne de commande utilise également NetSessionEnum pour énumérer les sessions). Toutefois, il n’existe pas d’API Win32 qui vous indique qui est connecté à un système localement, encore moins à quel moment ils se sont connectés.
Pour déterminer qui s’est connecté à un système localement, PsLoggedOn énumère les ID de sécurité (SID) situés sous la clé de Registre d’un HKEY_USERS
ordinateur. Lorsqu’une personne se connecte à un ordinateur localement, sur la console ou via un service, son profil est chargé dans la clé HKEY_USERS
. Les applications peuvent accéder aux paramètres de Registre de leur profil par le biais de la HKEY_CURRENT_USER
clé, car le système traite cette clé comme un lien symbolique vers leur profil particulier sous HKEY_USERS
. Par conséquent, PsLoggedOn peut savoir qui est connecté localement en convertissant les SID qu’il trouve dans la clé d’un HKEY_USERS
ordinateur en nom d’utilisateur correspondant. PsLoggedOn utilise RegConnectKey
pour se connecter au Registre d’un ordinateur distant lorsque vous le dirigez vers la liste des utilisateurs connectés à un système distant.
Déterminer l’heure à laquelle un utilisateur s’est connecté fonctionne à l’aide d’une astuce similaire. Lorsque le processus WinLogon charge le profil d’un utilisateur dans HKEY_USERS
une fois qu’il s’est connecté, WinLogon crée une sous-clé volatile (non enregistrée dans le profil sur le disque) dans son profil nommée, de manière appropriée, Environnement volatile. Le Registre stocke les horodatages des dernières modifications pour les clés de Registre et, comme le système ne modifie pas les sous-clés Environnement volatile après leur création, PsLoggedOn peut déterminer quand un utilisateur s’est connecté en obtenant l’horodatage de sa sous-clé Environnement volatile.
Téléchargez PsLoggedOn v1.2 avec source complète à l’adresse
www.sysinternals.com/psloggedon.htm.
PSSHUTDOWN V1.0
Si vous avez déjà eu besoin d’arrêter ou de redémarrer un système Windows NT/2000 local ou distant, vous souhaiterez télécharger PsShutdown. PsShutdown est un clone de l’outil Arrêter windows NT/2000 Resource Kit. Il utilise les mêmes arguments de ligne de commande qui vous permettent de spécifier un délai avant l’arrêt, s’il faut redémarrer ou non, un message facultatif à afficher à tout utilisateur actuellement connecté au système et le nom de l’ordinateur à arrêter ou redémarrer.
Download PsShutdown v1.0 at www.sysinternals.com/psshutdn.htm.
PSTOOLS V1.1
Vous avez probablement remarqué l’augmentation du nombre d’outils chez Sysinternals qui commencent par le préfixe « Ps ». Le premier était PsList, un outil en ligne de commande qui répertorie des informations sur les processus actifs sur le système Windows NT/2000 local ou distant. J’ai donné son nom à PsList, car l’outil d’informations sur le processus de ligne de commande UNIX standard est nommé « ps ». L’outil suivant pour obtenir le préfixe était PsKill, un utilitaire de ligne de commande qui vous permet d’arrêter les processus en cours d’exécution sur des systèmes Windows NT/2000 locaux ou distants. J’ai donné à PsKill le préfixe « Ps » parce qu’il a fait un compagnon parfait à PsList.
Au fil du temps, j’ai développé d’autres outils qui partagent les mêmes caractéristiques de définition que PsList et PsKill : ils sont basés sur la ligne de commande et fonctionnent sur le système Windows NT/2000 local ou distant. Par exemple, ElogList vous permet de vider le contenu des journaux des événements d’un système, et GetSid vous a montré le SID d’un ordinateur ou d’un compte particulier. Récemment, j’ai décidé de lier tous ces outils ensemble en leur donnant tous le préfixe « Ps » et en les rendant téléchargeables sous la forme d’un package unique nommé PsTools.
PsTools, qui inclut PsList, PsKill, ainsi que les psLogList et PsGetSid renommés, se compose d’un total de sept outils. Si vous voyez un outil Sysinternals avec le préfixe « Ps », vous savez automatiquement qu’il s’agit d’un outil en ligne de commande qui fonctionne localement et à distance.
Téléchargez PsTools v1.1 sur www.sysinternals.com/pstools.htm.
BGINFO V1.1
Suite aux commentaires des utilisateurs, Bryce a mis à jour BgInfo, un utilitaire qui définit le papier peint du bureau pour afficher des informations personnalisables sur la configuration d’un système, à la suite des commentaires des utilisateurs qu’il a reçus. Par défaut, BgInfo compte pendant 10 secondes avant d’appliquer les paramètres spécifiés dans sa boîte de dialogue, mais une nouvelle option de ligne de commande, /timer
, vous permet de modifier ou d’éliminer complètement le compte à rebours. Il est ainsi plus pratique d’inclure BgInfo dans un script d’ouverture de session ou en tant que raccourci dans le dossier De démarrage d’un profil.
La version 1.1 inclut d’autres nouvelles fonctionnalités, telles que la possibilité d’afficher du texte arbitraire que vous définissez et d’autres catégories d’informations prédéfinies. La bitmap de bureau créée par BgInfo v1.1 est également généralement plus petite, ce qui réduit l’encombrement de la mémoire du bureau de BgInfo.
Téléchargez BgInfo v1.1 sur www.sysinternals.com/bginfo.htm.
TOKENMON V1.0
Tokenmon est le dernier ajout à la suite variée d’outils de supervision que vous pouvez télécharger à partir de Sysinternals. Tokenmon, qui partage la même interface utilisateur que celle de ses cousins comme Regmon et Filemon, surveille les activités importantes liées à la sécurité sur un système Windows NT/2000. Qu’est-ce qu’une activité « significative » liée à la sécurité ? Au cœur de la sécurité Windows NT/2000 se trouve l’objet de jeton, une structure de données qui contient un SID de compte, des SID de groupe et des privilèges. Chaque fois qu’un processus tente d’accéder à un objet sécurisé, le Moniteur de référence de sécurité utilise les SID dans son jeton dans le cadre de la validation d’accès. Si un processus tente d’effectuer une opération restreinte, telle que redémarrer le système, le système vérifie le privilège approprié dans le jeton du processus.
L’une des fonctionnalités puissantes (et brevetées) du modèle de sécurité Windows NT/2000 est l’emprunt d’identité. L’emprunt d’identité permet à un thread de remplacer temporairement son identité basée sur les processus et d’adopter une autre identité à l’aide d’un jeton d’emprunt d’identité. Les applications serveur tirent parti de l’emprunt d’identité lors de l’accès aux ressources pour le compte d’un client, lorsqu’elles adoptent l’identité du client pendant la durée de l’accès.
Tokenmon installe les hooks d’appel système de la même façon que Regmon le fait pour les API de Registre, afin de surveiller la création et la suppression de jetons, l’activation et la désactivation des privilèges et l’emprunt d’identité. Tokenmon utilise également des hooks de création de processus fournis par le noyau NT/2000 pour surveiller la création et la suppression des processus, ainsi que d’autres API pour déterminer quand un utilisateur se connecte et quand il se déconnecte.
Le code source complet sur Tokenmon est publié, et il est utile de discuter de certaines des techniques intéressantes présentées par le code. Tokenmon détecte un événement d’ouverture de session en raccordant l’appel système NtCreateToken, qui est celui utilisé par les répartiteurs d’ouverture de session tels que WinLogon pour créer un jeton initial pour le premier processus d’une nouvelle session d’ouverture de session. Les processus créés par le premier processus héritent d’une copie du premier jeton. Pour détecter la fermeture de session, Tokenmon s’inscrit pour la notification de fermeture de session via la fonction SeRegisterLogonSessionTerminatedRoutine en mode noyau, une API qui existe au profit des pilotes de système de fichiers, appelés redirecteurs réseau, qui mettez en cache les données de session d’ouverture de session et souhaitent nettoyer lorsqu’un utilisateur se déconnecte. Les redirecteurs réseau implémentent le côté client des connexions client/serveur de partage de fichiers.
Un autre détail intéressant de l’implémentation de Tokenmon est la façon dont Tokenmon raccorde les API qu’il surveille. Certaines des API que les hooks Tokenmon ne sont pas exportées pour être utilisées par les pilotes de périphérique, mais sont exportées dans la bibliothèque de NTDLL.DLL en mode utilisateur pour une utilisation par les applications qui utilisent leurs équivalents Win32. Toutes les API de Registre que les crochets Regmon sont exportées en mode noyau, ce qui permet au pilote de périphérique Regmon d’obtenir leurs numéros d’appel système et de raccorder la table d’appels système de manière appropriée. Pour les API non exportées pour une utilisation par les pilotes, l’interface graphique Tokenmon doit obtenir les numéros d’appel à l’aide des exportations dans NTDLL.DLL, puis passer les numéros au pilote afin que le pilote puisse raccorder la table d’appels système. Ainsi, Tokenmon montre comment raccorder des appels système qui ne sont pas exportés en mode noyau.
Téléchargez Tokenmon v1.0 avec la source complète à www.sysinternals.com/tokenmon.htm.
FILEMON V4.32
Cette dernière mise à jour de Filemon introduit un filtrage plus intuitif et complet, l’affichage des noms de chemins UNC complets pour l’accès aux fichiers réseau Windows 9x/Me et l’affichage des noms de fichiers de métadonnées NTFS.
Les versions précédentes de Filemon vous obligeait à entrer des filtres avec des caractères génériques obligatoires. Par exemple, si vous souhaitez surveiller les accès au répertoire Temp sur le lecteur C:
, vous devez entrer un filtre comme celui-ci : « c:\temp\*
».
Avec la nouvelle syntaxe de filtrage, les caractères génériques sont facultatifs. Par conséquent, bien que l’exemple de filtre fonctionne, « c:\temp
» obtiendrait le même effet. En outre, Filemon applique désormais les filtres que vous entrez sur tous les champs de l’affichage, y compris le nom du processus, le type de requête, le chemin d’accès et la colonne « autre ». Cette flexibilité vous permet de rechercher des types spécifiques de demandes, ou avec certaines données dans l’autre colonne, ce qui n’était pas possible auparavant.
Les utilisateurs de Filemon sur les systèmes Windows 9x/Me voient désormais les noms des chemins d’accès d’affichage Filemon avec la syntaxe UNC complète lorsqu’ils accèdent aux ressources distantes. Auparavant, Filemon n’affichait pas le nom du serveur ou du partage pour ces accès, ce qui a entraîné des noms de chemin d’accès incomplets.
Enfin, si vous avez utilisé Filemon sur Windows NT/2000, vous avez sans doute vu le texte « DASD » dans la colonne de chemin d’accès pour de nombreux accès (« DASD » provient de « Périphérique de stockage Direct Access », terme que Microsoft utilise pour décrire les accès à un volume qui contournent les structures du système de fichiers). Pour la plupart des activités sur les volumes NTFS, DASD est désormais une chose du passé. Au lieu de cela, vous verrez les noms des fichiers de métadonnées NTFS en cours de lecture et d’écriture. Par exemple, une mise à jour d’un enregistrement MFT aurait entraîné une ligne de sortie DASD auparavant, mais vous la voyez maintenant comme un accès à « $Mft », le nom de fichier de métadonnées interne de MFT.
Pourquoi Filemon n’a-t-il pas affiché les noms de fichiers de métadonnées auparavant et comment obtient-il ces noms maintenant ? Les objets fichier qui représentent les fichiers de métadonnées NTFS ne stockent pas de nom de fichier. Filemon ne peut donc pas extraire le nom de l’objet fichier. L’autre méthode de Filemon pour obtenir le nom d’un fichier, l’interrogation du pilote du système de fichiers, ne fonctionne pas non plus pour les fichiers de métadonnées NTFS. Bien que NTFS réponde avec les noms des fichiers de métadonnées, NTFS sur NT 4 provoque des incidents aléatoires, et NTFS sur Win2k se bloque parfois lors de la réponse à de telles requêtes.
Filemon doit donc recourir à une astuce pour obtenir les noms de fichiers de métadonnées. Lorsqu’il voit une requête dirigée vers un objet fichier sur un volume NTFS sans nom, il envoie à NTFS une requête pour l’index du fichier. Il s’agit du même index que la fonction Win32 GetFileInformationByHandle retourne, et pour les fichiers sur les volumes NTFS, l’index est l’index MFT du fichier. Les 16 premières entrées du fichier MFT sont réservées à des fichiers de métadonnées spécifiques. Par conséquent, étant donné un index dans cette plage, Filemon recherche simplement le nom du fichier de métadonnées dans sa propre table.
Malheureusement, vous verrez toujours DASD pour les accès aux métadonnées de répertoire et aux tables d’allocation de fichiers (FAT) sur les volumes FAT, car FAT ne stocke pas de noms pour les fichiers de métadonnées de répertoire ou le FAT. Vous serez surpris de la fréquence d’accès au fichier journal NTFS ($LogFile). Incidemment, NTFS sur Whistler stocke les noms des fichiers de métadonnées. L’astuce n’est donc pas nécessaire sur Whistler.
L’amélioration finale de Filemon permet à Filemon d’afficher les horodatages d’heure de la journée avec une résolution en millisecondes. Cette prise en charge nécessitait des hacks laids dans le pilote Filemon Windows 9x/Me en raison de bogues dans une fonction de minutage dans le noyau Windows 9x/Me. Pour plus d’informations, consultez le code source.
Téléchargez Filemon v4.32 avec le code source à www.sysinternals.com/filemon.htm.
REGMON V4.32
Les modifications de Regmon ne sont pas aussi importantes que celles de Filemon, mais Regmon prend désormais en charge la même syntaxe de filtrage intuitive que Filemon et, comme Filemon, applique les filtres à tous les champs. Il peut également afficher la résolution en millisecondes sur les horodatages.
Ceux d’entre vous qui ont commencé à jouer avec Whistler (le successeur de Windows 2000) Bêta 1 ont peut-être remarqué que les versions précédentes de Regmon plante Whistler au démarrage. Cela est dû au fait que Microsoft a placé la table d’appels système, que Regmon modifie pour insérer ses crochets, dans la mémoire protégée en écriture. Regmon v4.32 fonctionne autour de cela en utilisant une technique pour laquelle je n’ai pas fourni de code source à la requête de Microsoft, car la technique peut s’interrompre dans la version finale de Whistler, et Microsoft explore des moyens de prendre en charge le raccordement d’appels système. Windows NT n’a pas été conçu pour prendre en charge le raccordement d’appels système, ce que nous avons lancé avec la première version de Regmon au milieu de 1996.
Voici un conseil Filemon/Regmon non documenté. Je reçois souvent des courriers électroniques qui demandent comment exécuter Regmon ou Filemon à partir d’un compte non administratif sur Windows NT/2000 Il existe de nombreux cas où une certaine application fonctionne correctement lorsqu’elle est exécutée à partir du compte administrateur, mais pas à partir de celle d’un utilisateur non privilégié, où Regmon et Filemon seraient utiles pour déterminer la raison de l’échec de l’application (c’est généralement un problème lié aux paramètres de sécurité sur un fichier ou une clé de Registre). Toutefois, l’exécution de Regmon et Filemon à partir d’un compte non privilégié échoue, car Filemon et Regmon installent les pilotes de périphérique, ce qui nécessite des privilèges d’administrateur.
Toutefois, il existe une astuce qui vous permet de contourner ce problème : si vous vous connectez en tant qu’administrateur et démarrez Filemon ou Regmon, vous pourrez ensuite les exécuter à partir de comptes non privilégiés. Cela est dû au fait que Filemon et Regmon installent un pilote lors de leur première exécution et, dans les exécutions suivantes, accèdent au pilote déjà chargé. Étant donné que je n’implémente aucune sécurité dans le pilote, un utilisateur non privilégié peut exécuter les outils une fois le pilote chargé. Rencontrez-vous un problème de sécurité ? Oui, mais Filemon et Regmon sont destinés à être des outils de résolution des problèmes. Ainsi, moi et les personnes qui demandent comment exécuter les utilitaires à partir de comptes non privilégiés, la considèrent comme une fonctionnalité.
Téléchargez Regmon v4.32 avec le code source complet à www.sysinternals.com/regmon.htm.
DEBUGVIEW V4.02
L’une des applications pour laquelle j’ai reçu le plus de commentaires des utilisateurs est, étonnamment, DebugView. Cette nouvelle version présente des améliorations significatives qui répondent à la plupart des demandes de fonctionnalités que j’ai reçues, et rendent DebugView plus puissant que jamais.
Plus visiblement, DebugView prend désormais en charge jusqu’à cinq filtres de mise en surbrillance différents, chacun avec ses propres couleurs personnalisables. Cela vous permet d’accéder simultanément à différents mots clés dans votre sortie de débogage et de les distinguer facilement. En outre, DebugView implémente la même nouvelle syntaxe de filtrage que Filemon et Regmon, ce qui rend les caractères génériques facultatifs pour la correspondance des sous-chaînes.
Une plainte que j’ai reçue concernant les versions précédentes de DebugView est que, même si vous vouliez simplement capturer la sortie de débogage Win32, vous aviez toujours besoin de privilèges d’administration pour exécuter DebugView, car DebugView ne s’exécuterait pas s’il ne pouvait pas installer son pilote de périphérique. Cette nouvelle version s’exécute même à partir de comptes qui n’ont pas de privilèges spéciaux. S’il ne peut pas installer son pilote ou y accéder, il désactive simplement ses éléments de menu liés à la capture en mode noyau.
Deux fonctionnalités qui facilitent la capture automatique de la sortie de DebugView lorsque vous vous connectez sont son option de réduction à la barre d’état et la prise en charge des commutateurs de ligne de commande. À l’aide de commutateurs de ligne de commande, vous pouvez faire démarrer DebugView dans la barre d’état système et la sortie du journal qu’il capture dans un fichier. Après avoir démarré DebugView, vous pouvez utiliser une option de menu pour basculer son comportement de bouton réduire entre la réduction normale et la réduction dans la barre d’état système.
Pour les utilisateurs qui exécutent DebugView dans les sessions à distance sur les services terminal Windows 2000, DebugView capture désormais la sortie Win32 générée par les applications exécutées dans votre session à distance, et éventuellement, à partir de la session console. Cela est utile pour déboguer des serveurs COM et des services Win32 à distance, car ces types de programmes s’exécutent dans la session de console.
Enfin, DebugView fonctionne désormais sur Whistler Beta 1, avec la prise en charge de la capture de la sortie à partir de plusieurs nouvelles variantes de Whistler sur la fonction DbgPrint en mode noyau.
Téléchargez DebugView v4.02 à l’adresse www.sysinternals.com/dbgview.htm.
DANS WINDOWS 2000, 3e ÉDITION
Le livre officiel sur les composants internes de Windows 2000 est maintenant disponible ! Cette édition, co-auteure par David Solomon (www.solsem.com) et Mark Russinovich, est plus de 40 % supérieure à la précédente, avec une nouvelle couverture des réseaux, plug-and-play, gestion de l’alimentation, services, registre, WMI, démarrage et arrêt, et stockage. Il inclut également un CD avec plusieurs outils puissants, qui ne sont disponibles nulle part ailleurs, pour examiner les éléments internes de Windows 2000.
L’un des outils que j’ai écrits spécifiquement pour le livre est LiveKd, un programme qui vous permet d’exécuter les deux débogueurs du noyau Microsoft, i386kd et WinDbg, sur un système en direct comme si vous regardiez une image mémoire après incident. La plupart des expériences présentées dans le livre fonctionnent sur un système en direct lorsqu’elles sont exécutées à l’aide de LiveKd. LiveKd fonctionne en installant un pilote de filtre de système de fichiers qui présente la mémoire physique de l’ordinateur au débogueur Microsoft comme s’il s’agissait d’un fichier d’image mémoire après incident. LiveKd crée un fichier de pseudo-vidage de 0 longueur, et lorsque le débogueur lit à partir du fichier, LiveKd retourne des données à partir de la mémoire physique. Consultez la page errata et mises à jour du livre pour un correctif LiveKd qui corrige une incompatibilité entre LiveKd v1.0 et plusieurs scanneurs de virus à l’accès.
Consultez la table des matières du livre et commandez maintenant via www.sysinternals.com/insidew2k.htm.
MAGASINE WINDOWS 2000 DE NOVEMBRE ET D’HIVER
Vous êtes curieux de savoir ce qui a changé exactement entre NTFS v4 et NTFS v5 ? Si c’est le cas, case activée ma série en deux parties dans les numéros de novembre et d’hiver du magazine Windows 2000. La partie 1 décrit les points d’analyse, les jonctions d’annuaires, les points de montage de volume, la prise en charge des quotas et les paramètres de sécurité consolidés. La partie 2 se termine par un regard attentif sur le chiffrement, les flux, le suivi des liens distribués et le journal des modifications. Les deux articles vous amènent plus loin que d’autres, en présentant les modifications sur disque et le comportement interne de ces nouvelles fonctionnalités.
Une chose dont je ne parle pas dans les articles est que NTFS pour Windows NT 4 n’est pas vraiment version
Retrouvez des liens vers toutes nos publications sur www.sysinternals.com/publ.htm.
SYSINTERNALS AT WWW.MICROSOFT.COM
Sysinternals a fait une apparition dans plusieurs nouveaux articles de la Base de connaissances Microsoft (KB) depuis la dernière lettre d’information, et j’ai également suivi certains anciens articles de la base de connaissances qui font référence à Sysinternals.
Q260513 PRB : une erreur se produit lorsque vous installez des produits Visual Studio
http://support.microsoft.com/support/kb/articles/Q260/5/13.ASP
Cet article recommande aux lecteurs d’utiliser Filemon et Regmon pour résoudre les problèmes d’installation de Microsoft Visual Studio.Q202258 XADM : Le système ne trouve pas le chemin spécifié – ID No : 0cx002003
http://support.microsoft.com/support/kb/articles/Q202/2/58.ASP
Microsoft guide en fait les utilisateurs dans l’utilisation de Filemon pour résoudre les problèmes de mise à niveau du Service Pack Exchange 5.0, avec un exemple de ligne de sortie Filemon et des recommandations sur la configuration des filtres.Q269383 PRB : Message « Erreur d’accès au Registre système » lors de l’affichage des références VB/VBA
http://support.microsoft.com/support/kb/articles/Q269/3/83.ASP
Regmon obtient la référence à partir de cet article, qui explique comment l’utiliser pour déterminer pourquoi la boîte de dialogue Références de l’IDE Visual Basic signale qu’elle ne peut pas accéder à une clé de Registre en raison d’un bogue dans Les rapports De cristal de Seagate qui applique des autorisations incorrectes à plusieurs clés.BOGUE Q269251 : L’automatisation de Windows Installer peut se bloquer lors de l’énumération de produits
http://support.microsoft.com/support/kb/articles/q269/2/51.asp
Regmon est à nouveau mis en surbrillance ici, où il est utilisé pour révéler un bogue d’automatisation Windows Installer.Q276525 Votre ordinateur peut cesser de répondre lorsque vous surveillez les handles ouverts
http://support.microsoft.com/support/kb/articles/Q276/5/25.asp
NtHandle est chargé de révéler un bogue dans Windows NT 4 SP6a, où le noyau se bloque dans certaines conditions lors de l’utilisation de NtHandle. Microsoft a travaillé avec moi pour résoudre le problème et ils ont émis un correctif logiciel. Si votre système NT 4 se bloque lors de l’utilisation de NtHandle, vous devez obtenir le lien suivant vers cet article.Q160660 Ntregmon.exe provoque l’arrêt 0x0000001E avec le nouveau Service Pack
http://support.microsoft.com/support/kb/articles/Q160/6/60.asp
Ce dernier est un vieux, mais bon. La première version de Regmon utilisait des numéros d’appel système codés en dur pour corriger la table de service système afin de raccorder les API du Registre. Comme les numéros d’appel système changent parfois d’un Service Packs à l’autre, cette technique est assez fragile, et je n’avais pas codé défensivement en prévision de cela (contre l’avis d’Andrew Schulman, qui craignait que Regmon ne se casse). Bien sûr, SP3 a introduit quelques nouveaux appels système, et Regmon plantait le système lorsqu’il crochetait des appels système incorrects. Bien que cela ait sûrement agacé quelques personnes, j’ai obtenu mon propre article kb de celui-ci!
LICENCES SYSINTERNALS
Même si le logiciel que vous téléchargez à partir de Sysinternals est un logiciel gratuit, ce qui signifie que vous pouvez l’utiliser sans payer de frais, vous n’êtes pas autorisé à les redistribuer ou à dériver des produits que vous distribuez à partir du code source Sysinternals. Par instance, si vous travaillez dans une entreprise où plusieurs utilisateurs trouvent certains outils Sysinternals utiles, vous ne pouvez pas publier les outils sur un partage interne ou un site Web. Au lieu de cela, placez un lien sur votre site vers la page d’accueil de chaque outil sur Sysinternals. Cela permet également de vous assurer que vos collègues téléchargent toujours les dernières versions.
Si vous souhaitez redistribuer les outils Sysinternals en interne, avec un produit commercial ou sur un CD de shareware, ou si vous souhaitez baser un produit commercial ou un programme redistribuable sur le code source Sysinternals, envoyez un e-mail expliquant les détails de votre utilisation souhaitée à licensing@....
INFORMATIONS INTERNES
NFI
J’ai révélé l’existence de l’outil DiskEdit que Microsoft a envoyé par inadvertance sur le CD NT 4 SP4. DiskEdit est une visionneuse de structure de système de fichiers très puissante, bien que bizarre, que vous pouvez utiliser pour examiner les structures de données NTFS et FAT (bien que ce soit la prise en charge NTFS intéressante) sur disque. Si vous avez manqué le CD NT 4 SP 4 et que vous souhaitez explorer les structures NTFS sur disque, vous n’êtes pas totalement dans le noir. Microsoft a publié un outil gratuit nommé NFI (NTFS Information) qui comprend et peut vider les structures internes des volumes NTFS. Bien que sa sortie ne soit pas aussi détaillée que celle de DiskEdit, elle est intéressante et révélatrice.
Vous pouvez télécharger NFI dans le cadre des outils de support OEM à l’adresse http://support.microsoft.com/support/kb/articles/q253/0/66.asp. L’exécution de NFI avec un nom de fichier vide l’enregistrement NTFS MFT pour ce fichier. L’exemple suivant montre que NFI vide l’enregistrement MFT pour le $Quota
fichier de métadonnées, un fichier qui existe uniquement si la gestion des quotas est activée sur un volume :
C:\nfi c:\$extend\$quota
File 24
\$Extend\$Quota
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $O (resident)
$INDEX_ROOT $Q (resident)
La sortie indique que le fichier occupe la 24e entrée dans le MFT (son index de fichier est 24) et qu’il contient quatre attributs, y compris les informations standard, le nom de fichier et deux racines d’index (et index est essentiellement une liste d’entrées compilée, comme un répertoire). J’explique comment NTFS utilise les $Quota
index de ma dernière série de Windows 2000 Magazine sur NTFS v5.
Pour vider tous les fichiers sur un volume, spécifiez la lettre de lecteur sur la ligne de commande de NFI sans nom de fichier, par exemple nfi c:
. Vous verrez une liste de chaque entrée MFT, y compris tous les fichiers de métadonnées.
NFI a d’autres talents, comme la capacité à traduire un numéro de secteur dans le fichier dans lequel elle réside. Vous voulez savoir dans quel secteur de fichiers 2345 sur le lecteur C:
se trouve ? Utilisez la commande nfi c: 2345
. Notez que cela échoue sur les volumes RAID logiciels tels que les jeux de volumes et les jeux à bandes. NFI fonctionne à la fois sur NT 4 et Windows 2000.
CLÉS DE REGISTRE WIN9X MASQUÉES
Il y a deux questions, j’ai dit que je couvrirais « les clés de registre Win9x masquées » dans le bulletin suivant, et plusieurs d’entre vous m’ont rappelé que j’avais oublié. Donc, ce mois-ci, je vais vous parler des clés de Registre masquées dans Windows 9x.
Il y a plusieurs années, j’ai découvert un moyen de créer des clés de Registre masquées dans Windows NT. Par masqué, je veux dire que, bien que vous puissiez voir les clés accessibles par l’application qui les crée avec Regmon, vous ne pouvez pas écrire un programme Win32 pour examiner les valeurs de la clé, ni les clés avec les éditeurs regedit ou Regedt32 Registry. Les clés masquées sont utiles pour stocker des données que vous ne souhaitez pas que les utilisateurs finaux puissent modifier, comme la date d’expiration d’un produit d’évaluation.
L’astuce pour créer une clé de Registre masquée a été ma réalisation que l’API NT native, qui est l’interface d’appel système sur laquelle l’API Win32 est générée, exige que les clés de Registre soient spécifiées comme des chaînes Unicode comptées.
Une chaîne Unicode comptée est une chaîne dont la longueur est indiquée par un champ de longueur, et non par la présence d’un terminateur null. À l’aide de l’API native, vous pouvez donc créer des clés de Registre qui contiennent un caractère null, comme "test\0test"
. Étant donné que l’API de clé de Registre de l’API Win32 est basée sur des chaînes terminées par null, il n’existe aucun moyen d’ouvrir une clé de Registre qui contient une terminaison null à l’aide de l’API Win32. Si vous avez essayé de transmettre l’exemple de nom de clé précédent à RegOpenKey
ou RegCreateKey
qu’il est traité comme "test"
, avec la chaîne tronquée au caractère null. Étant donné que tous les éditeurs du Registre existants, y compris ceux regroupés avec Windows NT et Windows 2000, utilisent l’API Win32, une application qui utilise l’API native pour créer des noms incorporés à caractères null crée des clés masquées.
Cette méthode fonctionne sur Windows NT, mais qu’en est-il de Windows 9x ? Je ne pensais pas qu’il y avait un moyen de créer des clés de Registre masquées sur Windows 9x jusqu’à ce que quelqu’un m’ait envoyé un e-mail avec un fichier journal Regmon qui montre Internet Explorer (IE) accès aux clés qui n’apparaissent pas dans Regedit. Pour voir cela par vous-même, démarrez Regmon et définissez le filtre d’inclusion suivant : « policydata ». Démarrez ensuite Internet Explorer (qui fonctionne pour toutes les versions d’Internet Explorer 4 et IE 5) et visitez un site web. Si vous ne voyez aucune sortie dans Regmon, accédez à la boîte de dialogue de configuration des options d’Internet Explorer et vérifiez que l’Assistant Contenu est activé.
Si le Conseiller de contenu est activé ou a déjà été activé sur votre système, vous verrez des accès à la HKLM\PolicyDat
clé et à ses sous-clés. Toutefois, vous ne trouverez pas de clé PolicyData sous HKEY_LOCAL_MACHINE
lorsque vous recherchez dans Regedit. Prenez une minute et voyez si vous pouvez comprendre ce qui se passe.
La réponse est qu’Internet Explorer charge dynamiquement une ruche du Registre à l’aide de l’API RegLoadKey
Win32, lit les valeurs dont il a besoin, puis décharge la ruche avec RegUnloadKey
. La ruche est nommée C:\Winows\System\Ratings.pol
: le fichier est masqué et en lecture seule, mais vous pouvez le révéler en tapant attrib –r –h c:\windows\system\ratings.pol
.
Les traces que vous voyez dans Regmon vous montrent les informations que le Conseiller de contenu recherche dans la ruche. Si vous souhaitez explorer son contenu vous-même, téléchargez mon utilitaire Regload à partir de www.sysinternals.com/regload.zip et exécutez-le avec la syntaxe suivante : regload test c:\windows\system\ratings.pol
. Ouvrez ensuite Regedit et accédez à HKLM\test
. Les valeurs que vous trouverez correspondent aux paramètres que vous spécifiez dans l’Assistant Contenu et sont liées au fichier de configuration nommé dans la valeur Users\FileName0
de la ruche. La valeur pointe généralement vers C:\Windows\System\RSACi.rat
, le fichier d’évaluation défini par l’Association d’évaluation du contenu Internet. Incidemment, vous pouvez voir une valeur avec le nom un peu humoristique de « PleaseMom » dans les paramètres du Registre de le Conseiller de contenu, par exemple sous HKLM\Test\Users\Default
. Cette valeur provient de la case à cocher « Le superviseur peut taper un mot de passe pour permettre aux utilisateurs d’afficher du contenu restreint » de la page Général de la boîte de dialogue Paramètres de le Conseiller de contenu.
La raison pour laquelle Microsoft masquerait l’existence de ces valeurs de Registre devrait être évidente. Cependant, il y a une faiblesse assez sérieuse dans leur conception. Notez que lorsque vous activez le Conseiller de contenu, vous devez spécifier un mot de passe qui protège les paramètres de le Conseiller de contenu. Ce mot de passe est stocké dans HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Ratings\Key
. Supprimez cette valeur et, par défaut, vous pouvez accéder aux paramètres de le Conseiller de contenu sans entrer de mot de passe ! Maintenant, si les développeurs d’Internet Explorer ont eu la peine d’obfusquer les paramètres de le Conseiller de contenu, pourquoi laisser cette porte arrière traîner dans l’ouverture ? Conception de sécurité Microsoft typique, je suppose. Au fait, pour décharger la clé que vous avez chargée avec Regload, tapez regload test
simplement .
NOUVEAUTÉS À VENIR
NOUVEAUX APPELS SYSTÈME WHISTLER
Whistler est une évolution incrémentielle du système d’exploitation Windows 2000 qui met l’accent sur une fiabilité accrue et une migration facile des utilisateurs à partir des systèmes d’exploitation Windows 9x. Toutefois, il inclut certaines modifications du noyau. Les fonctions de noyau les plus visibles sont les quelques nouveaux appels système et les fonctions de noyau exportées (utilisables par les pilotes de périphérique). La prochaine fois, je vous donnerai un aperçu de ces nouvelles API de noyau.
Merci d’avoir lu le bulletin Sysinternals.
Publié le jeudi 30 novembre 2000 à 19 h 05 par ottoh
[Archives des newsletters ^] [< Volume 2, Numéro 4] [Volume 3, Numéro 1 >]