Analyser la décharge de crash dans Windbg

Cela se produit généralement lorsqu'un client appelle Createfile pour un tuyau existant et toutes les instances de tuyau existantes sont occupées. À ce stade Createfile renvoie une erreur et le code d'erreur est error_pipe_busy. La bonne chose à ce stade est d'appeler Watinamedpipe avec une valeur de délai d'attente pour attendre qu'une instance de tuyau devienne disponible.

Le problème se produit généralement lorsque plusieurs clients tentent de se connecter au tuyau nommé en même temps.

Je suppose que la DLL 3ème partie est indigène (sinon, utilisez simplement un réflecteur)

Avant d'utiliser WINDBG pour analyser la décharge, essayez d'utiliser Process-Monitor (Sysinternals, Freeware) pour surveiller l'activité de votre processus. Si cela échoue à cause d'un problème connexe du système de fichiers, vous pouvez voir exactement ce qui a causé le problème et ce qu'il a essayé exactement de faire avant d'échouer.

Si le moniteur de processus ne suffisait pas que vous pouvez essayer de déboguer votre processus. Mais pour voir des informations significatives sur la DLL de la tierce partie, vous aurez besoin de la PDB.

Après avoir défini les symboles de débogage corrects, vous pouvez afficher la pile d'appels en utilisant la commande K ou l'une des variantes de ce qu'elle (à nouveau, je suppose que vous parlez de code natif). Si votre processus se bloque effectivement à cause de cette DLL que d'examiner les paramètres que vous transmettez à sa fonction pour vous assurer que le problème n'est pas de votre côté. Je suppose que cela davantage sur la pile d'appels, vous atteignez une API Win32 - examinez les paramètres que la fonction de la DLL passe, essayant de voir si quelque chose "sent". Si vous avez le symbole privé de la DLL, vous pouvez examiner également les variables locales de la fonction également (DV) qui peut vous donner plus d'informations.

J'espère que je vous ai donné un bon point de départ.

Il s'agit d'une excellente ressource pour utiliser WINDBG pour analyser des accidents pouvant être utilisés: http://www.networkworld.com/article/3100370/windows/how-to-solve-windows-10-Crashes -en-moins que-a-minute.html

L'article est destiné à Windows 10, mais il contient des liens vers des informations similaires pour les versions antérieures de Windows.

Dans le débogage de PostMortem avec WINDBG, il peut être utile d'exécuter quelques commandes de diagnostic générales avant de décider où creuser plus profondément. Celles-ci devraient être vos premières étapes: xxx

Ces commandes vous donnent généralement un aperçu de ce qui s'est passé afin que vous puissiez creuser davantage. Dans le cas de la gestion des bibliothèques où vous n'avez pas de source, l'envoi du fichier journal résultant au fournisseur avec le numéro de construction de la bibliothèque binaire devrait être suffisant pour les retrouver à un problème connu s'il y en a un. < / p>

Vous pouvez commencer à faire comme suit pour obtenir un aperçu de l'exception:

kb     ;will show you the stack trace of the crash.
dv     ;local variables