IIS7: application w3wp.exe défaillante, quelle est la cause de ces accidents?

Question

Notre site Web est en .NET mais avec quelques anciennes bibliothèques ASP et 32bits. Cela fonctionnait bien depuis un moment (2 ans). Mais pour le mois passé, nous avons vu l'erreur suivante sur notre serveur IIS7, que nous n'avons pas pu retrouver et corriger:

"Application défectueuse w3wp.exe, version 7.0.6001.18000, horodatage 0x47919413, module défaillant kernel32.dll, version 6.0.6001.18215, horodatage 0x4995344f, code d'exception 0xe053534f, correction d'erreur 0x0002f328, ID de processus 0x% 9, heure de début de l'application 0x% 10. "

Nous sommes en mesure de reproduire l'erreur:

• L'une de nos pages .aspx commence le chargement, l'exécution du code et des requêtes (nous avons Response.Flush() sur toute la page pour suivre où les pauses de code), puis il s'arrête soudainement et nous obtenons l'erreur ci-dessus dans IIS.

• La page arrête le chargement et, sans Response.Flush(), il ne rediriger vers notre page de error.aspx (tel que configuré dans web.config)

• L'erreur ne se produit pas tout le temps. Parfois, cela arrive 3 fois de suite, alors ça marche bien pendant 15 minutes non-stop avec une redirection correcte vers error.aspx. L'erreur que nous obtenons alors est un classique: "soit BOF ou EOF est vrai, ou l'enregistrement en cours a été supprimé." Lorsque l'erreur se produit, la page se bloque et toutes les autres sessions sur le même ordinateur de n'importe quel navigateur ont des pages Web suspendues (BTW, nous n'autorisons qu'un processus de travail pendant que nous testons). À partir d'autres ordinateurs, le site se charge bien.

• Je peux recycler le pool d'applications, tuer w3wp.exe, redémarrer IIS. Rien ne va faire. La seule façon de charger à nouveau la page est de redémarrer MS SQL qui gère nos états de session. Je ne sais pas pourquoi c'est, mais nous avons deviné que les cookies de session sur les navigateurs des utilisateurs pointe vers un thread qui n'a pas été terminé correctement (en raison du plantage ci-dessus) et IIS attend qu'il se termine pour traiter plus de code (?). Si quelqu'un peut mieux expliquer cela, ce serait vraiment utile. Y a-t-il un timeout que nous pouvons définir pour "terminer" les threads? Est-ce un problème lié à MS SQL?

J'ai aussi regardé les usages de la mémoire privée et virtuels, parce que je pense que notre code n'est pas le plus efficace et je suis certain qu'il nous reste des fuites de mémoire. Cependant, j'ai vu la page tomber en panne même si les souvenirs privés et virtuels étaient encore assez faibles (moins de 100 Mo chacun).

J'ai utilisé Debug Diag et WinDbg comme indiqué ici: http://blogs.msdn.com/b/tess/archive/2009/03/20/debugging-a-net-crash-with-rules-in-debug-diag.aspx, mais nous ne sommes pas en mesure de faire fonctionner windbg, c'est ce que nous essayons de faire pour le moment.

Si quelqu'un pouvait nous aider ou nous diriger vers la bonne direction ce serait vraiment génial, merci.

Answer 1

Il est tout à fait possible qu'un de vos assemblages référencés/liés soit devenu corrompu de manière aléatoire (cela peut arriver) sur le disque. Pouvez-vous essayer de reproduire le problème sur une nouvelle machine propre avec les mêmes caractéristiques, les nouvelles installations des derniers pilotes xyz que vous utilisez? J'ai résolu un mystérieux problème qui m'a pris des mois pour isoler de cette façon.Il semblait propre, de nouvelles machines avec les mêmes spécifications et les pilotes pré-requis fonctionneraient très bien - seulement certaines machines plus anciennes avec les mêmes spécifications échouaient systématiquement. J'ai fini par désinstaller tout (IIS, ASP.NET, .NET, base de données et client) et commencer à partir de zéro. La cause finale quand je l'ai isolée était que le pilote de client de DB était corrompu sur les machines plus anciennes (et toutes les machines plus anciennes étaient les unes des autres, donc je suppose qu'elles ont été clonées après que la corruption ait eu lieu), et il semblait être jouer avec l'espace mémoire .NET même si je ne l'appelais pas directement. Je n'ai pas encore répondu à ma réponse "help me debug this monster" avec cette réponse parce que je doutais que cela aiderait quelqu'un.

Answer 2

"Le format BOF ou EOF est True ou l'enregistrement en cours a été supprimé" signifie que la table est vide et que vous tentez d'effectuer un MoveNext. Donc vérifier l'eof avant de faire des mouvements.

IIS est connu pour lancer des erreurs de noyau dans w3wp.exe comme celui-ci. Toutes vos erreurs dans l'état de session ne sont que des symptômes du processus planté. Les pools d'applications multiples ne seront d'aucune aide - ils ne font que répandre l'erreur.

Je parierais que ce sont des blocages SQL à cause de la modification de votre environnement utilisateur. Cela causera un retard de 10 secondes pendant que SQL essaye de déterminer quelle requête tuer. On gagne, on perd. Le perdant récupère un pointeur vers une table inutilement vide et vous essayez un coup et un crash suivant. Vous pourriez peut-être diriger votre base de données vers une connexion ODBC et activer le suivi, ou trouver un moyen d'obtenir SQL pour l'enregistrer. J'ai eu tous les mêmes symptômes que ci-dessus en Per1. J'ai été capable de faire un wrapper fn() pour faire toutes les requêtes SQL et enregistrer tous les sql, + params et toutes les erreurs sur le disque pour localiser le problème. Il s'agissait d'interblocages, puis nous avons pu coder dans l'auto-réessayer, et finalement nous avons recodé l'ordre de requête et les colonnes analysées pour éliminer les interblocages.

Answer 3

Nous avons commencé à recevoir cette erreur après l'installation de mises à jour Windows sur une machine Windows Server 2008 R2. Le service d'activation de processus Windows (WAS) installe des liaisons de sites supplémentaires qui ont causé des problèmes pour notre installation.

Nous avons supprimé les liaisons net.tcp, net.pipe, net.msmq et msmq.formatname de notre site Web et ne recevaient plus l'exception de l'application défaillante.

Answer 4

Ceci est probablement un cas limite, mais juste au cas où quelqu'un vient ici et qu'ils utilisent MVCMailer, j'obtenais la même erreur en raison de la méthode .SendAsync() sur les expéditeurs. Je les ai tous basculés à .Send() et le blocage s'est arrêté.

Voir this SO answer des façons d'utiliser le logiciel de messagerie async et éviter l'accident (soi-disant, je ne l'ai pas personnellement mettre en œuvre)