J'ai un service Windows qui, par intermittence, lance une exception qui tue parfois sa SQLConnection, et d'autres fois tue complètement le service. Il fonctionne en direct sur le site d'un client.Windbg avec SOS, arrêt sur la bonne exception
J'ai prévu d'utiliser Windbg + SOS dessus pour obtenir un vidage sur incident, afin que je puisse déboguer cela à loisir.
Lors de ma première tentative, cependant, le débogueur a arrêté le service lorsqu'il a rencontré une exception de première chance qui était interceptée et gérée dans le code (comme j'ai utilisé la commande sxe clr).
Le fichier d'aide semble suggérer que j'utilise sxd clr, au lieu de sxe clr, pour capturer des exceptions de seconde modification au lieu d'exceptions de première chance.
Lors de mes tests, cependant, une exception générée, interceptée et gérée est traitée exactement comme une exception lancée (mais non interceptée) par la commande sxd clr, à savoir elle est notée et ignorée.
Est-ce que ce comportement consiste à ne pas s'arrêter sur une exception levée, probablement parce que j'ai jeté l'exception explicitement dans mon code ou toutes les exceptions clr échouent-elles à arrêter le débogueur avec la commande sxd? Dois-je utiliser une commande différente?
En second lieu, Windbg ne pas spécifiquement reconnaître les erreurs clr, est-il possible de le dire d'arrêter que sur un spécifique, non gérée, exception (c.-à-InvalidOperationException)
Merci, je vais vérifier – johnc
Gardez à l'esprit que adplus.vbs a été remplacé par adplus.exe dans la dernière version de WinDbg. J'ai eu quelques problèmes avec la nouvelle version, donc vous devrez peut-être utiliser l'ancienne version, qui est toujours incluse (renommée en adplus_old.vbs). –
Merveilleux, merci – johnc