La meilleure réponse est: non. Il existe déjà un système permettant de faire cela directement dans le système d'exploitation. Si vous laissez les exceptions sortir du programme, les systèmes d'exploitation modernes incluent le rapport d'erreurs Windows, qui permet à l'utilisateur d'envoyer un rapport d'erreurs à Microsoft. (pas envoyer des rapports d'erreur automatiquement - réfléchir longuement aux ramifications légales concernant les lois sur la confidentialité ...)
Le rapport d'erreurs inclut non seulement les informations d'exception et la trace de pile complète, mais inclut également une bonne partie de la mémoire de votre processus, ainsi que exactement quels modules OS ont été chargés (de sorte que vous pouvez même dire si le correctif Windows Update pertinent a été appliqué). Il encapsule toutes ces informations dans un fichier minidump (et inclut également quelques fichiers XML avec des informations supplémentaires).
Ce rapport d'erreurs est téléchargé sur les serveurs de Microsoft, vous n'avez donc pas à vous inquiéter de la configuration et de la maintenance d'un serveur "d'appel". Tous les rapports d'erreurs pour vos programmes sont catégorisés en utilisant des heuristiques avancées dans des «compartiments», chaque «compartiment» contenant des rapports susceptibles d'être causés par le même bogue.
Microsoft vous expose toutes ces informations (en tant qu'éditeur de logiciels) via un site appelé Winqual. À l'aide de Winqual, vous pouvez examiner tous les rapports d'erreurs et utiliser leurs algorithmes de recherche heuristique pour déterminer quels bogues ont le plus d'impact sur vos clients. Vous pouvez également télécharger chaque rapport individuel pour une analyse plus détaillée.Si vous avez un serveur de symboles et un serveur de contrôle de source configurés dans votre organisation (et vous le devriez certainement), vous pouvez simplement charger le minidump à partir d'un rapport d'erreur téléchargé directement dans Visual Studio, et il vérifiera automagiquement l'ancien source hors du contrôle de la source et vous permettent d'inspecter l'état exact du programme au moment où il s'est écrasé.
Trouver et réparer des bogues n'a jamais été aussi simple.
Pour résumer, voici ce que vous devez faire:
- Mettre en place un symbol server et un serveur source dans votre organisation. Établissez une stratégie de publication pour vous assurer que toutes les versions obtiennent source-indexed pdbs ajouté au serveur de symboles avant d'être mises à la disposition du client.
- Établissez un compte avec Winqual. Vous aurez besoin d'un certificat de signature de code Authenticode; Si vous obtenez un certificat de signature de code autre que VeriSign, vous devrez également débourser 100 $ pour un «certificat d'organisation» auprès de VeriSign.
- Modifiez votre stratégie de publication pour inclure la création de fichiers de mappage pour vos versions. Ces fichiers de mapping sont téléchargés sur Winqual avant l'expédition de la version.
- Ne pas attraper des exceptions inattendues. Si vous avez besoin de les attraper, assurez-vous de les relancer en utilisant
throw et non throw ex, afin que la trace de la pile et l'état du programme original soient conservés.
Pour plus d'informations, je peux recommander fortement Debugging .NET 2.0 Applications par John Robbins. Malgré le "2.0" dans le titre, ce livre est toujours tout à fait pertinent aujourd'hui (sauf que le seul exemple de serveur source utilise Visual SourceSafe, qui était une blague complète même à l'époque). Un autre bon livre si vous devez faire beaucoup de débogage est Advanced .NET Debugging, bien qu'il commence à montrer son âge, d'autant plus que les nouvelles avancées de débogage VS2010 rendent beaucoup de ses techniques obsolètes.
@ 0xA3 - corrigé .. merci. – Gishu