J'ai une application Web ASP.NET MVC qui intègre une bibliothèque gérée C# qui charge des plugins non gérés pour effectuer un traitement de fichiers. À leur tour, ces plugins non gérés comptent sur quelques bibliothèques tierces pour faire leur sale boulot; certains d'entre eux provoquent le blocage d'IIS.Débogage d'un plantage IIS mystérieux
Nous utilisons exactement la même bibliothèque dans une application de bureau qui est capable de traiter les fichiers très bien. Les fichiers fonctionnent également très bien lorsqu'ils s'exécutent sous le serveur Web Cassini fourni avec Visual Studio 2008 (IIS et Cassini s'exécutent dans le même dossier sur ma boîte locale).
J'ai fait un Crash Analysis with Debug Diagnostic (img) dont je ne suis pas en mesure d'extraire des informations utiles.
J'ai utilisé un peu procexp pour voir s'il y avait des tentatives d'accès au registre ou à un fichier qui ont causé un problème mais qui ont échoué. Je n'en ai vu aucun mais je les aurais facilement manqués compte tenu du nombre de lignes produites dans ce type de journalisation.
J'ai configuré le pool d'applications pour utiliser un compte de domaine et ai fait de ce compte un administrateur sur ma boîte en pensant qu'il pourrait s'agir d'un problème de permission mais pas de chance. Existe-t-il d'autres restrictions d'accès dans IIS que je ne connais pas?
Suggestions? Des articles? Outils? Vaudou?
EDIT: J'ai été capable de déboguer cela à la routine d'initialisation de la bibliothèque de la 3ème partie. Étant donné que la bibliothèque fonctionne correctement sous d'autres hôtes, je soupçonnais un problème d'autorisation ou de mémoire. Il s'est avéré être une limite de taille de pile lors de l'exécution sous IIS. Voir Stack sizes in IIS - affects ASP.NET
Pouvez-vous mettre une connexion dans le code auquel vous avez accès, pour vous aider à localiser l'endroit exact où les composants tiers causent un accident? Par exemple, le crash peut être dû à toujours le même appel de fonction; Le fait de savoir quelque chose comme ça pourrait vous aider à résoudre le problème mieux que de simplement savoir que le composant tiers * en quelque sorte * fait planter IIS. – stakx