Quel outil puis-je utiliser pour intercepter toutes les entrées qui provoquent le blocage d’une application?

J’ai besoin d’un outil Windows qui enregistre les entrées et les informations de débogage qui provoquent la panne du programme. Je ne parle pas d’un logiciel de fuzzing ! Par exemple, permettez-moi de décrire un scénario pour expliquer ce dont je parle.

Parfois, lors de l’utilisation d’un programme, il ne fonctionnera pas sans raison connue et lorsque je veux le déboguer, je ne trouve pas d’informations utiles pour savoir comment le plantage s’est produit car les données à l’origine du plantage n’existent plus nulle part.

J’ai donc besoin d’un outil enregistrant toutes les entrées et informations de débogage pour pouvoir réutiliser les données d’entrée et reproduire le crash sous un débogueur comme Immunity Debugger et OllyDbg afin de comprendre comment le crash s’est produit.

EDIT: Je dois être capable de faire cela pour un programme que je n’ai pas écrit. Supposons que je n’ai pas access à l’affichage ou à la modification de son code source.

Quel compilateur / IDE utilisez-vous?

Les chances sont, il inclut un débogueur que vous pouvez attacher à n’importe quel processus en cours d’exécution (comme votre application), que vous l’ayez démarré à partir de l’EDI ou non. Cela vous permettra de voir les valeurs actuelles des variables et de vous présenter une trace de stack (ou des informations de diagnostic utiles) à chaque fois que votre programme plante de manière inattendue. Le débogueur fourni avec Visual Studio est particulièrement utile si vous développez une application C ++ ou .NET.

Une autre option consiste à implémenter une fonctionnalité de journalisation étendue dans votre application. Vous pouvez écrire des informations détaillées sur l’état actuel du programme à intervalles réguliers dans un fichier ou dans le journal des événements Windows, puis examiner ces informations après une panne. Cela est particulièrement utile si vous essayez de déboguer des erreurs qui se produisent sur le site d’un client car elles peuvent simplement vous envoyer le fichier journal à parsingr.

Si vous parlez d’enregistrer un ensemble particulier d’entrées utilisateur provoquant le blocage de votre application, la journalisation est probablement la meilleure option.

Vous pouvez utiliser certaines bibliothèques de journalisation pour faciliter ce travail. Sans savoir dans quelle langue vous travaillez, il est difficile de formuler des recommandations spécifiques. Par exemple, si vous développez une application .NET, Log4Net est un excellent choix . J’ai entendu de bonnes choses sur le développement de Log4j pour Java. log4cxx est une option pour les applications C ++. Voir également cette question concernant les meilleures pratiques .

Je suppose que la trace de la stack doit vous aider à déboguer le problème. Vous pouvez utiliser

vent

Debugdiag

outil pour obtenir les vidages sur incident. J’ai trouvé cela vraiment utile

Vous avez dit que vous devez déboguer un code que vous n’avez pas écrit sans code à afficher.
D’après mon expérience, ce n’est pas si facile mais …
Vous pouvez configurer drwtsn32, si toujours présent sur vous, pour écrire des fichiers de sortie lorsque le programme se bloque.

L’ancienne sortie stylisée est drtwsn32.log (la version Windows de NT 4.0 à Windows 7 place ce fichier dans un emplacement différent sur le disque, recherchez simplement ce fichier) qui vous donne la trace de la stack, des registres et un petit nombre de vidages de mémoire. Acutellement, vous devriez avoir le fichier .map du programme original afin d’identifier la fonction qui plante et même la ligne de code dans laquelle les plantages se produisent (il y a une méthode pratique que j’ai utilisée il y a longtemps … mais vous avez besoin d’une fichier MAP complet).

Une version plus récente de drwtsn32 produit un ensemble de fichiers. Ils sont

appcompat.txt
manifest.txt
programme .exe.hdmp
programme .exe.mdmp

Ils sont mémoire et processus de vidage. Ouvrez-le avec un IDE / Debugger Microsoft en tant que Visual Studio 2008/2010 et consultez.
Il affiche la stack d’appels complète, l’état de la mémoire, tous les registres, etc. Si vous avez aussi le fichier .pdb du programme qui plante, vous devriez être capable de savoir quelle est la fonction et la ligne de code mais … sans fichier source vous vous trouvez dans l’obscurité, je suppose.

Donc … le fichier MAP ou le fichier PDB devrait être présent ou je pense que vous allez avoir un travail très dur.

HTH