Après avoir omis d'obtenir Les fichiers de dépôt de collision ont été créés sur une zone Windows Server 2016, exécutant mon application Web ASP.NET 4.5.2 sur IIS-10. Mon application Web ASP.NET contient plusieurs composants 3ème partie, avec leurs DLL individuelles.
J'ai copié les fichiers de décharge de collision sur ma machine de développement Windows 10 et utilisez WINDBG localement plutôt que sur le serveur.
Le problème est ... lorsque je manette Je couronne WINDBG sur la même machine que j'ai construit le site Web en premier lieu ... y a-t-il donc une façon de dire WINDBG qu'il peut trouver la DLL dans un endroit particulier sur la machine locale ?
I évidemment, je n'ai évidemment pas de fichier Quelqu'un peut-il me dire dans la bonne direction? Debugdiag pour analyser le crash -Dachets Il a été suggéré d'essayer d'utiliser windbg à la place.
! analyser -v dans Windbg sur l'un des fichiers de décharge de collision, il est efficacement suspendu lors de "Téléchargement de fichier xxx. Dll "(xxx.dll étant le nom d'une seule des DLL de composants tiers) et éventuellement s'ensuivre après une période de temps.
.pdb pour l'un des composants tiers, et donc je ne suis pas dérangé par le chargement des symboles pour ces dlls ... mais je dis en quelque sorte Il convient d'ignorer ces DLL particulières, ou je lui dis comment les trouver localement.
3 Réponses :
Vous n'avez pas à analyser le fichier de vidage avec! Analyze -V. Si vous devez charger la DLL, alors .chargez D: .... est suffisant.
à Maunal Analyser un fichier de vidage. Veuillez exécuter .Loadb SOS CLR pour charger le module de débogage. Si le serveur de crash et votre machine exécutent une version différente de .NET Framework. Ensuite, vous devez charger sos.dll manuellement.
Lorsque vous devez déboguer l'application .NET dans IIS, l'extension MEX est recommandée. https://www.microsoft.com/en-us/ Télécharger / Détails.aspx? Id = 53304
Vous pouvez charger MEX.DLL via .load 1.Vous pouvez utiliser 2.then aller à ce fil via 3.Run c: \ \ \ mex.dll
! MEX.ASPXPAGES peut afficher toutes les demandes à l'intérieur du processus et de leur processus
! meex.mthreads Affiche l'état de tous les threads
! MEX.CLROSTACK2 affiche toutes les exceptions et la pile d'appels manager dans un thread spécifique.
~ * k pour charger la pile d'appels complète dans tous les threads et ! MEX.MTHADES Vérifier l'état.
Ensuite, vous pouvez trouver quelque chose comme kernelbase! RaiseeeException dans un thread spécifique
threadid ~ comme 12 ~
! MEX.CLROSTACK2 et il montrera l'exception de crash
si vous devez charger la DLL, alors .chargez D: ..... est suffisant. - qui ne chargera pas de DLL, il chargera une extension Windbg.
La majorité de votre réponse n'a rien à voir avec mon problème ... Je ne débrouge pas directement IIS, soit localement ni à distance. Je télécharge les fichiers de crash sur ma machine locale
Fondamentalement, non, vous ne pouvez pas accélérer le processus de chargement de symboles pour les DLL où vous n'avez pas de symboles. IMHO, la seule façon d'accélérer le processus de symbole serait de désactiver le serveur HTTP, de sorte que les symboles ne soient recherchés que sur votre disque local.
Voir aussi: Comment configurer des symboles dans Windbg si Vous n'avez pas fait cela souvent.
Obtenir un http 404 pour que ces fichiers ne devraient pas prendre très longtemps. Cependant, il essaie divers fins de fichiers et des pointeurs, etc. Parfois, les serveurs Microsoft sont lents. En outre, avoir beaucoup de DLL 3ème partie peut résumer bien sûr. Cela peut être assez anode.
La désactivation du serveur HTTP a du sens, mais je pense que je le faisais effectivement, en exécutant l'application via une ligne de commande avec WINDBG -Y C: \ WINDBG \ symboles . Heureusement, j'ai réussi à comprendre que le débordement de la pile a été causé par un composant 3ème partie particulier sans utiliser le ! Analyser -v
@FreeFalder: Oui, définissez-le comme ça avec -y doit désactiver les serveurs de symboles HTTP
Je vais commencer par dire que je ne comprends pas à 100% tout ce que je devais faire, mais voici le pas que j'ai pris pour découvrir où le problème de Stackoverflow était dans ma demande ...
Vous n'avez pas vraiment besoin de
! Analyser -v pour une application .NET Framework, comme cela est principalement utilisé pour les crash indigènes et les autres. Naviguez sur les threads gérés et vérifiez leurs piles d'appels, et le coupable devrait être clair. Des astuces peuvent être trouvées dans les messages comme Dougrathbone.com/blog/2014/03/20/...Merci encore pour votre aide @lex (transformant mon assistant personnel) ... et merci pour le billet de blog. Je continuerai à enquêter
@Lex - pris un moment, mais j'ai finalement suivi la question à une composante 3ème partie spécifique. Merci encore pour le blog post, c'était vraiment utile
Vous pouvez résumer ce que vous avez appris comme une réponse et acceptez-le. .NET Dump Analyse est en fait facile pour certains scénarios (comme la vôtre), alors une fois que vous maîtrisez les étapes de base, vous pouvez conquérir des plus gros dans le futur.
@Lex - a finalement trouvé du temps pour écrire une réponse. Je suis sûr qu'il y a beaucoup de trous dans mes méthodes, mais il est précis quant à la façon dont j'ai réussi à le faire