Comment déboguer w3wp clr.dll erreur

Mon client a une ASP.NET application installée sur deux serveurs de production (équilibré avec équilibrage de charge réseau, mais c'est sans importance).
Les deux serveurs crash toutes les 3 à 4 heures à la suite de l'observateur d'événements d'erreur enregistré:

Défaillant nom de l'application: w3wp.exe version: 7.5.7601.17514, horodatage: 0x4ce7afa2

Nom du module défaillant: clr.dll version: 4.0.30319.18034, horodatage: 0x50b5a783

Code d'Exception: 0xc00000fd décalage d'erreur: 0x000000000001a840

Id du processus défaillant: 0xd50

Application défaillante heure de début: 0x01ce97fe076d27b4

Défaillant chemin de l'application: c:\windows\system32\inetsrv\w3wp.exe

Chemin d'accès du module défaillant: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Id de Rapport: e0c90a5f-0455-11e3-8f0e-005056891553

Je n'ai aucune idée de comment déboguer ou par où commencer. Lorsque l'accident est sur le point de se passer de l'utilisation du processeur de serveur saute à 100% et y reste. Le processus fautif est w3wp.exe. Je ne suis même pas sûr si mon code est la génération de l'erreur ou non. C'est IIS 7.5. Tous les pointeurs serait grandement apprécié.

InformationsquelleAutor cristi71000 | 2013-08-20
  1. 66

    Il semble que vous avez un StackOverflow Exception, qui est causée par la surabondance de la récursivité (à plusieurs reprises une fonction appelant elle-même, etc). Ce ne peut pas être attrapé par la régularité de bloc try/catch. Vous pouvez localiser le problème à l'aide de DebugDiag et WinDbg.

    DebugDiag peut être configuré pour générer un fichier de vidage sur incident lors de la StackOverflowException se produit. Télécharger au https://www.microsoft.com/en-us/download/details.aspx?id=49924.

    1. Ouvrir DebugDiag et cliquez sur Ajouter une Règle.
    2. "Crash" est déjà sélectionné. Cliquez Sur Suivant.
    3. Choisir "Une application web IIS piscine" et cliquez sur Suivant.
    4. Sélectionnez le pool d'applications et cliquez sur Suivant.
    5. Vous devriez être sur la Fenêtre Configuration Avancée. Cliquez sur Exceptions sous Paramètres Avancés.
    6. Cliquez sur Ajouter une Exception et choisissez Débordement de Pile, avec une Action de Type de Userdump Complet
    7. Cliquez sur OK et enregistrez et fermez.

    Prochaine fois qu'un StackOverflowException se produit, vous aurez un fichier de vidage sur incident. Maintenant, à la nécessité d'interpréter le fichier de vidage.

    Outils de débogage pour Windows est une partie du kit de développement logiciel Windows et peut être téléchargé à l' http://msdn.microsoft.com/en-US/windows/hardware/gg463009/.

    1. À utiliser WinDbg, vous aurez besoin d'obtenir les symboles des fichiers. Télécharger les fichiers de symboles et les mettre dans un dossier local.
    2. Ouvrir WinDbg. Dans le menu Fichier, cliquez sur le Symbole Chemin d'accès au Fichier.
    3. Dans la zone chemin d'accès, la documentation dit de taper la commande suivante: SRV*your local folder for symbols*http://msdl.microsoft.com/download/symbols, cependant je viens de mettre dans le dossier local pour les symboles et il a bien fonctionné.
    4. Sortir et ouvrir WinDbg de nouveau, et d'Ouvrir de Vidage sur incident et de localiser le fichier de vidage qui a été créé par DebugDiag.
    5. Dans la ligne de commande, tapez .loadby sos clr
    6. Maintenant type !CLRStack

    Dans les résultats, il devrait être clair que le problème est (vous l'aurez probablement voir un TAS de lignes montrant les fonction(s) qui a été à plusieurs reprises d'être appelé).

    • Question connexe: stackoverflow.com/questions/6019674/...
    • J'ai essayé cette, pris un cliché, a obtenu certains symboles de débogage et maintenant j'ai l'erreur suivante lors du chargement de la décharge: *** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll - This dump file has an exception of interest stored in it. The stored exception information can be accessed via .ecxr. ...*** ERROR: Symbol file could not be found. Defaulted to export symbols for clr.dll - *** WARNING: Unable to verify checksum for mscorlib.ni.dll *** ERROR: Module load completed but symbols could not be loaded for mscorlib.ni.dll
    • Oups, my bad, maintenant je l'ai chargé de vidage avec aucune erreur, mais quand je fais"!CLRStack' il dit "Échec du chargement de l'accès aux données DLL"
    • Enfin réussi à le faire fonctionner. Malheureusement, la pile d'appel est inutile: OS Thread Id: 0xdd0 (42) Child SP IP Call Site 0000000011b1ef48 000007fef7a5c91b [GCFrame: 0000000011b1ef48] 0000000011b1ef88 000007fef7a5c91b [ContextTransitionFrame: 0000000011b1ef88] 0000000011b1efc8 000007fef7a5c91b [GCFrame: 0000000011b1efc8] 0000000011b1f1b0 000007fef7a5c91b [ComMethodFrame: 0000000011b1f1b0]
    • Hmmm... la taille de votre fichier de vidage? Le mien était énorme (+de 100 MO) et les commandes .loadby sos clr et puis !CLRStack a fallu un certain temps pour charger et de sortie d'un grand nombre de données.... le défilement à travers elle m'des centaines d'appels à la fonction même qui m'a montré où trouver de la récursivité. Vous pouvez également être en mesure d'ouvrir le fichier dans visual studio.
    • Le cliché a été de 1,5 GO :). J'ai d'abord analysé avec le debugdiag de l'analyseur et ensuite, j'ai utilisé windbg. DebugDiag m'a montré une énorme pile d'appel, mais il ne montre des adresses de mémoire. En effet, l'un d'eux a été appelé des centaines de fois. Dans tous les cas, toute trace de la pile est dans le clr.dll. Je suis de plus en plus convaincu qu'il existe aujourd'hui un clr.dll erreur qui est déclenché par un certain comportement dans notre code. Peut-être une collecte des ordures faute ou quelque chose le long de ces lignes. Surtout depuis l'incident se produit 3 à 4 heures d'intervalle, même à bizarre heures comme 4:00 du matin quand personne n'utilise l'application.
    • C'est un excellent article. M'a aidé à aller au fond d'un ennuyeux IIS AFIN.
    • Super! Il a fallu des jours pour comprendre tout ça... mais je suppose que ça à l'air assez facile de se résumait à quelques points. Je pense de toutes mes réponses, et cette question m'a causé le plus de chagrin, alors c'est agréable de savoir qu'il fournit une certaine valeur.
    • Plus récemment DebugDiag est situé, il microsoft.com/en-us/download/confirmation.aspx?id=40336 (l'ancienne version lien ici n'est pas installe)
    • Merci pour la notification. Nous espérons que les instructions sur la façon d'utiliser n'ont pas changé dans la nouvelle version.
    • Pour moi, d'essayer d'ajouter la nouvelle Règle de la DebugDiag a abouti à un "impossible de démarrer DbgSVC. GetLastError retourne 0x00000422". Correctif est ici: stackoverflow.com/q/26127366/12484
    • Thx pour le suivi de détails.
    • Merci pour le fantastique réponse ci-dessus! M'a sauvé heures dans l'extinction d'un incendie sur mon serveur IIS de production de ce matin!
    • Cela a fonctionné comme un charme et m'a sauvé une tonne de temps. Je vous remercie. Note: les liens sont périmés mais un rapide google va les trouver.
    • Cette réponse est génial et je pense que ça va m'aider et je sais que c'est vieux cependant dès maintenant à un certain point w3wp.exe se bloque et je veux attraper le dump mais pour l'instant je suis tout capturer alors, comment puis-je filtrer par exemple de Réponse.Des redirections de provoquer des abandons de thread. Je ne veux pas décharges pour ceux je veux un dump pour quand le w3wp.exe en fait se bloque
    • Si je comprends bien votre problème, vous pouvez ajouter un "faux" paramètre de Réponse.Redirection qui permet d'arrêter l'abandon de thread. stackoverflow.com/questions/13727422/...
    • oui je suis au courant de cela, mais parce que le permet le code de continuer à exécuter, qui peut causer d'autres problèmes. J'ai été en mesure de trouver le hex code d'erreur d'être projetés pendant le crash d'w3wp.exe il a fini pas de code du tout, mais quelque chose que le client avait installé pour surveiller les incidents qui était à l'origine du w3wp.exe pour crash. Quelle ironie est que.

    InformationsquelleAutor MikeSmithDev
  2. 2

    Certains plus de la réponse ci-dessus.
    Développer l'extension de l'Explorateur qui a reçu l'erreur lors de la connexion de l'utilisateur. Donc, pour l'utilisateur, il semble "clignotement de l'écran" (alors que l'explorateur essaie de démarrer et de crash, puis redémarrer etc).
    Connecté sous un autre compte d'utilisateur installé DebugDiag et WinDbg.
    Je suis sous Windows 8.1 avec .Net 4.0 avec toutes les dernières mises à jour aujourd'hui (13 janvier 2014)
    Essayé de télécharger quelques symboles localement, mais WinDbg peut'not charge clr.apb en raison de mauvaises signaure.

    Résolu à l'aide de symboles en ligne - l'utilisation "SRV*http://msdl.microsoft.com/download/symbols" en tant que symboles de chemin.

    InformationsquelleAutor Arkady Marchenko
  3. 0

    Une autre cause pourrait "infini de façon récursive de la fonction". Quand est infitine boucle de Windows pour essayer de avoidence de blocage et de désactiver releated application de la piscine.

    J'ai rencontré le même problème aujourd'hui. J'ai une fonction récursive qui liste parentproject-sous-projet. Un projet est placé lui-même parent de projet et quand recusive fonction d'essayer de la liste de tous les parent-sous-projet, boucle infinie se passe.

    InformationsquelleAutor Dreamcatcher
  4. 0

    J'ai été en mesure de vérifier de l'Observateur d'Événements -> Journaux Windows -> Système et de trouver des

    Le pool d'applications "DankAppPool" est automatiquement désactivé en raison d'
    une série d'échecs dans le processus(es) au service de ce pool d'applications.

    Ci-dessous que:

    Un processus servant de pool d'applications 'DankAppPool' souffert d'une fatale
    erreur de communication avec le Service d'Activation des Processus Windows. L'
    id de processus a '5704'. Le champ de données contient le numéro de l'erreur.

    Et:

    La QueueMonitor service est terminé de manière inattendue. Il a fait ce 32
    temps(s). L'action corrective suivante va être effectuée dans 60 000
    millisecondes: Redémarrer le service.

    Au moins le QueueMonitor service est un endroit pour commencer.

    InformationsquelleAutor sirdank