Partager via

Résoudre les incidents de pool d’applications sur une machine virtuelle Services cloud

  • Article

Cet article explique comment résoudre les blocages de pool d’applications sur une machine virtuelle dans Microsoft Azure Services cloud. Si un pool d’applications se bloque, votre application cesse de répondre.

Étape 1 : Rechercher les erreurs dans les processus qui servent des pools d’applications

Dans l’Observateur d’événements, si vous sélectionnez Système des journaux>Windows dans l’arborescence de la console, vous pouvez voir l’un des événements suivants :

Un processus servant le pool d’applications « %1 » a subi une erreur de communication irrécupérable avec le service d’activation de processus Windows. L’ID de processus était « %2 ». Le champ de données contient le numéro d’erreur.

Un processus servant le pool d’applications « %1 » s’est arrêté de façon inattendue. L’ID de processus était « %2 ». Le code de sortie du processus était « %3 ».

Ces événements indiquent clairement un blocage du pool d’applications. Étant donné qu’une erreur s’est produite dans l’application, le pool d’applications devait être arrêté. Une fois le pool d’applications terminé, son processus de w3wp.exe correspondant est également arrêté. Toutes les informations basées sur le cache ou basées sur une session que vous avez enregistrées dans le processus de w3wp.exe sont effacées.

Dans l’idéal, lorsqu’un pool d’applications se bloque, un nouveau processus de w3wp.exe est généré automatiquement pour respecter les requêtes entrantes. Toutefois, si le pool d’applications plante plus de cinq fois au cours d’une période de cinq minutes, le pool d’applications passe à un état arrêté. Vous devrez redémarrer manuellement le pool d’applications pour l’exécuter. Si quelque chose de similaire se produit, vous observerez l’événement suivant sous les journaux système dans l’Observateur d’événements :

Le pool d’applications « %1 » est automatiquement désactivé en raison d’une série d’échecs dans le ou les processus qui servent ce pool d’applications.

Vous pouvez configurer ces paramètres dans la boîte de dialogue Paramètres avancés du pool d’applications, sous la section Protection rapide contre l’échec. La propriété Enabled a la valeur true par défaut. Si la propriété Enabled a la valeur True, le pool d’applications s’arrête une fois la limite d’échec atteinte dans un certain temps. La limite d’échec est représentée par la propriété Nombre maximal d’échecs . Cette propriété a la valeur par défaut 5. L’intervalle de temps est représenté par la propriété Failure Interval (minutes). Cette propriété est également égale à 5.

Capture d’écran de la boîte de dialogue Paramètres avancés du pool d’applications, section Protection rapide-échec.

Étape 3 : Capturer les fichiers de vidage w3wp.exe processus

Après avoir déterminé que l’application s’est écrasée, déterminez exactement pourquoi elle s’est écrasée. Vous devrez capturer un fichier de vidage du processus w3wp.exe juste avant qu’il ne se termine. Il existe de nombreuses façons de capturer ce fichier. Vous pouvez configurer windows Error Reporting (WER), ProcDump et DebugDiag pour capturer un fichier de vidage sur incident. Cet article traite uniquement de la méthode DebugDiag de capture de données.

Pour télécharger et installer DebugDiag, procédez comme suit :

  1. Accédez au site Outil de diagnostic de débogage v2 , puis sélectionnez Télécharger.

  2. Pour choisir le téléchargement souhaité, sélectionnez la version de fichier Microsoft Windows Installer (MSI) appropriée pour l’architecture de votre ordinateur, puis sélectionnez Suivant.

  3. Ouvrez le fichier téléchargé. Dans l’Assistant Installation, acceptez les options par défaut, puis terminez l’installation de l’application.

Pour configurer l’application DebugDiag 2 Collection , procédez comme suit :

  1. Sélectionnez Démarrer, entrez Collection DebugDiag 2, puis ouvrez l’application nouvellement installée dans la liste des résultats.

  2. Dans la boîte de dialogue Sélectionner le type de règle, sélectionnez l’option Plantage , puis sélectionnez Suivant.

  3. Dans la boîte de dialogue Sélectionner le type de cible, sélectionnez l’option de pool d’applications web IIS spécifique, puis sélectionnez Suivant.

  4. Dans la boîte de dialogue Sélectionner une cible , sélectionnez le pool d’applications spécifique qui se bloque, puis sélectionnez Suivant. Si une fenêtre s’ouvre qui indique que la gestion des services Internet (IIS) n’est pas installée et que les pools d’applications ne sont pas répertoriés, sélectionnez OK, puis entrez manuellement le nom de l’application.

  5. Dans la boîte de dialogue Configuration avancée (facultatif), sélectionnez Points>d’arrêt Ajouter un point d’arrêt.

  6. Effectuez les sélections suivantes pour créer un point d’arrêt, puis sélectionnez OK.

    Champ Description active
    Offset Expression Processus de capture Ntdll !ZwTerminateProcess
    Type action Type de vidage capturé Userdump complet
    Limite d’action Nombre de vidages à capturer 10

  7. Dans la boîte de dialogue Configurer les points d’arrêt, vérifiez que le nouvel élément Expression de point d’arrêt est affiché. Sélectionnez Enregistrer & Fermer pour revenir à la boîte de dialogue Configuration avancée (facultatif), puis sélectionnez Suivant pour activer le point d’arrêt.

  8. Dans la boîte de dialogue Sélectionner l’emplacement de vidage et le nom de la règle (facultatif), entrez un nom de règle, puis remplacez l’emplacement Userdump par un lecteur et un répertoire qui disposent d’un espace disque disponible suffisant, si nécessaire. (La taille de chaque fichier de vidage correspond à ce qui est consommé par le processus de w3wp.exe en mémoire.)

  9. Cliquez sur Suivant.

  10. Pour activer la règle, sélectionnez Terminer.

À présent, la règle d’incident est dans un état actif et le nombre Userdump est égal à 0. Lorsque le problème se produit, le nombre de vidages augmente immédiatement et un fichier de vidage correspondant est généré.

Note

Une corbeille normale du pool d’applications peut également déclencher un fichier de vidage. Cela se produit parce que, lorsqu’il recycle, le w3wp.exe ID de processus (PID) correspondant du pool d’applications change. Cela génère un fichier de vidage. Ce fichier est un faux positif. Par conséquent, il ne vous aidera pas à analyser le blocage du pool d’applications. Chaque fois que vous voyez un incrément dans le nombre userdump, vérifiez les journaux des événements pour déterminer si les événements d’incident attendus se sont produits. Si les événements sont comme prévu, le vidage capturé est correct.

Étape 4 : Analyser les fichiers de vidage w3wp.exe processus

Une fois le fichier de vidage capturé, vous pouvez ouvrir l’analyse Start>DebugDiag 2. Cette application vous permet d’analyser le fichier de vidage sur incident capturé.

Vérifiez que le chemin d’accès aux symboles est correctement défini. Il s’agit d’un processus en deux parties. Dans Analyse DebugDiag 2, sélectionnez Paramètres (icône d’engrenage). Sous Chemins de recherche de symboles à utiliser pour l’analyse, vérifiez que _NT_SYMBOL_PATH et les serveurs de symboles publics Microsoft sont sélectionnés .

Rouvrez la collection DebugDiag 2, puis sélectionnez Options et paramètres des outils>. Ensuite, dans la boîte de dialogue Options &Paramètres , vérifiez que la zone De débogage de votre chemin de recherche de symboles (c.-à-d. Règles de blocage) est définie sur srv*c :\symcache*https://msdl.microsoft.com/download/symbols. Ce chemin entraîne le téléchargement des symboles DebugDiag en fonction des besoins à partir du serveur de symboles publics Microsoft, puis les stocke dans le répertoire c :\symcache .

Après avoir modifié ou vérifié vos paramètres de chemin d’accès aux symboles, vous pouvez analyser les fichiers de vidage capturés. Pour démarrer l’analyse, revenez à DebugDiag 2 Analysis, puis double-cliquez sur le nom d’un fichier de vidage. Une fois le rapport généré, vous pouvez l’ouvrir dans le navigateur et comprendre la pile des appels du thread qui a déclenché l’expression de point d’arrêt. Lisez la pile des appels de bas en haut, puis déterminez la méthode ou le composant qui a déclenché le blocage du pool d’applications. Si vous ne trouvez pas de pile d’appels d’exception précise, examinez plus en détail la pile des appels .NET dans la même analyse de fichier de vidage.

Étape 5 : Rechercher les exceptions non gérées dans le processus w3wp.exe ou WaWorkerHost.exe

Pour rechercher également les exceptions non gérées qui ont provoqué l’arrêt du processus w3wp.exe ou WaWorkerHost.exe , consultez Les exceptions non gérées provoquent l’arrêt d’ASP. Applications basées sur NET pour quitter de manière inattendue dans le .NET Framework.

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.