Test de prise en charge crashdump (LOGO)
Ce test vérifie que le pilote de miniport de stockage sur Windows prend en charge la création d’un fichier de vidage de la mémoire après une erreur d’arrêt du système.
Détails du test
| Spécifications |
|
| Plateformes |
|
| Versions prises en charge |
|
| Durée d’exécution attendue (en minutes) | 45 |
| Catégorie | Scénario |
| Délai d’expiration (en minutes) | 2700 |
| Nécessite un redémarrage | false |
| Nécessite une configuration spéciale | true |
| Type | automatique |
Documentation supplémentaire
Les tests de cette zone de fonctionnalité peuvent avoir une documentation supplémentaire, y compris les conditions préalables, l’installation et les informations de résolution des problèmes, que vous trouverez dans les rubriques suivantes :
- Documentation supplémentaire Device.Storage
- Documentation supplémentaire sur System.Fundamentals
- Documentation supplémentaire sur System.Server
Exécution du test
Avant d’exécuter le test, effectuez la configuration de test décrite dans les exigences de test pour le type de contrôleur de stockage que vous testez. Pour plus d’informations, consultez Vue d’ensemble des tests de l’adaptateur de stockage ou du contrôleur.
Ce test nécessite des logiciels et du matériel supplémentaires :
Appareil à tester
Disque dur avec un minimum de 20 Go disponibles sur la partition C:.
Avant d’exécuter le test, vous devez également remplir les conditions préalables suivantes :
Si votre système de test dispose d’une connexion Internet, aucune action n’est nécessaire.
Si votre système de test n’a pas de connexion Internet, créez un dossier nommé C:\Symbols et téléchargez et installez les symboles du système d’exploitation Windows. Pour cela, procédez comme suit :
Notes
Des symboles sont nécessaires pour analyser le fichier de vidage. L’échec de l’installation des symboles est le problème de configuration de test le plus courant qui provoque l’échec de ce test. La version des symboles doit correspondre à la version du système d’exploitation installée sur l’ordinateur de test. Par conséquent, il doit être téléchargé à l’extérieur du kit.
Sur un ordinateur disposant d’une connexion Internet, téléchargez les packages symboles Windows. Pour plus d’informations, consultez Télécharger les packages de symboles Windows.
Copiez les fichiers de symboles sur l’ordinateur de test dans le dossier C:\Symbols . Étant donné que les symboles peuvent être volumineux, il vous suffit de copier ntkrnlmp.pdb (pour x64 ou Arm) ou ntkrpamp.pdb (pour x86).
Dépannage
Pour la résolution des problèmes génériques des échecs de test HLK, consultez Résolution des échecs de test HLK Windows.
Pour plus d’informations sur la résolution des problèmes, consultez Résolution des problèmes de test Device.Storage.
Message d’erreur « Échec du chargement des symboles corrects » dans les journaux de test
Lors du redémarrage, le test examine le fichier de vidage pour déterminer s’il est correct. Le test effectue cette opération, comme le ferait un développeur, en utilisant le débogueur de noyau kd (voir Télécharger et installer les outils de débogage pour Windows). Pour analyser un fichier de vidage, le débogueur doit accéder aux symboles (voir Fichiers de symboles). Il s’agit d’un dictionnaire pour le vidage. Ils permettent au débogueur d’analyser le contenu de la mémoire (ou d’un fichier crashdump) dans des modules individuels (exécutables, bibliothèques, pilotes, etc.), des fonctions au sein de ces modules et des structures de données. En règle générale, si vous ne pouvez pas examiner le fichier de vidage à l’aide du débogueur du noyau, le test ne peut pas réussir.
Pour que le test fonctionne correctement, il doit fournir au débogueur des symboles. Lorsqu’il n’a pas de symboles appropriés, il enregistre les avertissements lors des échecs de journalisation pendant la première phase d’analyse du test. Pour ce faire, le mécanisme actuel consiste à télécharger des packages de symboles publics (voir Télécharger les packages de symboles Windows) et à les installer sur l’ordinateur de test avant d’exécuter le test. Lorsque les symboles ne sont pas installés ou ne correspondent pas au système d’exploitation testé, le message suivant peut apparaître dans le journal des tests :
(x) Échec du chargement des symboles corrects.
(i) Reportez-vous à la documentation WDK pour savoir comment installer des symboles de système d’exploitation.
(i) Vos symboles peuvent également être obsolètes. Veuillez les mettre à jour à l’aide du serveur de symboles Microsoft.
Ce message ne provoque pas réellement l’échec du test, car dans certains cas, le vidage peut toujours être analysé avec des symboles partiellement correspondants. Si le test se poursuit et que d’autres cas de test échouent avec des messages tels que Erreur lors de la récupération des adresses de ... ou Impossible d’obtenir..., cela signifie que le débogueur ne peut pas analyser le vidage en raison de symboles manquants. Une façon de contourner un symbole consiste à compléter le symbole installé localement avec des symboles mis en cache à partir d’un serveur de symboles Internet. Procédez comme suit pour mettre en cache les symboles localement :
Vérifiez que vous avez déjà créé un crashdump. Le moyen le plus simple consiste à exécuter le test une seule fois et à le laisser échouer.
Vérifiez que les outils de débogage sont installés. Là encore, le moyen le plus simple consiste à exécuter le test une fois. Il installe les outils sur les débogueurs C:\.
Ouvrez une invite de commandes avec des privilèges élevés.
Tapez la commande suivante
c:\Debuggers\kd -z c:\Windows\MEMORY.DMP -y SRV*C:\Symbols*http://msdl.microsoft.com/download/symbolsCela charge le vidage dans le débogueur du noyau en utilisant le magasin de symboles distant sur Microsoft et le répertoire local C:\Symbols comme magasin en aval pour mettre en cache les symboles.
Vérifiez que des symboles sont disponibles pour les fichiers de système d’exploitation tels que NTOSKRNL et NTDLL. Ces fichiers sont nécessaires pour analyser le vidage. Il est correct si des erreurs apparaissent lors du chargement des symboles pour d’autres modules, tels que des pilotes tiers.
Vous devez maintenant avoir une invite 0: kd>. À cette invite, tapez la commande .reload /f. Cette commande force le débogueur à charger et mettre en cache tous les symboles des modules chargés dans le vidage.
Pour quitter le débogueur, appuyez sur Ctrl+B , puis sur Entrée.
Message d’erreur des journaux de test « La taille du fichier de pagination est trop petite à des fins de vidage complet »
En cas d’incident, il n’existe aucune certitude quant aux parties du système d’exploitation qui seront toujours fonctionnelles. Les pilotes réseau ou de système de fichiers ont peut-être provoqué l’incident ; par exemple, empêcher l’accès aux structures de système de fichiers pour créer un fichier de vidage ou le réseau pour stocker le fichier à distance. Le système d’exploitation gère cela à l’aide d’un fichier dont il sait déjà qu’il existe (le fichier page) et écrit directement dans les extensions de blocs logiques de ce fichier sur le disque. Le processus de vidage écrit le contenu de la mémoire physique dans le fichier page sur le disque système (généralement c:\pagefile.sys). Le fichier page doit être suffisamment volumineux pour contenir le vidage. Le plus grand vidage est un vidage complet, qui nécessite la taille de la mémoire physique (par exemple, 4096) plus un mégaoctet supplémentaire pour contenir les informations d’en-tête. Le test nécessite que l’utilisateur configure le fichier de page à une taille appropriée avant l’exécution. Si la taille du fichier de page est insuffisante, le test journalisera l’erreur suivante pendant la phase d’initialisation :
(i) Vérification de la taille du fichier de pagination.
(x) La taille du fichier de pagination est trop petite pour un vidage complet.
(i) Taille du fichier de pagination : 330989568
(i) Taille de la mémoire physique : 1073094656
(i) Configurez la taille minimale du fichier de pagination sur la taille de ram physique + 1 Mo.
Je vois l’erreur d’arrêt du système (écran bleu), mais le code de vérification de bogue n’est pas E2
Après une validation des paramètres de base, le test installe un pilote utilisé pour bloquer le système et redémarrer le système. Après le redémarrage, le test modifie les paramètres de contrôle d’incident (pour le vidage de la mémoire complète), supprime tous les anciens fichiers de vidage et bloque le système. Au moment de l’incident, le système affiche un écran de vérification des bogues (écran bleu) avec des détails sur la nature de l’incident. Le type de vérification de bogue doit être MANUALLY_INITIATED_CRASH (e2). Si autre chose s’affiche ici, cela signifie qu’une deuxième vérification de bogue s’est produite pendant le processus d’écriture du fichier de vidage. Pour ce faire, connectez un débogueur de noyau au client de test et déboguez le pilote de l’adaptateur de stockage.
Le message d’erreur des journaux de test « Le fichier de vidage est utilisé par un autre processus. HRESULT : 0x80070020 »
Une fois le fichier de vidage écrit, la machine de test doit redémarrer automatiquement. Au démarrage après un incident, le système d’exploitation détecte la présence d’informations de vidage dans le fichier de page et commence le processus d’écriture d’un vidage. Ce processus se produit de manière asynchrone pendant le démarrage de l’ordinateur et même après que l’utilisateur s’est connecté. Au cours de ce processus, vous pouvez afficher la progression en vérifiant la taille du fichier de vidage (C:\windows\memory.dmp) ou en affichant le processus dans le gestionnaire des tâches (werfault.exe). Le test s’exécute souvent en même temps que ce processus, essayant d’accéder au même fichier de vidage. Si cela se produit, les messages suivants s’affichent dans le journal :
(i) Connexion à DumpFile : C:\Windows\MEMORY. DMP
(i) Le fichier de vidage est utilisé par un autre processus. HRESULT : 0x80070020
(i) Habituellement, memory.dmp est toujours en cours d’écriture en raison d’une ram importante, réessayez après 5 minutes.
Le test doit ensuite réessayer d’accéder au fichier. Si le code du message d’erreur est différent ou s’il change (par exemple, 0x80070002 : ERROR_FILE_NOT_FOUND), cela signifie que le fichier n’a pas pu être écrit sur le disque. Le journal des événements système est le premier endroit pour case activée d’informations de débogage précieuses. Pour afficher le journal des événements, cliquez sur Démarrer, sur Exécuter, puis tapez Compmgmt.msc. Dans la fenêtre gestion de l’ordinateur, sélectionnez Gestion de l’ordinateur\Outils système\observateur d'événements\Système. Parcourez la liste des événements d’un événement qui a la source BugCheck. La cause la plus courante d’un fichier de vidage manquant est l’espace libre insuffisant sur le disque. La clé de RegistreHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash contient des informations sur le dernier incident (avant un redémarrage), y compris le fichier de vidage partiel s’il en a été créé. Cela peut être utile lors de la tentative de débogage d’autres problèmes de vidage manquants.
Plus d’informations
Crashdump est le mécanisme dans lequel le système d’exploitation appelle le pilote de l’adaptateur de stockage pour écrire le contenu de la mémoire dans un fichier de vidage après une erreur d’arrêt du système. En raison de la nature d’une erreur d’arrêt du système, le système d’exploitation ne peut pas faire d’hypothèses sur la stabilité du système. Par conséquent, très peu de services système sont disponibles pour les pilotes de stockage. Le test de prise en charge de Crashdump vérifie que le pilote de l’adaptateur de stockage peut toujours fonctionner dans ces environnements contraints et effectuer les E/S pour écrire correctement dans le vidage.
Le système d’exploitation Windows permet de générer trois types différents de fichiers de vidage de mémoire :
Complète
Noyau
Mini
Le test testera les types de fichiers de vidage Noyau et Mini. Pour plus d’informations sur ces types de fichiers de vidage, consultez Fichiers de vidage en mode noyau.
Le test effectue la séquence d’opérations suivante :
Installez Les outils de débogage pour Windows dans le répertoire %SystemDrive%\Débogueurs et initialisez le système.
Installez le pilote de test pour simuler un incident.
Définissez la taille du fichier de page.
Simuler des erreurs d’arrêt du système (écran bleu) avec le code de vérification des bogues 0x000000E2.
Redémarrez le système et redémarrez automatiquement le test.
Examinez le blocage précédent en analysant le fichier de vidage de mémoire via le débogueur du noyau, puis vérifiez que le vidage a été écrit correctement.
Répétez les étapes 4 à 6 pour chaque type de fichier de vidage.
Syntaxe de commande
| Commande | Description |
|---|---|
Crashdumptest.exe -c |
Effacez les échecs passés. |
crashdumptest.exe -dtm -y [SymbolsDirectory] -ypass |
Initialisez le test. |
crashdumptest.exe -autorun -y [SymbolsDirectory] -dtm » |
Exécute le test. |
Liste de fichiers
| Option de commande | Description |
|---|---|
Crashdumptest.exe |
[TestBinRoot]\nttest\driverstest\storage\wdk\ |
BugCheck.sys |
[TestBinRoot]\nttest\driverstest\storage\wdk\ |
Paramètres
| Nom du paramètre | Description des paramètres |
|---|---|
| DebuggerDirectory | Répertoire dans lequel installer les débogueurs. |
| SymbolsDirectory | Répertoire dans lequel les symboles sont déjà installés. |
| LLU_LclAdminUsr | Compte d’utilisateur pour l’exécution du test. |
| LLU_NetAccessOnly | Compte d’utilisateur pour accéder au partage de fichiers de test. |
| PagefileSize | Taille du fichier de page en Mo (prend en charge le format mem+N) |