Résoudre les erreurs HTTP 4xx et 5xx

Cet article fournit des étapes de résolution des problèmes liés à la résolution des erreurs de code d’état HTTP 4xx et 5xx dans Internet Information Services (IIS). Les codes d’état 4xx indiquent un problème côté client, tandis que les codes d’état 5xx indiquent un problème côté serveur. Les conseils vous aideront à identifier la cause de ces erreurs et à les résoudre efficacement.

Identifier les erreurs 4xx

Les codes d’état HTTP 4xx indiquent qu’une erreur s’est produite en raison d’un problème côté client. Par exemple, le navigateur client a peut-être demandé une page qui n’existe pas ou le navigateur client n’a pas fourni d’informations d’authentification valides.

Pour identifier 4xx erreurs, examinez les journaux IIS et les journaux HTTPERR :

• Le code d’état HTTP est enregistré dans les journaux IIS. Ce fichier est généralement stocké dans C :\inetpub\logs\Logfiles, mais peut être configuré via la journalisation IIS dans le Gestionnaire IIS.

• Un code d’erreur 4xx peut être généré par le pilote de noyau HTTP.sys , ce qui signifie que ces requêtes peuvent ne pas atteindre IIS et ne seront donc pas journalisées dans les journaux IIS. HTTP.sys journalise ces erreurs dans des fichiers distincts appelés journaux HTTPERR. Ce fichier est généralement stocké dans C :\Windows\System32\LogFiles\HTTPERR , mais peut être configuré via le Registre HKEY\LOCAL\MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\ErrorLoggingDir.

• Une façon de confirmer si la réponse 4xx provient de HTTP.sys consiste à collecter un fichier de trace HAR sur le client et à rechercher l’en-tête de réponse Microsoft-HttpApi/2.0.

  Pour capturer un fichier de trace HAR, qui enregistre l’interaction de votre navigateur avec le site web, suivez les instructions de Capture d’une trace de navigateur pour la résolution des problèmes.

Examiner les journaux IIS

Si vous trouvez des erreurs dans les journaux IIS, notez le code d’état (sc-status) et le code de sous-état (sc-substatus) et consultez la vue d’ensemble du code d’état HTTP pour plus d’informations.

Pour obtenir plus d’informations sur le code d’état et comprendre le module ou le gestionnaire qui a retourné des erreurs 4xx , collectez les journaux de trace des demandes ayant échoué (FREB) à peu près au moment où le problème s’est produit en configurant une règle FREB à déclencher par le code d’état affiché dans les journaux IIS.

Examiner les journaux HTTPERR

Si vous trouvez des erreurs dans les journaux HTTPERR, notez la raison (s-reason) et consultez Types d’erreurs journalisées par l’API serveur HTTP pour plus d’informations.

Identifier les erreurs 5xx

Les codes d’état HTTP 5xx indiquent que le serveur n’a pas pu terminer la requête, car le serveur a rencontré une erreur lors du traitement de la demande. Utilisez les instructions suivantes en fonction de votre type d’application.

500 erreurs dans ASP classique

Si une erreur 500 se produit dans ASP classique, vérifiez le code d’erreur ou le message d’erreur dans la cs-uri-query requête des journaux IIS.

Pour plus d’informations, capturez et examinez les journaux de trace des demandes ayant échoué (FREB) pour les erreurs 500.

500 erreurs dans IIS général

Si une erreur 500 se produit dans IIS en général, examinez les journaux IIS, notez le code d’état (sc-status) et le code de sous-état (sc-substatus) et consultez la vue d’ensemble du code d’état HTTP pour plus d’informations sur l’échec.

Activez les messages d’erreur détaillés si possible pour obtenir plus de détails. Pour activer les messages d’erreur détaillés, procédez comme suit :

1. Ouvrez la fenêtre de commande Exécuter .

2. Lancez inetmgr.

3. Dans le Gestionnaire IIS, sous le volet Connexions situé à gauche de la console, développez le nom de l’ordinateur, développez Sites, puis sélectionnez le site web cible.

   

4. Double-cliquez sur l’icône Pages d’erreur dans le volet central.

   

5. Sur la droite, dans le volet Actions , sélectionnez Modifier les paramètres de fonctionnalité.

   

6. Dans la boîte de dialogue Modifier les paramètres des pages d’erreur (où vous choisissez d’envoyer des demandes locales et distantes), le deuxième bouton d’option est ce que vous devez sélectionner pour retourner des erreurs détaillées pour les demandes locales et distantes. Par défaut, l’option inférieure est sélectionnée pour envoyer des erreurs détaillées uniquement envoyées pour les demandes locales.

   

   Nous vous déconseillons d’envoyer des erreurs détaillées pour les demandes distantes, car cette option peut exposer des informations sensibles à Internet. Vous devez rétablir les modifications une fois que vous avez plus d’informations sur l’échec.

Pour plus d’informations, capturez et examinez les journaux de trace des demandes ayant échoué (FREB) pour les erreurs 500.

500 erreurs dans ASP.NET

Si une erreur 500 se produit dans ASP.NET, utilisez les méthodes suivantes pour identifier la cause racine de l’erreur :

• Vérifiez les journaux des événements d’application.

  Vérifiez les journaux des événements de l’application au moment où le problème s’est produit. ASP.NET journalise les détails de l’erreur, y compris la pile des appels, dans les journaux des événements d’application.

  Pour accéder aux journaux des événements d’application, procédez comme suit :

  1. Ouvrez le menu Démarrer , recherchez Observateur d’événements, puis sélectionnez Observateur d’événements.
  2. Dans Observateur d’événements, ouvrez le nœud Journaux Windows.
  3. Sélectionnez Application pour ouvrir les journaux des événements d’application.
  4. Recherchez les erreurs associées à l’application ayant échoué. La valeur de la colonne Source pour les erreurs est iis AspNetCore Module ou IIS Express AspNetCore Module.

• Capturez les vidages de mémoire.

  Dans certains cas, il peut être nécessaire de capturer un vidage de mémoire d’une exception spécifique pour examiner les détails entourant l’exception qui a provoqué l’état HTTP 500.

  Pour capturer des vidages, suivez les instructions de collecte des vidages de mémoire pour une exception de première chance lorsqu’elle se produit.

  Utilisez l’outil Analyse DebugDiag 2 (partie de la suite DebugDiag ) avec la règle CrashHangAnalysis sur les vidages collectés pour générer un rapport qui peut être utilisé pour passer en revue la pile des appels et identifier la cause racine.

  Pour générer un rapport à l’aide de l’outil DebugDiag Analysis, procédez comme suit :

  1. Ouvrez l’analyse DebugDiag 2.
  2. Sélectionnez Ajouter des fichiers de données et ajoutez le ou les fichiers de .dmp .
  3. Sélectionnez CrashHangAnalysis et PerfAnalysis, puis démarrez l’analyse.

  Une fois terminé, un rapport (.mht) est créé dans C :\Program Files\DebugDiag\Reports et affiché dans Internet Explorer avec les résultats et les recommandations.

  Si vous utilisez des DLL personnalisées, vous pouvez spécifier le chemin de recherche de symboles pour les fichiers PDB personnalisés en procédant comme suit :

  1. Ouvrez l’outil DebugDiag 2 Collection.
  2. Sélectionnez les options d’outils>>et chemins de recherche.
  3. Sous Chemin de recherche de symboles pour le débogage, sélectionnez Parcourir pour définir le chemin d’accès.

• Capturez la trace Perfview pour identifier les problèmes ExecutionTimeout.

  Pour 500 erreurs en raison du dépassement de la ASP.NET ExecutionTimeout, capturez une trace PerfView et des vidages pour identifier les retards .

500 erreurs dans ASP.NET Core

Si une erreur 500 se produit dans ASP.NET Core, utilisez les méthodes suivantes pour identifier la cause racine de l’erreur :

• Vérifiez les journaux des événements d’application.

  Pour accéder aux journaux des événements d’application, procédez comme suit :

  1. Ouvrez le menu Démarrer , recherchez Observateur d’événements, puis sélectionnez Observateur d’événements.
  2. Dans Observateur d’événements, ouvrez le nœud Journaux Windows.
  3. Sélectionnez Application pour ouvrir les journaux des événements d’application.
  4. Recherchez les erreurs associées à l’application ayant échoué. La valeur de la colonne Source pour les erreurs est iis AspNetCore Module ou IIS Express AspNetCore Module.

• Activez la page d’exception du développeur.

  La ASPNETCORE_ENVIRONMENT variable d’environnement peut être ajoutée à web.config pour exécuter l’application dans l’environnement de développement. Si vous ne remplacez pas le paramètre d’environnement dans le code de démarrage de votre application à l’aide de la UseEnvironment méthode sur le générateur d’hôtes, la variable d’environnement permet à la page d’exception du développeur d’apparaître lors de l’exécution de l’application.

  <aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
    <environmentVariables>
       <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
    </environmentVariables>
  </aspNetCore>
  

  La définition de la variable d’environnement est ASPNETCORE_ENVIRONMENT recommandée uniquement sur les serveurs intermédiaires et de test non exposés à Internet. Supprimez la variable d’environnement du fichier web.config une fois la résolution des problèmes effectuée.

• Activez le journal du module stdout ASP.NET Core.

  Pour activer et afficher stdout les journaux, procédez comme suit :

  1. Accédez au dossier de déploiement du site sur le système hôte.

  2. Si le dossier logs n’est pas présent, créez-le. Pour obtenir des instructions sur l’activation de MSBuild pour créer automatiquement le dossier des journaux d’activité dans le déploiement, consultez ASP.NET structure de répertoires Core.

  3. Modifiez le fichier web.config. stdoutLogEnabled Définissez et modifiez true le stdoutLogFile chemin d’accès pour qu’il pointe vers le dossier des journaux (par exemple, .\logs\stdout) comme suit :

     <aspNetCore processPath="dotnet"
         arguments=".\App.dll"
         stdoutLogEnabled="true"
         stdoutLogFile=".\logs\stdout">
     </aspNetCore>
     

  4. Utilisez stdout comme préfixe de nom de fichier. Un horodatage, un ID de processus (PID) et une extension de fichier sont ajoutés automatiquement lors de la création du journal. Un nom de fichier journal classique est stdout_<timestamp>_<PID>.log.

  5. Vérifiez que l’identité de votre pool d’applications dispose des autorisations d’écriture sur le dossier logs.

  6. Enregistrez le fichier web.config mis à jour.

  7. Effectuez une demande à l’application.

  8. Accédez au dossier logs. Recherchez et ouvrez le journal le plus récent stdout .

  9. Examinez les erreurs dans le journal.

  Pour désactiver la stdout journalisation lorsque la résolution des problèmes est terminée, procédez comme suit :

  1. Modifiez le fichier web.config.
  2. Définissez stdoutLogEnabled sur false.
  3. Enregistrez le fichier.

• Activez le journal de débogage du module core ASP.NET (IIS).

  Pour activer le journal de débogage du module principal ASP.NET, ajoutez les paramètres de gestionnaire suivants au fichier web.config de l’application :

  <aspNetCore ...>
     <handlerSettings>
       <handlerSetting name="debugLevel" value="file" />
       <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
     </handlerSettings>
  </aspNetCore>
  

  Vérifiez que le chemin spécifié pour le journal existe et que l’identité du pool d’applications dispose d’autorisations d’écriture sur l’emplacement.

Erreurs 502 dans ARR

Si une erreur 502 se produit dans le routage des demandes d’application (ARR), suivez les instructions de résolution des erreurs 502 dans ARR.

Erreurs 503

Si vous rencontrez 503 erreurs, le code de sous-état (sc-substatus) dans les journaux IIS ou dans les s-reason HTTPERR peut fournir des conseils.

Pour plus d’informations, consultez l’article suivant :

• 503 - Service indisponible
• Journalisation des erreurs dans l’API serveur HTTP

Reportez-vous également à l’article suivant, qui met en évidence un problème connu qui peut entraîner des erreurs 503 :

Réponse HTTP 503 Service indisponible à partir d’IIS : une cause générique courante

Collecte de données

Étapes de capture des journaux FREB

Important

Pour configurer les journaux FREB, vérifiez que le service de rôle de suivi est installé pour IIS.

Pour installer le service de rôle de suivi pour IIS, procédez comme suit :

1. Ouvrez Gestionnaire de serveur, puis sélectionnez Gérer les>rôles et fonctionnalités.
2. Dans la fenêtre Ajouter des rôles et des fonctionnalités , sélectionnez Suivant jusqu’à atteindre la page Rôles de serveur.
3. Développez Web Server (IIS)Web> Server>Health and Diagnostics, puis cochez la case Suivi.
4. Sélectionnez Suivant pour les étapes suivantes, puis sélectionnez Installer.

Une fois le service de rôle de suivi installé, procédez comme suit pour capturer FREB :

1. Ouvrez la fenêtre de commande Exécuter .

2. Lancez inetmgr.

3. Dans le Gestionnaire des services Internet, sous le volet Connexions , développez le nom de l’ordinateur, développez Sites, puis sélectionnez le site web cible.

   

4. Double-cliquez sur Règles de suivi des requêtes ayant échoué.

   

5. Dans le volet Actions , sélectionnez Ajouter.

6. Dans l’Assistant Ajouter une règle de suivi des demandes ayant échoué, dans la page Spécifier le contenu à suivre, sélectionnez Tout le contenu>Suivant.

   

7. Dans la page Définir les conditions de trace, mettez à jour le ou les codes d’étatsur 400-600 , puis sélectionnez Suivant.

   

8. Dans la page Sélectionner les fournisseurs de trace, sous Fournisseurs, cochez toutes les cases. Sous Zones, vérifiez que toutes les cases sont cochées pour chaque fournisseur. Sous Verbosité, sélectionnez Détaillée. Sélectionnez Terminer.

9. Activez le suivi des demandes ayant échoué pour le site et configurez le répertoire du fichier journal :

   1. Dans le volet Connexions, développez le nom de l’ordinateur, développez Sites, puis sélectionnez Site web par défaut.

   2. Dans le volet Actions , sous Configurer, sélectionnez Suivi des demandes ayant échoué.

      

   3. Dans la boîte de dialogue Modifier les paramètres de suivi des demandes ayant échoué du site web, cochez la case Activer, définissez le champ Répertoire sur %SystemDrive%\inetpub\logs\FailedReqLogFiles et définissez le nombre maximal de fichiers de trace sur 1000.

      

   4. Cliquez sur OK.

Étapes pour capturer une trace et des vidages PerfView

Pour capturer une trace et des vidages PerfView, suivez les étapes décrites dans les sections suivantes.

Configurer PerfView et Procdump avant le problème

Avant le problème, procédez comme suit pour configurer PerfView et Procdump pour la collecte de données :

1. Téléchargez ProcDump. Il s’agit d’un fichier exécutable léger qui ne nécessite pas d’installation et automatise la collecte de vidage.

2. Extrayez le fichier procdump.exe dans un dossier particulier sur le serveur.

3. Téléchargez l’outil PerfView sur le serveur. Il s’agit d’un outil de profileur qui capture les événements de suivi d’événements pour Windows (ETW) (aucune installation requise).

4. Pour que PerfView fournisse des informations utiles, ajoutez le suivi en tant que service de rôle pour IIS. Sans suivi activé, une trace ETW inclut uniquement des informations HTTP.sys . Si vous ne savez pas si le service de rôle de suivi est installé, procédez comme suit :

   1. Ouvrez Gestionnaire de serveur, puis sélectionnez Gérer les>rôles et fonctionnalités.
   2. Dans la fenêtre Ajouter des rôles et des fonctionnalités , sélectionnez Suivant jusqu’à atteindre la page Rôles de serveur.
   3. Développez Web Server (IIS)Web> Server>Health and Diagnostics, puis cochez la case Suivi.
   4. Sélectionnez Suivant pour les étapes suivantes, puis sélectionnez Installer.

5. Ouvrez l’outil PerfView, sélectionnez le menu Collecter , puis sélectionnez l’option Collecter .

6. Cochez les cases Zip, Merge et Thread Time , comme illustré dans la capture d’écran suivante. Modifiez le champ Mo circulaire sur 2000 :

   

7. Développez l’onglet Options avancées et cochez la case IIS , comme illustré dans la capture d’écran suivante.

   

   Si vous exécutez une application ASP.NET Core, ajoutez la chaîne suivante dans les fournisseurs supplémentaires :

   *Microsoft-Extensions-Logging:4:5,Microsoft-AspNetCore-Server-Kestrel,System.Net.Http,System.Net.Sockets,System.Net.NameResolution,System.Threading.Tasks.TplEventSource::5,Microsoft-System-Net-Http,Microsoft-Windows-Application Server-Applications::Verbose

   Note

   Ne manquez pas l’astérisque (*) au début.

Collecter des données pendant le problème

Pendant le temps du problème, procédez comme suit pour collecter des données :

1. Sélectionnez le bouton Démarrer la collection dans PerfView avec les paramètres de configuration que vous avez configurés dans La section Configurer PerfView et Procdump.

2. Ouvrez Gestionnaire des services Internet (IIS) .

3. Sélectionnez le nom de votre serveur (à gauche).

4. Double-cliquez sur Processus de travail pour afficher l’ID de processus des services. Par exemple :

   

5. Ouvrez Invite de commandes en tant qu’administrateur.

6. Accédez au dossier dans lequel procdump.exe est extrait en exécutant dans la cd <path to procdump.exe> commandes.

7. Exécutez la commande suivante pour capturer des vidages consécutifs.

   procdump.exe -accepteula -ma <PID of W3WP.exe)> -s 10 -n 3

   Note

   Remplacez <PID of W3WP.exe> par le PID réel du processus de W3WP.exe que vous avez trouvé à l’étape 4.

   • Vous pouvez spécifier un chemin à la fin de la commande pour stocker les vidages dans un emplacement spécifique.
   • Cette commande capture trois jeux de vidages à intervalles de 10 secondes.

8. Une fois que les vidages sont collectés par procdump, arrêtez PerfView en sélectionnant Arrêter la collection ou attendez deux minutes et demi pour qu’il s’arrête automatiquement. Autoriser PerfView à fusionner les données collectées, ce qui peut prendre un certain temps. Et il génère un fichier Perfview.etl.zip . Si vous êtes invité à entrer des symboles, sélectionnez Utiliser les serveurs de symboles Microsoft.

Plus d’informations

• Codes d’état 4xx - Erreur du client
• Codes d’état 5xx - Erreur du serveur