Trace du noyau Windows 7 WinDbg

Question

Je ne reçois aucune information de débogage lors du débogage en_windows_7_checked_build_dvd_x86_398742. Je ne peux même pas voir mes propres informations de trace (ATLTRACE). À l'opposé, Windows XP Checked fonctionne comme un charme. Je reçois le message "Bad QueryIdType: 5" lors de la session de débogage avec Windows 7. Le débogage du noyau est correctement configuré. S'il vous plaît aider ...

Answer 1

OK, j'ai trouvé la solution here. Cela peut aider les gens:

Le problème: vos messages DbgPrint ou KdPrint n'apparaissent pas dans WinDbg (ou KD) lorsque vous exécutez votre pilote sous Windows Vista.

La raison? Vista mappe automatiquement DbgPrint et ses amis sur DbgPrintEx. Maintenant, vous pouvez rappeler que DbgPrintEx vous permet de contrôler les conditions dans lesquelles les messages seront envoyés au débogueur du noyau en filtrant les messages via un nom et un niveau de composant dans l'appel de fonction et un masque de filtre associé dans le registre ou en mémoire.

Dans Vista, DbgPrint et KdPrint sont mappés sur le composant "DPFLTR_DEFAULT_ID" et le niveau "DPFLTR_INFO_LEVEL". Bien sûr, dans Vista, la sortie xxx_INFO_LEVEL est désactivée par défaut. Donc, par défaut, votre DbgPrint/KdPrint n'est pas envoyé au débogueur du noyau.

Comment le réparer? Deux choix:

• Sortie de validation des messages DbgPrint/KdPrint par défaut --open la HKLM\SYSTEM\CurrentControlSet\Session Manager\Debug Print Filter clé. Sous cette clé, créez une valeur avec le nom DEFAULT Définissez la valeur de cette clé égale à la valeur DWORD 8 pour activer la sortie xxx_INFO_LEVEL ainsi que la sortie xxx_ERROR_LEVEL. Ou essayez de régler le masque sur 0xF pour obtenir toutes les sorties. Vous devez redémarrer pour que ces modifications prennent effet.

• Changez spécifiquement le mât du filtre de composant pour DPFLTR. Dans les premières versions de Vista/LH, vous avez modifié le masque d'impression par défaut en spécifiant une valeur de masque pour le DWORD à Kd_DPFLTR_MASK ("ed Kd_DPFLTR_MASK"). Dans build 5308 (le CTP Février de Vista), il semble que la variable de masque a changé et vous devez définir la valeur de masque pour le DWORD à Kd_DEFAULT_MASK ("ed Kd_DEFAULT_MASK) .Dans les deux cas, spécifiez 8 pour activer la sortie DPFLTR_INFO_LEVEL en plus à DPFLTR_ERROR_LEVEL sortie ou 0xF pour obtenir tous les niveaux de sortie

Consultez la documentation WDK pour la lecture des messages et filtrage de débogage (suivez le chemin. Outils de développement Driver \ Outils pour les pilotes de débogage \ Utilisation du code de débogage dans un pilote \ Présentation du code de débogage) pour obtenir tous les détails sur l'utilisation de DbgPrintEx/KdPrintEx ou consultez la documentation relative aux outils de débogage pour Windows (Annexe A) sur DbgPrintEx

Answer 2

j'ai pu le fixer à l'intérieur windbg, sur Windows 7 32 bits:

ed Kd_DEFAULT_Mask 8 

Selon l'article msdn, vous pouvez également utiliser le registre, mais vous devez redémarrer l'ordinateur pour qu'elle prenne effet. Créez une clé DWORD sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter appelée DEFAULT avec une valeur de 8.

La documentation à jour Microsoft est disponible ici: http://msdn.microsoft.com/en-us/library/windows/hardware/ff551519(v=vs.85).aspx

Answer 3

Pour activer la sortie des messages DbgPrint/KdPrint par défaut, le chemin de registre est "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Debug Imprimer le filtre" Le gestionnaire de session est sous le contrôle. La valeur par défaut est normalement 0xf. Cela active tous les messages. Pour définir un bitmask meilleur ajustement à vos besoins les informations sont situés à https://docs.microsoft.com/de-de/windows-hardware/drivers/devtest/reading-and-filtering-debugging-messages#identifying-the-component-name

Si vous prenez Visual Studio 2015 ou 2017, la configuration standard ne sera pas mis ce drapeau par défaut. Lorsque vous commencez à travailler avec des exemples, n'oubliez pas de définir ce supplément sur la cible de débogage. Cela m'a aidé dans mon environnement Windows 10 en utilisant Windbg.

Un deuxième problème utilisait devcon sur Windows 10 comme décrit dans l'exemple écho https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debug-universal-drivers---step-by-step-lab--echo-kernel-mode-#install

A Bullet « 7 Localisez les fichiers de pilote intégré » transférer les fichiers de pilotes nécessaires à la Debug-cible et de les charger avec devcon . Avec Windows 10, vous devez également copier le catalogue-fichier. Sinon, devcon.exe échouera comme décrit. De ce fait, vous devrez également installer le certificat de test. Cela est généralement effectué lors de la préparation de l'environnement de débogage avec Visual Studio 2015/2017. Juste vérifier avec certmgr.