Comment puis-je arrêter le programme avant de charger l'une des dlls liées?
J'ai essayé de définir Loadlibraryexw code> Fonction dans la fonction Casser en fonction CODE> Option de débogage et Il s'arrête à cette fonction, mais avant que j'aie ce qui suit dans Visual Studio Sortie Windows: P>
'test.exe': Loaded 'C:\Windows\System32\ntdll.dll', Symbols loaded (source information stripped).
'test.exe': Loaded 'C:\Windows\System32\kernel32.dll', Symbols loaded (source information stripped).
'test.exe': Loaded 'C:\Windows\System32\KernelBase.dll', Symbols loaded (source information stripped).
'test.exe': Loaded 'C:\Windows\System32\uxtheme.dll', Symbols loaded (source information stripped).
'test.exe': Loaded 'C:\Windows\System32\msvcrt.dll', Symbols loaded (source information stripped).
---- plus about 30 DLLs ---
7 Réponses :
Au lieu de commencer avec F5, commencez simplement à déboguer avec F11 ou F10.
Dans ce cas, il s'arrête à la fonction après que toutes les DLL ont été chargées et après l'initialisation de tous les objets statiques.
ntdll.dll est chargé par le noyau lors de la création de processus. Je ne connais pas les autres dll spécifiquement, mais ils sont très probablement chargés par le noyau.
Autant que je sache, ce que vous essayez de faire ne peut pas être fait, à moins que vous ne deviez écrire un rootkit pour écraser une partie du code de création de processus. Même dans ce cas, je ne sais pas si le processus créé est vraiment considéré comme un processus avant que ces bibliothèques soient chargées.
Je ne pense pas que vous puissiez le faire avec le débogueur habituel en mode utilisateur dans Visual Studio. Microsoft fournit une boîte à outils gratuite d'autres outils de débogage, notamment KD (Kernel Debugger) et WINDBG, pouvant pouvoir interrompre le chargement, mais je doute que vous puissiez jamais inspecter le processus avant de charger NTDLL. Ce n'est pas vraiment un processus à ce moment-là.
Qu'essayez-vous d'accomplir?
Il n'y a aucun moyen de le faire car les DLL que votre exécutable PE dépend de SONT chargé par système (pas par votre processus) avant la création du processus. Le processus ne commence que lorsque votre exécutable est liée à toutes les fonctions importées d'autres DLL.
Vous pouvez le faire en ajoutant une clé de registre aux "Options d'exécution des fichiers image" avec le nom de votre exe. Ajoutez une valeur de type chaîne nommée «débogueur» et définissez-la sur vsjitdebugger.exe pour lancer la boîte de dialogue de débogueur juste à temps. Ce qui vous permet ensuite de choisir l'un des debuggers disponibles, y compris Visual Studio. Cette boîte de dialogue est déclenchée juste après que Windows a chargé l'EXE, avant que tout code ne commence à exécuter.
Voici est un exemple de fichier .reg qui déclenche la boîte de dialogue lorsque vous démarrez NOTEPAD.EXE. Modifiez le nom de la clé à votre .exe:
J'ai essayé cet explorateur et le processus explorateur me montre que le processus a déjà alloué environ 30 objets GDI à ce stade déjà. Mais à ce moment, c'est le meilleur que je puisse obtenir.
Vous pouvez utiliser l'outil Gflags à partir du kit Windows Debugger Modifier facilement le registre automatiquement pour vous. Il se trouve dans les outils de débogage de Windows chez msdn.microsoft.com /en-us/windows/hardware/ggg463009.aspx comprend également de nombreux autres outils de débogage utiles, y compris WINDBG, gratuitement de Microsoft.
Utilisation de gflags and Windbg, vous pouvez automatiquement joindre à votre application cible et définir un point de rupture avant que toutes les DLL soient chargées.
Pour ce faire, vous aurez besoin des "outils de débogage de Windows" installé. Vous pouvez obtenir cela gratuitement de Microsoft. Il comprend des gflags et de la runbg. Vous pouvez le trouver à: http://msdn.microsoft.com/en-us/windows/hardware /ggg463009.aspx
Utilisez GFLAGS pour définir les options de débogage automatique de votre programme cible. C'est le moyen le plus simple de définir votre système pour démarrer un débogueur qui sera automatiquement démarré lorsque la demande cible commence. Pas besoin de vous tromper avec le registre, il apportera tous les changements nécessaires pour vous.
Utilisez des gflags pour définir WINDBG pour être démarré comme le débogueur. Modifiez les filtres d'événement pour Windbg sur l'événement "Créer un processus" de "Ignorer" sur "Activé". Par défaut, Windbg ne casse pas sur la création de processus de votre cible. Mais si vous avez besoin ou si vous souhaitez définir un point de rupture sur Create Process, vous pouvez en modifier cette option d'événement. Le moyen le plus simple de modifier cette option est de télécharger votre candidature sur votre application, d'utiliser son interface graphique pour modifier l'option via l'élément de menu «Debug | Event ...» et sa boîte de dialogue, enregistrez votre espace de travail et arrêtez de débuter. Ensuite, commencez tout ce qui conduit à votre application cible à partir, et à partir de ce moment-là pour cette cible de débogage particulière, Windbg va rompre sur "Créer un processus".
Il existe d'autres moyens de définir cette option automatiquement dans WindDBG, mais ils ne sont pas aussi simples que l'utilisation de son interface graphique. Vous pouvez définir les options de ligne de commande pour son invocation pour activer l'événement Create Process. Vous pouvez utiliser Windbg Exécuter un fichier de script qui définira l'option pour vous. Vous pouvez définir la variable d'environnement des outils de WINDBG pour le signaler à son fichier "Outils.ini" et activer l'événement Create Process. Et il y a quelques méthodes supplémentaires pour définir l'option d'événement pour activer un point de rupture sur Créer un processus.
Le lien ci-dessus comprend des liens de débogage de l'aide avec Gflags et Windbg.
Pour la plupart des besoins de débogage, les développeurs n'ont pas besoin ou ne veulent pas de point de rupture à la création de processus (avant que toutes les DLL normales et de base nécessaires à exécuter sont chargées). Mais si vous faites, WINDBG et plusieurs autres débuggeurs gratuits fournis par Microsoft peuvent le faire. Il vous suffit de modifier la valeur par défaut pour cet événement d'ignoré à activé.
Un moyen de casser très tôt est d'ajouter manuellement un point d'arrêt de fonction sur ldrinitializéch . Cela ne casse pas avant NTDLL, mais devrait être avant toute inipalisation statique ou code utilisateur