[Archives des newsletters ^] [< Volume 4, Numéro 3] [Volume 5, Numéro 2 >]
Bulletin d’information The Systems Internals Volume 5, numéro 1
http://www.sysinternals.com
Copyright (C) 2003 Mark Russinovich
19 février 2003 - Dans ce numéro :
ÉDITORIAL
NOUVEAUTÉS DE SYSINTERNALS
- Filemon v5.01
- DebugView v4.2
- NewSID v4.02
- PsShutdown v2.01
- Autoruns v2.02
- ShareEnum v1.3
- TCPView v2.31
- Bluescreen v3.0
- Sysinternals chez Microsoft
INFORMATIONS INTERNES
- Nouvelle vidéo d’internes XP/Server 2003
- Mark et David Solomon enseignent les services internes et la résolution des problèmes à Seattle
- Windows 2000 SP3 Common Criteria Certified
- Visual Studio : Placer une montre sur LastError
- Explication de la valeur du Registre LameButtonText
- Historique du développement Windows
- Présentation de l’analyse du vidage sur incident
Le bulletin Sysinternals 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/XP. Les produits Winternals Software incluent ERD Commander 2002, NTFSDOS Professional Edition (un pilote NTFS en lecture/écriture pour DOS) et la récupération à distance.
Winternals est fier d’annoncer Defrag Manager version 2.10, le défragmenteur d’entreprise le plus rapide et le plus complet disponible. Vous pouvez désormais gérer les planifications de défragmentation dans l’ensemble de votre entreprise Windows à partir d’un simple composant logiciel enfichable MMC, sans même avoir à installer un logiciel client sur vos systèmes NT, Windows 2000 ou Windows XP. Visitez http://www.winternals.com/es pour plus d’informations ou pour demander une version d’évaluation gratuite de 30 jours.
Bonjour,
Bienvenue dans le bulletin Sysinternals. Le bulletin compte actuellement 36 000 abonnés.
J’ai le plaisir de vous informer que David Solomon est l’auteur invité de l’éditorial de ce mois-ci, où il décrit certaines de ses expériences de dépannage du monde réel avec plusieurs utilitaires Sysinternals.
Veuillez transmettre le bulletin d’informations à des amis que vous pensez être intéressés par son contenu.
Merci !
- Mark
ÉDITORIAL - par David Solomon
J’ai une nouvelle devise : « En cas de doute, exécutez Filemon et Regmon (et Process Explorer) ».
Avant d'expliquer, permettez-moi d'abord de remercier Mark de m'avoir invité à écrire cet éditorial (bien sûr, comme il s'agit d'un rapport élogieux sur l'utilité de ses outils, ce n'est pas comme s'il me faisait une grande faveur ou quoi que ce soit d'autre !).
Comme beaucoup d’entre vous le savent, Mark et moi travaillons ensemble pour aider à éduquer les gens sur les éléments internes de Windows. Notre dernier projet était une mise à jour du tutoriel vidéo sur les aspects internes de Windows 2000 que nous avons créé l'année dernière pour couvrir les changements du noyau dans Windows XP et Windows Server 2003, et notre prochain cours public sur les aspects internes de Windows aura lieu du 21 au 23 avril à Bellevue, Washington - voir les détails dans les sections correspondantes de ce bulletin. Et, comme beaucoup nous l’ont demandé, nous sommes dans le processus de notre livre Inside Windows 2000 for XP & Server 2003 (date de publication provisoire est en fin d’été).
Et maintenant, pourquoi je suis si enthousiasmé par les outils Sysinternals ? En effet, au cours de l'année écoulée, ils m'ont aidé à dépanner et à résoudre un large éventail de problèmes liés aux applications et aux systèmes, qui auraient été insolubles autrement. En fait, je ne peux pas commencer à décrire le nombre de problèmes totalement différents et non liés que j’ai pu résoudre avec ces outils. Même dans les cas où je ne pensais pas qu’ils aideraient, ils l’ont fait. D’où ma nouvelle devise, « En cas de doute, exécutez Filemon et Regmon ».
Il existe deux techniques de base que j’ai trouvées pour appliquer ces outils :
- Examinez la dernière chose dans la trace Filemon/Regmon que l’application a effectuée avant son échec. Cela peut pointer vers le problème.
- Comparez une trace Filemon/Regmon de l’application défaillante avec une trace d’un système opérationnel.
Dans la première approche, exécutez Filemon et Regmon, puis exécutez l’application. Au moment où l’échec se produit, revenez à Filemon et Regmon et arrêtez la journalisation (appuyez sur CTRL+E). Ensuite, accédez à la fin du journal et recherchez les dernières opérations effectuées par l’application avant son échec (plantage, blocage ou autre). À partir de la dernière ligne, effectuez votre chemin vers l’arrière en examinant les fichiers et/ou les clés de Registre référencés, ce qui permet souvent d’identifier le problème.
Utilisez la deuxième approche lorsque l’application échoue sur un système, mais fonctionne sur un autre. Capturez une trace Filemon et Regmon de l’application sur le système opérationnel et défaillant, puis enregistrez la sortie dans un fichier journal. Ensuite, ouvrez les fichiers journaux bons et incorrects avec Excel (prenez les valeurs par défaut dans l’Assistant Importation) et supprimez les 3 premières colonnes (sinon, la comparaison affichera chaque ligne comme différente, car les 3 premières colonnes contiennent des informations différentes de l’exécution à exécuter, telles que l’heure et l’ID de processus). Enfin, comparez les fichiers journaux résultants (par exemple avec WinDiff, qui sur Windows XP est inclus dans les outils de support gratuits que vous pouvez installer sur le CD XP, ou pour Windows NT4 et Windows 2000, vous pouvez le trouver dans le Kit de ressources).
Voici quelques exemples concrets.
Sur une station de travail Windows 2000 sur laquelle Microsoft Office 97 est installé, Word obtiendrait un Dr Watson peu de temps après le démarrage. Vous pouvez en fait taper quelques caractères avant que le Dr Watson ne se produise, mais que vous tapiez quoi que ce soit ou non, dans quelques secondes après le démarrage, Word planterait. Bien sûr, l’utilisateur avait essayé de désinstaller et de réinstaller Office, mais le problème persistait. J’ai donc exécuté Filemon et Regmon et j’ai regardé la dernière chose faite par Word avant qu’il coupe. La trace Filemon a montré que la dernière chose Word a été d’ouvrir une DLL d’imprimante HP. Il s’avère que la station de travail n’avait pas d’imprimante, mais en avait apparemment une à un moment donné. J’ai donc supprimé l’imprimante HP du système et le problème est parti !
Apparemment, Word énumérant les imprimantes au démarrage a provoqué le chargement de cette DLL, ce qui a provoqué la mort du processus (pourquoi cela s’est produit, je ne sais pas- peut-être que l’utilisateur avait installé une version bidon; mais comme le système n’avait plus d’imprimante, cela n’avait vraiment pas d’importance).
Dans un autre exemple, Regmon a empêché un utilisateur d’effectuer une réinstallation complète de son système de bureau Windows XP. Le symptôme était que Internet Explorer (IE) se bloque au démarrage si l’utilisateur n’a pas d’abord composé manuellement la connexion Internet. Cette connexion Internet a été définie comme connexion par défaut pour le système. Par conséquent, le démarrage d’Internet Explorer aurait dû provoquer une numérotation automatique vers Internet (car Internet Explorer a été configuré pour afficher une page d’accueil par défaut au démarrage). Suivant ma nouvelle devise, j’ai exécuté Filemon et Regmon et j’ai regardé vers l’arrière à partir du point dans le journal où IE était suspendu. Filemon n’a rien montré d’inhabituel, mais le journal Regmon a montré une requête à une clé HKEY_CURRENT_USER\Software\Microsoft\RAS Phonebook\ATT
.
L’utilisateur m’avait dit qu’il avait installé le programme de numérotation AT&T à un moment donné, mais qu’il l’avait désinstallé et créé manuellement la connexion d’accès à distance.
Comme le nom de la connexion dialup n'était pas « ATT », j'ai soupçonné qu'il s'agissait d'un résidu de registre provenant de la désinstallation qui provoquait l'étouffement d'IE.
J’ai donc renommé la clé et le problème est parti !
L’utilisation de la technique « comparer les journaux » a permis de résoudre la raison pour laquelle Access 2000 était suspendu à la station de travail XP d’un programmeur essayant d’importer un fichier Excel. L’importation du même fichier a fonctionné correctement sur les stations de travail d’autres utilisateurs, mais elle a échoué sur cette station de travail. Ainsi, une capture d’Access a été effectuée sur le système opérationnel et défaillant. Les fichiers journaux ont été comparés à Windiff après avoir été convenablement classés. Les premières différences étaient dues à des noms de fichiers temporaires différents et à des noms de noms différents en raison de différences de cas, mais bien sûr, il ne s’agissait pas de « différences pertinentes » entre les deux systèmes.
La première différence qui n’était pas correcte était qu’une DLL Access était chargée à partir du \Windows\System32
système défaillant, mais à partir du \Program Files\Microsoft Office\Office
dossier sur le système de travail.
La comparaison des DLL a révélé que la version dans \Windows\System32
provient d’une version précédente d’Access. Ainsi, l’utilisateur a renommé cette DLL en .bad
et ré-exécuté Access et le problème a disparu !
L’une des classes de problèmes Filemon est incroyablement utile pour la découverte des problèmes d’autorisation de fichier. De nombreuses applications signalent mal les erreurs d’accès refusé. Toutefois, l’exécution de Filemon révèle clairement les échecs de ce type, car la colonne de résultat indique « ACCÈS REFUSÉ » pour les échecs d’ouverture de fichiers en raison de problèmes de droits (et la version la plus récente indique même le nom d’utilisateur qui n’a pas pu accéder au fichier). Deux exemples spécifiques où c’était le cas :
- Un utilisateur recevait une erreur macro étrange au démarrage de Word ; il s’avère que les autorisations sur un fichier .DOT référencé par une macro avait été modifié pour interdire cet accès utilisateur. Filemon a clairement montré que Word obtenait une erreur d'accès refusé sur le fichier .DOT. Une fois les autorisations corrigées, le problème a disparu.
- Une application Outlook a fait apparaître une boîte de message qui disait
Application defined or object-defined error-Message ID: [Connect].[LoadGlobalVariables].[LN:?].[EN:287]
-un autre exemple de la façon dont de nombreuses applications génèrent des messages d'erreur inutiles sur des échecs d'E/S aléatoires. Là encore, l’exécution de Filemon a révélé une erreur d’accès refusé (cette fois à un dossier auquel Outlook devait accéder). Les autorisations ont été ajustées sur le dossier et le problème a disparu.
Ce ne sont que quelques exemples, j’ai beaucoup d’autres histoires de réussite où Filemon et Regmon (et Process Explorer, dont je n’ai pas discuté ici) ont sauvé la journée. Il n’est pas étonnant que le support technique Microsoft utilise ces outils quotidiennement pour aider à résoudre les problèmes des clients (au dernier décompte, quelque 40 articles de la Base de connaissances pointent vers les outils de Mark-voir http://www.sysinternals.com/ntw2k/info/mssysinternals.shtml pour obtenir une liste).
Donc, en cas de doute, exécutez Filemon et Regmon !
David Solomon David Solomon Séminaires d’experts http://www.solsem.com
NOUVEAUTÉS DE SYSINTERNALS
FILEMON V5.01
Filemon, l’un des utilitaires que David met en évidence dans son éditorial, a subi sa première révision majeure depuis plusieurs années. La nouvelle version apporte un nouveau niveau de facilité d’utilisation à un outil qui disposait déjà d’une interface utilisateur accessible. L’amélioration la plus significative est la modification de la façon dont l’activité du système de fichiers est présentée dans le paramètre par défaut de Filemon lors de l’exécution sur Windows NT, 2000, XP ou Server 2003, une chose à laquelle j’avais pensé depuis un certain temps et que j’ai finalement implémentée en fonction des commentaires des utilisateurs réels de David.
Les versions précédentes de Filemon affichent les opérations de système de fichiers avec les noms textuels des demandes d’E/S internes qui exécutent les opérations.
Bien que la présentation soit techniquement précise, de nombreux utilisateurs ne connaissent pas les rouages du sous-système d'E/S de Windows et trouvent que des opérations telles que l'absence de sens FASTIO_CHECK_IF_POSSIBLE
et d'autres, telles que l'échec signalé d'une opération FASTIO_READ
, sont déroutantes. Il existe de nombreux autres exemples d’opérations que la plupart classeraient comme « bruit » et des noms d’opérations qui ne sont pas explicites.
Le mode d’affichage par défaut de Filemon version 5.01 dispose désormais d’un mécanisme de filtrage pour supprimer l’activité inutile dans la plupart des scénarios de résolution des problèmes et qui présente des noms intuitifs pour toutes les opérations d’E/S.
FASTIO_CHECK_IF_POSSIBLE
est filtré, FASTIO_READ
les échecs ne sont pas affichés et FASTIO_READ
ceux qui réussissent sont signalés en tant qu’opérations READ
.
En outre, la vue par défaut omet l’activité du système de fichiers dans le processus Système, qui est le processus à partir duquel le Gestionnaire de mémoire et de cache effectue une activité en arrière-plan, et toute activité de pagination du Gestionnaire de mémoire, y compris celle vers le fichier de pagination du système. The Options|L’élément de menu avancé satisfait les utilisateurs, tels que les développeurs de pilotes de filtre de système de fichiers, qui souhaitent la vue « brute » de l’activité du système de fichiers affichée par les versions précédentes de Filemon.
Plusieurs utilisateurs, y compris des employés de Microsoft, ont demandé à Filemon d’afficher le compte dans lequel les erreurs « accès refusé » se produisent afin de faciliter le débogage des paramètres de sécurité dans les environnements Terminal Services. En réponse, la version 5.01 affiche ces informations ainsi que le mode d’accès (lecture, écriture, suppression, etc.) qu’un processus souhaite quand il ouvre un fichier et comment un fichier est ouvert, par exemple s’il est remplacé ou ouvert uniquement s’il existe.
De nombreuses sessions de résolution des problèmes se concentrent sur l’identification des fichiers auxquels un processus accède ou tente d’accéder, auquel cas les opérations telles que les lectures, les écritures et les fermetures ne sont que du bruit. En reconnaissance de ce fait, j’ai ajouté une nouvelle option de filtrage « ouverture de journal » qui vous permet d’isoler uniquement les opérations ouvertes.
Un autre changement majeur concerne la façon dont Filemon v5.01 gère les partages mappés réseau. Dans les versions précédentes, chaque mappage s’affiche sous la forme d’une lettre de lecteur dans le menu Lecteurs. À présent, tous ces mappages sont inclus dans la sélection « Réseau » du menu Volumes (qui est le menu Renommé Lecteurs).
En sélectionnant Réseau, Filemon surveille tous les partages réseau et signale l’activité réseau de type UNC du type qui se produit lorsque vous accédez à des fichiers distants à l’aide de la convention d’affectation de noms «\\computer\share\directory
».
Cette modification vous permet d’afficher l’activité des fichiers réseau même lorsque vous n’avez pas de partage réseau mappé, comme requis par les versions précédentes de Filemon. De nombreuses autres modifications mineures ont été apportées au dernier Filemon, notamment une structure de menu mise à jour qui reflète les menus plus utilisables que j’ai introduits dans Regmon il y a plusieurs mois.
Téléchargez Filemon v5.01 à l’adresse
http://www.sysinternals.com/ntw2k/source/filemon.shtml
À PROPOS DU CODE SOURCE FILEMON ET REGMON
Les développeurs de logiciels, de matériels et de produits de mise en réseau prennent en charge Sysinternals en achetant des licences pour redistribuer notre code. Cependant, au cours de la dernière année, nous avons trouvé une gamme de logiciels, des chevaux de Troie aux produits commerciaux de quelques sociétés de plusieurs milliards de dollars, contenant du code source Sysinternals sans licence. Dans le but de maintenir la croissance de Sysinternals et nos produits sous licence légale, nous avons cessé de publier le code source de certains de nos produits, y compris les dernières versions de Filemon et Regmon. Nous continuerons de mettre le code source à la disposition des titulaires de licences commerciales. Si vous découvrez des miroirs pour le code source Sysinternals, faites-le nous savoir.
DEBUGVIEW V4.2
DebugView est un utilitaire Sysinternals très populaire que les développeurs de logiciels utilisent pour capturer la sortie de débogage générée par leur logiciel. La version v4.2 reflète un certain nombre d’améliorations et de fonctionnalités demandées par l’utilisateur. Une option demandée par Microsoft vous permet de capturer la sortie de débogage des processus s’exécutant dans la session de console d’un environnement Terminal Services lorsque vous exécutez DebugView dans une session hors console. V4.2 prend en charge les options de ligne de commande développées qui vous permettent de spécifier un fichier journal à charger, la profondeur de l’historique et d’autres comportements de démarrage. Plusieurs utilisateurs ont demandé des filtres de plus en plus longs, un filtrage sur les ID de processus et la possibilité d’insérer des commentaires dans la sortie, ce qui est possible avec la dernière version. La nouvelle version est complétée par plusieurs correctifs de bogues, une meilleure prise en charge de l’extraction de la sortie de débogage du noyau à partir des fichiers de vidage sur incident, et de meilleures fenêtres bulles pour le texte qui dépasse la largeur de sa colonne de sortie et même de l’écran.
Téléchargez DebugView v4.2 à l’adresse
http://www.sysinternals.com/ntw2k/freeware/debugview.shtml
NEWSID V4.02
Le problème de duplication SID (ID de sécurité) est un problème que vous rencontrerez si vous utilisez une image Windows préinstallée pour déployer plusieurs systèmes. Chaque ordinateur qui partage l’image a le même SID Windows interne, qui est un identificateur que le sous-système de sécurité Windows utilise comme base pour les identificateurs de groupe et de compte locaux. En raison des problèmes de sécurité, le partage peut amener la plupart des administrateurs à prendre des mesures pour post-appliquer un SID unique à chaque ordinateur à l’aide d’un outil de modification de SID.
NewSID, le changeur SID de Sysinternals, est populaire, car contrairement à d’autres changeurs qui s’appuient sur DOS ou nécessitent qu’un système soit exempt de logiciel complémentaire, NewSID est un programme Win32 que vous pouvez utiliser pour affecter un nouveau SID aux ordinateurs qui ont installé des applications. La version 4.02 est une mise à jour majeure qui a une nouvelle interface d’Assistant, ajoute la prise en charge de Windows XP et vous permet de renommer un ordinateur.
Une fonctionnalité demandée par de nombreux administrateurs est la possibilité de NewSIDs d’appliquer un SID que vous spécifiez, ce qui peut être utile pour la migration des paramètres d’une installation vers un autre ordinateur ou pour la réinstallation. À mesure que NewSID s’exécute, le Registre augmente lorsqu’il applique des paramètres de sécurité temporaires à des parties du Registre afin de les rendre accessibles. Cette surcharge peut entraîner le dépassement de son quota de taille par une nouvelle fonction v4.02 qui compresse le Registre à sa taille minimale comme dernière étape d’opération.
Téléchargez NewSID v4.02 à l’adresse
http://www.sysinternals.com/ntw2k/source/newsid.shtml
PSSHUTDOWN V2.01
Shutdown est un outil que Microsoft a longtemps inclus dans le Kit de ressources Windows et qui est inclus dans les installations de Windows XP. Avant la version 2.01, PsShutdown, membre du kit d’outils d’administration en ligne de commande Sysinternals PsTools, était simplement un clone de Shutdown, mais cette dernière version étend ses fonctionnalités bien au-delà de celles de Shutdown. Par exemple, vous pouvez arrêter et mettre hors tension si un système prend en charge la gestion de l’alimentation, verrouille le bureau et déconnecte l’utilisateur interactif, le tout sur l’ordinateur local ou distant, sans installer manuellement de logiciel client.
Télécharger PsShutdown v2.01 à l’adresse
http://www.sysinternals.com/ntw2k/freeware/psshutdown.shtml
Téléchargez l’intégralité de la suite PsTools à l’adresse
http://www.sysinternals.com/ntw2k/freeware/pstools.shtml
AUTORUNS V2.02
Nous avons tous été ennuyés par l’installation d’applets indésirables qui s’exécutent lorsque nous nous connectons et ont été frustrés dans notre recherche de leur commande de démarrage. Il n’est pas étonnant que Windows dispose de près de 2 douzaines de mécanismes pour une telle activation. L’utilitaire MsConfig inclus dans Windows Me et XP peut parfois vous aider, mais il manque environ la moitié des emplacements de démarrage possibles.
Autoruns, un outil de Sysinternals écrit par Bryce Cogswell et moi-même, vous donne une vue d'ensemble. Son affichage affiche une liste de tous les emplacements de registre et de fichiers possibles où une application peut s’exécuter au démarrage ou à l’ouverture de session du système. La dernière version affiche des informations sur l’icône et la version pour chaque image configurée au démarrage pour faciliter l’identification et ajoute des améliorations de l’interface utilisateur comme un menu contextuel. En outre, la nouvelle version identifie davantage d'emplacements de démarrage, notamment les scripts de connexion et de déconnexion, les tâches du planificateur de tâches qui s'exécutent lors de la connexion et les points de lancement des modules complémentaires d’Explorer.
Téléchargez Autoruns v2.01 à l’adresse
http://www.sysinternals.com/ntw2k/source/misc.shtml
SHAREENUM V1.3
Les administrateurs système négligent souvent une partie essentielle de la sécurité du réseau local : les dossiers partagés. Les utilisateurs au sein d’un environnement d’entreprise créent fréquemment des partages dans des dossiers contenant des documents afin de fournir un accès facile aux collègues de leur groupe. Malheureusement, de nombreux utilisateurs ne parviennent pas à verrouiller leurs partages avec des paramètres qui empêchent d’autres employés non autorisés d’accéder à des informations potentiellement sensibles.
ShareEnum est un utilitaire Sysinternals écrit par Bryce Cogswell qui vous aide à identifier les partages non autorisés et à renforcer la sécurité sur les partages valides. Lorsque vous démarrez ShareEnum, il utilise l’énumération NetBIOS pour localiser les ordinateurs sur votre réseau et signale les partages qu’ils exportent, ainsi que des détails sur les paramètres de sécurité appliqués aux partages. En quelques secondes, vous pouvez repérer les partages ouverts et double-cliquer sur un partage pour l’ouvrir dans Explorer afin de pouvoir modifier ses paramètres. Vous pouvez également utiliser la fonctionnalité d’exportation de ShareEnum pour enregistrer les analyses et comparer une analyse actuelle à celle que vous avez enregistrée précédemment.
Téléchargez ShareEnum v1.3 à l’adresse
http://www.sysinternals.com/ntw2k/source/shareenum.shtml
TCPVIEW V2.31
TCPView est un utilitaire graphique de type netstat qui affiche la liste des points de terminaison TCP et UDP actifs d’un système. Sur les installations Windows NT, 2000, XP et Server 2003, il vous montre le processus qui possède chaque point de terminaison. La version 2.31 affiche l’icône du fichier image d’un processus pour faciliter l’identification.
Téléchargez TCPView v2.31 à l’adresse
http://www.sysinternals.com/ntw2k/source/tcpview.shtml
BLUESCREEN V3.0
Bluescreen of Death Screensaver Sysinternals est un téléchargement favori depuis plusieurs années et la version 3.0 ajoute la compatibilité Windows XP. L'économiseur d'écran affiche un écran bleu de la mort d'apparence authentique, avec le formatage et les détails aléatoires propres au système d'exploitation sur lequel il est exécuté (par exemple Windows NT, 2000 ou XP), et après une pause, il simule un cycle de redémarrage et la répétition ultérieure d'un autre écran d'arrêt. C’est tellement convaincant que David Solomon m’a trompé avec lui et je l’ai dupé avec lui. Utilisez-le comme votre propre économiseur d’écran ou pour tromper vos amis et collègues, mais assurez-vous que votre patron a un sens de l’humour avant de l’installer sur un système de production.
Téléchargez Bluescreen v3.0 à l’adresse
http://www.sysinternals.com/ntw2k/freeware/bluescreensaver.shtml
SYSINTERNALS AT WWW.MICROSOFT.COM
Voici la dernière version des références Sysinternals dans les articles de la Base de connaissances Microsoft (KB) publiés depuis la dernière lettre d’information. Je suis honoré de vous signaler que cela porte à 41 le nombre total de références de base de connaissances à Sysinternals.
ACC2000 : Message d’erreur : Le composant ActiveX ne peut pas créer d’objet http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q319841&
COMMENT : résoudre les problèmes d’ASP dans IIS 5.0 http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q309051&
OL2002 : Comment créer des compléments COM Outlook approuvés http://support.microsoft.com/default.aspx?scid=KB;en-us;327657&
PRB : Erreur 80004005 « Le moteur de base de données Microsoft Jet ne peut pas ouvrir le fichier '(Inconnu)' » http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q306269&
Échec de déchargement de profil utilisateur lorsque vous démarrez, quittez ou déconnectez NetMeeting http://support.microsoft.com/default.aspx?scid=KB;EN-US; Q327612&
XADM : Message d’erreur : Erreur 123 : Le nom du fichier, le nom du répertoire ou la syntaxe de l’étiquette de volume est incorrect http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q318746&
INFORMATIONS INTERNES
NOUVELLE VIDÉO XP/SERVER 2003 INTERNALS
Notre nouvelle mise à jour vidéo sur les modifications internes de Windows XP/Server 2003 est disponible pour la commande en préversion ! En complément de notre didacticiel vidéo existant, INSIDE Windows 2000, ou en tant que produit autonome à part entière, cette nouvelle vidéo fournit une formation sur les modifications du noyau dans Windows XP et le nouveau produit de Microsoft Windows Server 2003, qui sera lancé en avril. Les sujets abordés incluent les performances, la scalabilité, la prise en charge 64 bits, les systèmes de fichiers, la fiabilité et la récupération.
Dans le même style interactif que son prédécesseur, la mise à jour Windows XP/Server 2003 vous place sur le bureau de David Solomon et Mark Russinovich pour 76 minutes de formation intensive et hautement ciblée. Il comprend des questions de révision, des exercices de laboratoire et un classeur imprimé, et est disponible en DVD vidéo et Windows Media sur CD-ROM.
Étant donné que ces vidéos ont été développées avec un accès complet au code source Windows et à l’équipe de développement, vous savez que vous obtenez l’histoire réelle. En guise de compliment ultime, Microsoft a concédé cette vidéo sous licence pour sa formation interne dans le monde entier.
PRIX SPÉCIAL PRÉVERSION SI VOUS ACHETEZ AVANT LE 15 MARS ! Achetez INSIDE Windows 2000 pour 950 USD et obtenez la mise à jour Windows XP/Server 2003 GRATUITEMENT ! C’est près de 40 % de moins que la valeur au détail combinée de 1 390 USD. Vous pouvez également acheter la vidéo de mise à jour Windows XP/Server 2003 autonome pour seulement 169 USD (valeur commerciale de 195 USD). Autres configurations de licence disponibles à partir du site web. Pour tirer parti de cette offre à temps limité, commandez dès maintenant à http://www.solsem.com/vid_purchase.html
MARK ET DAVID SOLOMON ENSEIGNENT LE FONCTIONNEMENT INTERNE ET LE DÉPANNAGE À BELLEVUE, WA
Écoutez David Solomon et moi présenter notre classe interne Windows 2000/XP/.NET Server de 3 jours à Bellevue, WA (près de Seattle) du 21 au 23 avril. Basé sur « Inside Windows 2000, 3rd Edition », il couvre les relations entre l'architecture du noyau et les mécanismes des composants clés du système, tels que les threads du système, la répartition des appels système, la gestion des interruptions, le démarrage et l'arrêt. Découvrez des techniques avancées de résolution des problèmes à l’aide des outils Sysinternals et comment utiliser Windbg pour l’analyse de base du vidage sur incident. Les éléments internes des sous-systèmes clés couverts incluent les threads de processus, la planification des threads, la gestion de la mémoire, la sécurité, le système d’E/S et le gestionnaire de cache. En comprenant le fonctionnement interne du système d’exploitation, vous pouvez tirer parti de la plateforme plus efficacement et plus efficacement déboguer et résoudre les problèmes.
Pour vous inscrire ou obtenir davantage d’informations, consultez http://www.sysinternals.com/seminar.shtml
WINDOWS 2000 SP3 COMMON CRITERIA CERTIFIED
Beaucoup d’entre vous sont probablement familiarisés avec les termes « Orange Book » et C2, qui sont tous deux liés à une norme d’évaluation de sécurité obsolète utilisée dans les années 1980 et 90 par le gouvernement américain pour évaluer les capacités de sécurité des logiciels, y compris les systèmes d’exploitation. Depuis 1999, les évaluations du Livre Orange, qui faisaient partie des critères d’évaluation du système informatique de confiance (TCSEC) du ministère de la Défense, ont été subsumées par le nouveau système de critères communs (CC). Le CC a été convenu par plusieurs nations comme une norme internationale d’évaluation de sécurité qui est plus riche que TSCEC et les évaluations obsolètes de l’Information Technology Security (ITSEC) de l’Angleterre.
Lorsqu’un fournisseur a son logiciel certifié par rapport à la norme CC, il spécifie un « profil de protection », qui est un ensemble de fonctionnalités de sécurité, et l’évaluation signale un niveau d’assurance, connu sous le nom de niveau d’assurance d’évaluation (EAL), que le logiciel répond aux exigences du profil de protection. Il existe 7 EAL avec des niveaux d’assurance plus élevés indiquant une plus grande confiance dans la fiabilité des fonctionnalités de sécurité du logiciel évalué.
Microsoft a soumis Windows 2000 pour l’évaluation CC par rapport aux profils de protection d’accès contrôlé, qui est à peu près l’équivalent CC de la classification TCSEC C2, il y a plusieurs années et en octobre 2002, son évaluation s’est terminée. Science Applications International Corporation (SAIC), la société indépendante qui a réalisé l'évaluation, a estimé que Windows 2000 avec le Service Pack 3 répondait au profil de protection du contrôle d'accès avec un niveau d'assurance d'évaluation (EAL) de 4 plus la correction des failles. Un EAL de 4 est considéré comme le niveau le plus élevé possible par un logiciel à usage général, et la correction des défauts fait référence au mécanisme Windows Update pour l’application en temps opportun des correctifs de sécurité. Cette évaluation est le niveau le plus élevé atteint jusqu’à présent sous le CC par un système d’exploitation.
VISUAL STUDIO : PLACER UNE MONTRE SUR LASTERROR
Si vous développez des applications qui s’appuient sur l’API Win32, vous avez presque certainement écrit du code qui exécute une fonction Win32, mais pour une raison quelconque ne signale pas d’erreurs spécifiques. Si c’est le cas, vous trouverez ce conseil utile. En ajoutant l'expression @ERR,hr
à la fenêtre de surveillance, vous verrez la représentation numérique et textuelle de la valeur stockée dans la variable du thread LastError
en cours, qui est la valeur renvoyée par la fonction Win32 GetLastError()
.
LA VALEUR DU REGISTRE LAMEBUTTONTEXT EXPLIQUÉE
Si vous avez examiné les traces Regmon sur un système Windows 2000 ou XP d’un démarrage d’application Windows, vous avez probablement vu des références à la valeur du Registre HKCU\Control Panel\Desktop\LameButtonText
, généralement avec une erreur NOTFOUND
. Quelqu’un chez Microsoft a apparemment un sens de l’humour, mais à quoi sert cette valeur ? Il s’avère qu’il stocke le texte que vous voyez dans les versions bêta et release candidate de Windows sur les barres de titre de fenêtre qui vous invitent à cliquer sur un lien afin de signaler des commentaires. Il serait intéressant de l’activer sur les versions non préversion de Windows pour placer du texte personnalisé, mais ses fonctionnalités sont malheureusement désactivées sur les versions de production.
HISTORIQUE DU DÉVELOPPEMENT WINDOWS
Paul Thurrott a une belle série d’articles en 3 parties sur l’histoire du processus de développement Windows NT. Voyez par vous-même sur http://www.winsupersite.com/reviews/winserver2k3_gold1.asp
PRÉSENTATION RAPIDE DE L’ANALYSE DU VIDAGE SUR INCIDENT
Lorsqu’un système se bloque immédiatement après l’installation d’un nouveau matériel ou logiciel, la cause est évidente. Parfois, cependant, des plantages système se produisent de temps en temps et il n’y a aucune raison apparente. Dans ce cas, la seule façon de déterminer la cause du plantage consiste à analyser un vidage sur incident. Dans ce tutoriel, je vais décrire le fonctionnement de l’analyse des incidents en ligne (OCA) de Microsoft et la façon dont elle peut vous donner la réponse à un casse-tête d’incident, puis vous expliquer comment configurer votre propre environnement d’analyse des incidents afin que vous puissiez examiner les plantages que l’OCA ne pourra pas ou ne peut pas analyser correctement.
Microsoft a introduit OCA avec la version de Windows XP pour être un service d’analyse automatisé basé sur un référentiel centralisé d’informations liées aux incidents. Après le redémarrage d’un système XP à partir d’un incident, il vous invite à envoyer des informations d’incident au site OCA (http://oca.microsoft.com/en/Welcome.asp). Si vous êtes d’accord, XP charge un fichier XML qui décrit votre configuration système de base ainsi qu’un fichier d’incident minidump de 64 Ko. Un minidump contient une petite quantité de données immédiatement pertinentes pour un incident, telles que le code d’incident, la pile du thread qui s’exécutait au moment de l’incident, la liste des pilotes chargés sur le système et les structures de données qui gèrent le processus en cours d’exécution lorsque l’incident s’est produit.
Une fois que l’OCA reçoit les informations, il procède à son analyse et stocke le résumé de l’analyse dans une base de données. Si vous suivez l’invite après le chargement et que vous visitez le site OCA, vous avez la possibilité de suivre l’analyse. Pour cela, vous devez vous connecter avec un compte Passeport. Vous entrez ensuite un nom pour l’incident et du texte décrivant la nature de l’incident. Si le moteur OCA met en corrélation l’incident avec d’autres dans la base de données pour laquelle Microsoft a identifié une cause, le site vous avertit par e-mail et lorsque vous revenez sur le site et que vous recherchez l’incident que vous avez envoyé, la résolution vous indique où obtenir une mise à jour du pilote ou du système d’exploitation. Malheureusement, bien que la prise en charge d’OCA soit intégrée à XP et qu’elle accepte les fichiers de vidage sur incident Windows 2000, elle ne prend pas en charge NT 4 et ne peut pas identifier la cause de la plupart des incidents (du moins selon mon expérience).
Pour effectuer vous-même l’analyse des incidents, vous aurez besoin des outils appropriés, que Microsoft fournit sous la forme du package Outils de débogage pour Windows que vous pouvez télécharger à partir de http://www.microsoft.com/ddk/Debugging/. Le package inclut, entre autres, l’outil d’analyse Windbg. Une fois les outils téléchargés et installés, exécutez Windbg et ouvrez le fichier |Boîte de dialogue Chemin du fichier de symbole. Là, vous indiquez à Windbg où trouver les fichiers de symboles pour la version du système d’exploitation à partir de laquelle un incident que vous analysez a été généré. Vous pouvez entrer un chemin d’accès à un répertoire dans lequel vous avez installé des symboles, mais cela vous oblige à obtenir des fichiers de symboles pour le système d’exploitation exact, le Service Pack et les correctifs à chaud installés sur le système d’incident. Il est fastidieux de tenir à jour manuellement les fichiers de symboles et, si vous souhaitez analyser des crashs provenant de différents systèmes, vous devez vous préoccuper de différents jeux de fichiers de symboles pour chaque installation.
Vous pouvez éviter les tracas liés au fichier de symboles en pointant le windbg sur le serveur de symboles de Microsoft. Lorsque vous le configurez pour utiliser le serveur de symboles, Windbg télécharge automatiquement les fichiers de symboles à la demande en fonction du crash dump que vous ouvrez. Le serveur de symboles stocke les symboles pour les versions bêta de NT 4 à Server 2003 et les versions candidates, y compris les Service Packs et les correctifs à chaud. La syntaxe pour diriger Windbg vers le serveur de symboles est srv*c:\symbols*http://msdl.microsoft.com/download/symbols
. Remplacez par c:\symbols
le répertoire dans lequel vous souhaitez stocker les fichiers de symboles. Pour plus d’informations sur les symboles, consultez http://www.microsoft.com/ddk/debugging/symbols.asp
Avant d’être prêt à analyser les vidages sur incident, vous devez effectuer une autre étape : configurer vos systèmes pour les générer. Pour ce faire, ouvrez l’applet système dans le panneau de configuration et, sur Win2k et versions ultérieures, cliquez sur le bouton Démarrage/arrêt de la page Avancé. Sur NT 4, accédez à l’onglet Démarrage/Arrêt de l’applet. La seule option de vidage sur incident sur les systèmes NT 4 est un vidage de la mémoire complète, où tout le contenu de la mémoire physique au moment d’un incident est enregistré dans le fichier que vous spécifiez. Sur Win2k et les versions ultérieures, il existe trois options : mini, noyau et full. La valeur par défaut de Win2K & XP Professional et Home est mini ; par défaut, les systèmes serveurs est full. Pour les ordinateurs de station de travail/clients, modifiez le paramètre de mini-vidage du noyau, ce qui enregistre uniquement des parties de la mémoire physique appartenant au système d’exploitation (par opposition aux applications), car cela réduit la taille du fichier de vidage sur incident et fournit toujours des informations complètes sur les structures de données du noyau dont Windbg a besoin pour analyser efficacement un incident. Pour les systèmes serveur, les vidages complets sont corrects, mais les vidages du noyau sont un choix sûr (et peut-être votre seul choix si vous avez un très grand système de mémoire).
Vous êtes maintenant prêt à analyser un incident. Lorsqu’il se produit, chargez simplement le fichier de vidage résultant dans Windbg en sélectionnant le Fichier|Ouvrir l’option de menu Vidage sur incident. Lorsque le vidage se charge, Windbg commence à le traiter et vous verrez des messages sur la version du système d’exploitation et le chargement des symboles. Ensuite, vous verrez un message avec le texte « Analyse de vérification des bogues ». La sortie qui suit le message signale les paramètres du code d’incident et du code d’incident, ainsi qu’un « probablement causé par ».
Dans certains cas, l’analyse de base effectuée ici par Windbg est suffisante pour identifier le pilote ou le composant du noyau défaillant. Toutefois, je recommande d’entrer toujours la commande suivante : !analyze -v
. Cette commande aboutit à la même analyse, mais avec plus d’informations. Par exemple, le texte explique la signification du code d’incident et vous indique ce que représentent les paramètres facultatifs, parfois avec des conseils sur les prochaines tentatives. Vous verrez également une trace de pile, qui est un enregistrement de l’exécution de la fonction menant au code dans lequel le plantage s’est produit. Si un pilote transmet des données défectueuses au noyau ou à un pilote identifié par l’analyse, vous pouvez voir son nom dans la trace et l’identifier comme cause racine possible.
Si vous souhaitez approfondir l’état du système au moment de l’incident, il existe de nombreuses commandes Windbg qui vous permettent de voir la liste des processus en cours d’exécution, des pilotes chargés, l’utilisation de la mémoire, etc. Le fichier d’aide Windbg contient également une référence de vérification des bogues que je vous recommande d’utiliser pour plus d’informations et d’aide, et si vous vous retrouvez toujours bloqué, je vous recommande d’effectuer une recherche dans la Base de connaissances de Microsoft (KB) pour le code d’incident. Microsoft crée des articles de base de connaissances pour les incidents courants et vous dirige vers des sites fournisseurs ou des correctifs à chaud qui corrigent des problèmes particuliers.
Si vous voulez me voir présenter ces informations en direct, avec des exemples, venez me voir à l’une des conférences suivantes :
- Le séminaire sur le fonctionnement interne et le dépannage que David et moi-même organisons en avril à Bellevue, WA
- Connexions Windows et .NET Magazine à Scottsdale, AZ en mai : http://www.winconnections.com/win
- TechEd US (Dallas) ou TechEd Europe (à Barcelone) cet été
Merci d'avoir lu la newsletter Sysinternals.
Publié le mercredi 19 février 2003 à 16:47 par ottoh
[Archives des newsletters ^] [< Volume 4, Numéro 3] [Volume 5, Numéro 2 >]