Résoudre les problèmes liés à ASP.NET Core sur Azure App Service et IIS

Par Justin Kotalik

Cet article fournit des informations sur les erreurs courantes de démarrage d’application et des instructions sur la façon de diagnostiquer les erreurs lorsqu’une application est déployée sur Azure App Service ou IIS :

Erreurs de démarrage d’application
Explique les scénarios courants de code d'état HTTP de démarrage.

Résoudre les problèmes sur Azure App Service
Fournit des conseils de résolution des problèmes pour les applications déployées sur Azure App Service.

Résoudre les problèmes sur IIS
Fournit des conseils de résolution des problèmes pour les applications déployées sur IIS ou exécutées sur IIS Express localement. Les instructions s’appliquent aux déploiements de Windows Server et de bureau Windows.

Effacer les caches de package
Explique ce qu’il faut faire lorsque des packages incohérents interrompent une application lors d’une mise à niveau majeure ou de la modification de versions de package.

Ressources supplémentaires
Répertorie d’autres rubriques de résolution des problèmes.

Erreurs de démarrage d’application

Dans Visual Studio, le serveur par défaut ASP.NET Core projet est Kestrel. Visual Studio peut être configuré pour utiliser IIS Express. Un échec de processus 502.5 ou un échec de démarrage 500.30 qui se produit pendant un débogage local avec IIS Express peut être diagnostiqué en utilisant les conseils de cette rubrique.

403.14 Interdit

L’application ne parvient pas à démarrer. L’erreur suivante est enregistrée :

The Web server is configured to not list the contents of this directory.

L’erreur est généralement due à un déploiement interrompu sur le système d’hébergement, qui inclut l’un des scénarios suivants :

• L’application est déployée dans le dossier incorrect sur le système d’hébergement.
• Le processus de déploiement n’a pas pu déplacer tous les fichiers et dossiers de l’application vers le dossier de déploiement sur le système d’hébergement.
• Le fichier web.config est manquant dans le déploiement ou le contenu du fichier web.config est incorrect.

Procédez comme suit :

1. Supprimez tous les fichiers et dossiers du dossier de déploiement sur le système d’hébergement.
2. Redéployez le contenu du dossier de publication de l’application sur le système d’hébergement à l’aide de votre méthode de déploiement normale, telle que Visual Studio, PowerShell ou le déploiement manuel :
   • Vérifiez que le fichier web.config est présent dans le déploiement et que son contenu est correct.
   • Lors de l’hébergement sur Azure App Service, vérifiez que l’application est déployée dans le dossier D:\home\site\wwwroot.
   • Lorsque l’application est hébergée par IIS, vérifiez que l’application est déployée sur le chemin d’accès physique IIS affiché dans les paramètres de base du Gestionnaire IIS.
3. Vérifiez que tous les fichiers et dossiers de l’application sont déployés en comparant le déploiement sur le système d’hébergement au contenu du dossier de publication du projet.

Pour plus d’informations sur la disposition d’une application ASP.NET Core publiée, consultez ASP.NET Core structure de répertoires. Pour plus d’informations sur le fichier web.config, consultez Module ASP.NET Core (ANCM) pour IIS.

500 Erreur interne du serveur

L’application démarre, mais une erreur empêche le serveur de répondre à la requête.

Cette erreur se produit dans le code de l’application pendant le démarrage ou durant la création d’une réponse. La réponse peut être dépourvue de contenu ou apparaître sous la forme d’une erreur de serveur interne 500 dans le navigateur. Le Journal des événements de l’application indique généralement qu’elle a démarré normalement. Du point de vue du serveur, c’est exact. L’application a démarré, mais elle ne peut pas générer de réponse valide. Exécutez l’application depuis une invite de commandes sur le serveur ou activez le journal stdout du module ASP.NET Core pour résoudre le problème.

Cette erreur peut également se produire lorsque l’offre groupée d’hébergement .NET Core n’est pas installé ou est endommagé. L’installation ou la réparation de l’installation de l’offre groupée d’hébergement .NET Core (pour IIS) ou de Visual Studio (pour IIS Express) peut résoudre le problème.

500.0 - Échec de chargement du gestionnaire in-process

Le processus de travail échoue. L’application ne démarre pas.

Une erreur inconnue s’est produite durant le chargement des composants du module ASP.NET Core. Effectuez l'une des opérations suivantes :

• Contactez le Support Microsoft (sélectionnez Outils de développement, puis ASP.NET Core).
• Posez une question sur Stack Overflow.
• Signalez un problème sur notre dépôt GitHub.

500.30 - Échec du démarrage in-process

Le processus de travail échoue. L’application ne démarre pas.

Le module ASP.NET Core tente, en vain, de démarrer le CLR .NET Core in-process. Vous pouvez généralement déterminer la cause d’un échec de démarrage du processus à partir des entrées du Journal des événements de l’application et du journal stdout du module ASP.NET Core.

Conditions d’échec courantes :

• L’application est mal configurée à cause du ciblage d’une version de l’infrastructure partagée ASP.NET Core non présente. Vérifiez les versions du framework partagé ASP.NET Core qui sont installées sur l’ordinateur cible.
• Utilisation d’Azure Key Vault, absence d’autorisations sur le Key Vault. Vérifiez les stratégies d’accès dans le Key Vault ciblé pour vous assurer que les autorisations appropriées sont accordées.

500.31 - Échec de la recherche de dépendances natives par ANCM

Le processus de travail échoue. L’application ne démarre pas.

Le module ASP.NET Core tente, en vain, de démarrer le runtime .NET Core in-process. La cause la plus courante de cet échec de démarrage est liée à la non-installation du runtime Microsoft.NETCore.App ou Microsoft.AspNetCore.App. Si l’application est déployée pour cibler ASP.NET Core 3.0, et si cette version n’existe pas sur la machine, cette erreur se produit. Voici un exemple de message d’erreur :

The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - The following frameworks were found:
      2.2.1 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview5-27626-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27713-13 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27714-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27723-08 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]

Le message d’erreur liste toutes les versions installées de .NET Core ainsi que la version demandée par l’application. Pour corriger cette erreur, vous avez le choix entre plusieurs possibilités :

• Installez la version appropriée de .NET Core sur la machine.
• Changez l’application pour cibler une version de .NET Core présente sur la machine.
• Publiez l’application sous forme de déploiement autonome.

Durant l’exécution en phase de développement (la variable d’environnement ASPNETCORE_ENVIRONMENT a la valeur Development), l’erreur spécifique est écrite dans la réponse HTTP. La cause d’un échec de démarrage du processus se trouve également dans le Journal des événements de l’application.

500.32 - Échec du chargement de la dll par ANCM

Le processus de travail échoue. L’application ne démarre pas.

Le plus souvent, cette erreur provient du fait que l’application est publiée pour une architecture de processeur incompatible. Si le processus de travail s’exécute en tant qu’application 32 bits et si l’application a été publiée pour cibler une architecture 64 bits, cette erreur se produit.

Pour corriger cette erreur, vous avez le choix entre plusieurs possibilités :

• Republiez l’application pour la même architecture de processeur que celle du processus de travail.
• Publiez l’application sous forme de déploiement dépendant du framework.

500.33 - Échec du chargement du gestionnaire de requêtes ANCM

Le processus de travail échoue. L’application ne démarre pas.

L’application n’a pas référencé le framework Microsoft.AspNetCore.App. Seules les applications ciblant l’infrastructure Microsoft.AspNetCore.App peuvent être hébergées par le module ASP.NET Core.

Pour corriger cette erreur, vérifiez que l’application cible le framework Microsoft.AspNetCore.App. Examinez le fichier .runtimeconfig.json pour vérifier le framework ciblé par l’application.

500.34 - Modèles d’hébergement mixtes ANCM non pris en charge

Le processus de travail ne peut pas exécuter à la fois une application in-process et une application out-of-process dans le même processus.

Pour corriger cette erreur, exécutez les applications dans des pools d’applications IIS distincts.

500.35 - Applications in-process multiples dans le même processus ANCM

Le processus de travail ne peut pas exécuter plusieurs applications in-process dans le même processus.

Pour corriger cette erreur, exécutez les applications dans des pools d’applications IIS distincts.

500.36 - Échec de chargement du gestionnaire out-of-process ANCM

Le gestionnaire de requêtes out-of-process, aspnetcorev2_outofprocess.dll, ne se trouve pas aux côtés du fichier aspnetcorev2.dll. Cela indique une installation endommagée du module ASP.NET Core.

Pour corriger cette erreur, réparez l’installation du bundle d’hébergement .NET Core (pour IIS) ou Visual Studio (pour IIS Express).

500.37 - Échec du démarrage d’ANCM dans le délai imparti

ANCM n’a pas pu démarrer dans le délai imparti spécifié. Par défaut, le délai d’expiration est de 120 secondes.

Cette erreur peut se produire quand un grand nombre d’applications démarrent sur la même machine. Recherchez les pics d’utilisation du processeur/de la mémoire sur le serveur durant le démarrage. Vous devrez peut-être décaler le processus de démarrage de plusieurs applications.

500.38 DLL d’application ANCM introuvable

ANCM n’a pas pu localiser la DLL d’application, qui doit se trouver à côté de l’exécutable.

Cette erreur se produit lors de l’hébergement d’une application empaquetée en tant qu’exécutable à fichier unique à l’aide du modèle d’hébergement in-process. Le modèle in-process nécessite que l’ANCM charge l’application .NET Core dans le processus IIS existant. Ce scénario n’est pas pris en charge par le modèle de déploiement à fichier unique. Utilisez l’une des approches suivantes dans le fichier projet de l’application pour corriger cette erreur :

1. Désactivez la publication à fichier unique en définissant la propriété MSBuild PublishSingleFile sur false.
2. Basculez vers le modèle d’hébergement hors processus en définissant la propriété MSBuild AspNetCoreHostingModel sur OutOfProcess.

502.5 échec du processus

Le processus de travail échoue. L’application ne démarre pas.

Le module ASP.NET Core tente, en vain, de démarrer le processus de travail. Vous pouvez généralement déterminer la cause d’un échec de démarrage du processus à partir des entrées du Journal des événements de l’application et du journal stdout du module ASP.NET Core.

Une condition d’échec courante est une application mal configurée qui cible une version du framework partagé ASP.NET Core non présente. Vérifiez les versions du framework partagé ASP.NET Core qui sont installées sur l’ordinateur cible. Le framework partagé est le jeu d’assemblys (fichiers .dll) qui sont installés sur l’ordinateur et référencés par un métapaquet comme Microsoft.AspNetCore.App. La référence de métapaquet peut spécifier une version minimale requise. Pour plus d’informations, consultez Le framework partagé.

La page d’erreur d’un échec de processus 502.5 est retournée quand une erreur de configuration d’hébergement ou d’application entraîne l’échec du processus de travail :

Échec du démarrage de l’application (code d’erreur « 0x800700c1 »)

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

L’application n’a pas pu démarrer, car l’assembly de l’application (.dll) n’a pas pu être chargé.

Cette erreur se produit lorsqu’il existe une incompatibilité au niveau du nombre de bits entre l’application publiée et le processus w3wp/iisexpress.

Vérifiez que le paramètre 32 bits du pool d’applications est correct :

1. Sélectionnez le pool d’applications parmi les Pools d’applications IIS Manager.
2. Sélectionnez Paramètres avancés sous Modifier le pool d’applications dans le volet Actions.
3. Définissez Activer les applications 32 bits :
   • Si vous déployez une application 32 bits (x86), définissez la valeur sur True.
   • Si vous déployez une application 64 bits (x64), définissez la valeur sur False.

Vérifiez qu’il n’y a pas de conflit entre une propriété MSBuild <Platform> dans le fichier projet et le nombre de bits de l’application publié.

Échec du démarrage de l’application (code d’erreur « 0x800701b1 »)

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x800701b1'.

L’application n’a pas pu démarrer, car un service Windows n’a pas pu être chargé.

Un des service commun qui doit être activé est le service « null ». La commande suivante active le service Windows null :

sc.exe start null

Réinitialisation de la connexion

Si une erreur se produit après l’envoi des en-têtes, il est trop tard pour que le serveur puisse envoyer une erreur de serveur interne 500. C’est souvent le cas quand une erreur se produit pendant la sérialisation des objets complexes d’une réponse. Ce type d’erreur apparaît en tant qu’erreur de réinitialisation de la connexion sur le client. La journalisation des applications peut aider à le résoudre.

Limites de démarrage par défaut

Le module ASP.NET Core est configuré avec une valeur startupTimeLimit par défaut de 120 secondes. Quand cette valeur par défaut est conservée, une application peut mettre jusqu’à deux minutes à démarrer avant que le module ne consigne un échec de processus. Pour plus d’informations sur la configuration du module, voir Attributs de l’élément aspNetCore.

Résoudre les problèmes sur Azure App Service

Important

Préversions d’ASP.NET Core avec Azure App Service

Les préversions d’ASP.NET Core ne sont pas déployées sur Azure App Service par défaut. Pour héberger une application qui utilise une préversion d’ASP.NET Core, consultez Déployer la préversion d’ASP.NET Core sur Azure App Service.

Flux de journal d’Azure App Services

Le journal Azure App Services transmet les informations de journalisation à mesure qu’elles se produisent. Pour afficher les flux de journaux :

1. Dans le Portail Azure, ouvrez l’application dans App Services.
2. Dans le volet gauche, accédez à Surveillance>Journaux App Service.
3. Sélectionnez Système de fichiers pour la Journalisation du serveur Web. Activez éventuellement la journalisation des applications.
4. Dans le volet gauche, accédez à Surveillance>Flux de journaux, puis sélectionnez Journaux d’application ou Journaux de serveur Web.

Les images suivantes montrent la sortie des journaux d’application :

Les flux de journaux ont une certaine latence et peuvent ne pas s’afficher immédiatement.

Journal des événements des applications (Azure App Service)

Pour accéder au Journal des événements de l’application, utilisez le panneau Diagnostiquer et résoudre les problèmes du Portail Azure :

1. Dans le Portail Azure, ouvrez l’application dans App Services.
2. Sélectionnez Diagnostiquer et résoudre les problèmes.
3. Sélectionnez le titre Outils de diagnostic.
4. Sous Outils de support, sélectionnez le bouton Événements d’application.
5. Examinez la dernière erreur fournie par l’entrée IIS AspNetCoreModule ou IIS AspNetCoreModule V2 dans la colonne Source.

En dehors de la solution consistant à utiliser le panneau Diagnostiquer et résoudre les problèmes, vous pouvez examiner directement le fichier Journal des événements de l’application avec Kudu :

1. Ouvrez les Outils avancés dans la zone Outils de développement. Sélectionnez le bouton Atteindre. La console Kudu s’ouvre dans un nouvel onglet ou une nouvelle fenêtre du navigateur.
2. Dans la barre de navigation en haut de la page, ouvrez Console de débogage et sélectionnez CMD.
3. Ouvrez le fichier LogFiles .
4. Sélectionnez l’icône en forme de crayon à côté du fichier eventlog.xml.
5. Examinez le journal. Allez en bas du journal pour voir les événements les plus récents.

Exécuter l’application dans la console Kudu

De nombreuses erreurs de démarrage ne produisent pas d’informations utiles dans le Journal des événements de l’application. Vous pouvez exécuter l’application dans la console d’exécution à distance Kudu pour détecter l’erreur :

1. Ouvrez les Outils avancés dans la zone Outils de développement. Sélectionnez le bouton Atteindre. La console Kudu s’ouvre dans un nouvel onglet ou une nouvelle fenêtre du navigateur.
2. Dans la barre de navigation en haut de la page, ouvrez Console de débogage et sélectionnez CMD.

Tester une application 32 bits (x86)

Version actuelle

1. cd d:\home\site\wwwroot
2. Exécutez l’application :

   • Si l’application est un déploiement dépendant du framework :

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Si l’application est un déploiement autonome :

     {ASSEMBLY NAME}.exe
     

La sortie de la console de l’application, qui affiche les erreurs, est dirigée vers la console Kudu.

Déploiement dépendant du framework sur une préversion

Installation de l’extension de site du runtime ASP.NET Core {VERSION} (x86) requise.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} est la version du runtime).
2. Exécutez l’application : dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

La sortie de la console de l’application, qui affiche les erreurs, est dirigée vers la console Kudu.

Tester une application 64 bits (x64)

Version actuelle

• Si l’application est un déploiement dépendant du framework 64 bits (x64) :
  1. cd D:\Program Files\dotnet
  2. Exécutez l’application : dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Si l’application est un déploiement autonome :
  1. cd D:\home\site\wwwroot
  2. Exécutez l’application : {ASSEMBLY NAME}.exe

La sortie de la console de l’application, qui affiche les erreurs, est dirigée vers la console Kudu.

Déploiement dépendant du framework sur une préversion

Installation de l’extension de site du runtime ASP.NET Core {VERSION} (x64) requise.

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} est la version du runtime).
2. Exécutez l’application : dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

La sortie de la console de l’application, qui affiche les erreurs, est dirigée vers la console Kudu.

ASP.NET Core module stdout log (Azure App Service)

Avertissement

Si vous ne désactivez pas le journal stdout, l’application ou le serveur risque d’échouer. Il n’existe aucune limite quant à la taille du fichier journal ou au nombre de fichiers journaux créés. N’utilisez la journalisation stdout que pour résoudre les problèmes de démarrage de l’application.

Pour la journalisation générale dans une application ASP.NET Core après le démarrage, utilisez une bibliothèque de journalisation qui limite la taille du fichier journal et applique une rotation aux journaux. Pour plus d’informations, consultez Fournisseurs de journalisation tiers.

Le journal stdout du module ASP.NET Core enregistre souvent des messages d’erreur utiles et absents du Journal des événements de l’application. Pour activer et afficher les journaux stdout :

1. Dans le portail Azure, accéder à l’application web.
2. Dans le panneau App Service, entrez kudu dans la zone de recherche.
3. Sélectionnez Outils avancés>Go.
4. Sélectionnez Déboguer la console > CMD.
5. Accédez à site/wwwroot
6. Sélectionnez l’icône en forme de crayon pour modifier le fichier web.config.
7. Dans l’élément <aspNetCore />, définissez stdoutLogEnabled="true" et sélectionnez Enregistrer.

Désactivez la journalisation stdout lorsque la résolution des problèmes est terminée en définissant stdoutLogEnabled="false".

Pour plus d’informations, consultez Module ASP.NET Core (ANCM) pour IIS.

Journal de débogage du module ASP.NET Core (Azure App Service)

Le journal de débogage du module ASP.NET Core fournit une journalisation supplémentaire, plus approfondie, à partir du module ASP.NET Core. Pour activer et afficher les journaux stdout :

1. Pour activer le journal de diagnostic amélioré, effectuez l’une des opérations suivantes :
   • Suivez les instructions indiquées dans Journaux de diagnostic améliorés afin de configurer l’application pour une journalisation des diagnostics améliorée. Redéployez l’application.
   • Ajoutez le <handlerSettings> présenté dans Journaux de diagnostic améliorés au fichier web.config de l’application en production à l’aide de la console Kudu :
     1. Ouvrez les Outils avancés dans la zone Outils de développement. Sélectionnez le bouton Atteindre. La console Kudu s’ouvre dans un nouvel onglet ou une nouvelle fenêtre du navigateur.
     2. Dans la barre de navigation en haut de la page, ouvrez Console de débogage et sélectionnez CMD.
     3. Ouvrez les dossiers sur le chemin d’accès site>wwwroot. Modifiez le fichier web.config en sélectionnant le bouton représentant un crayon. Ajoutez la section <handlerSettings> comme indiqué dans Journaux de diagnostic améliorés. Sélectionnez le bouton Enregistrer.
2. Ouvrez les Outils avancés dans la zone Outils de développement. Sélectionnez le bouton Atteindre. La console Kudu s’ouvre dans un nouvel onglet ou une nouvelle fenêtre du navigateur.
3. Dans la barre de navigation en haut de la page, ouvrez Console de débogage et sélectionnez CMD.
4. Ouvrez les dossiers sur le chemin d’accès site>wwwroot. Si vous n’avez pas indiqué de chemin pour le fichier aspnetcore-debug.log, le fichier apparaît dans la liste. Si vous avez indiqué un chemin, accédez à l’emplacement du fichier journal.
5. Ouvrez le fichier journal à l’aide du bouton représentant un crayon à côté du nom de fichier.

Désactivez la journalisation du débogage, une fois la résolution des problèmes effectuée :

Pour désactiver la journalisation de débogage améliorée, effectuez l’une des opérations suivantes :

• Supprimez <handlerSettings> du fichier web.config localement, puis redéployez l’application.
• Utilisez la console Kudu pour modifier le fichier web.config et supprimer la section <handlerSettings>. Enregistrez le fichier .

Pour plus d’informations, consultez Création et redirection de journaux avec le module ASP.NET Core.

Avertissement

Si le journal de débogage n’est pas désactivé, cela peut entraîner une défaillance de l’application ou du serveur. Il n’existe aucune limite à la taille du fichier journal. Utilisez uniquement la journalisation de débogage pour résoudre les problèmes de démarrage d’application.

Pour la journalisation générale dans une application ASP.NET Core après le démarrage, utilisez une bibliothèque de journalisation qui limite la taille du fichier journal et applique une rotation aux journaux. Pour plus d’informations, consultez Fournisseurs de journalisation tiers.

Application lente ou suspendue (Azure App Service)

Si une application répond lentement ou se bloque sur une requête, consultez Résoudre les problèmes de performances d’une application web lente dans Azure App Service.

Panneaux Monitoring

Les panneaux Monitoring offrent une expérience de résolution des erreurs différente des méthodes décrites précédemment dans la rubrique. Ils peuvent servir à diagnostiquer les erreurs de la série 500.

Vérifiez que les extensions ASP.NET Core sont installées. Si ce n’est pas le cas, installez-les manuellement :

1. Dans la section du panneau OUTILS DE DÉVELOPPEMENT, sélectionnez le panneau Extensions.
2. Les Extensions ASP.NET Core devraient apparaître dans la liste.
3. Si les extensions ne sont pas installées, sélectionnez le bouton Ajouter.
4. Choisissez les Extensions ASP.NET Core dans la liste.
5. Sélectionnez OK pour accepter les conditions légales.
6. Sélectionnez OK sur le panneau Ajouter une extension.
7. Un message contextuel d’information indique que les extensions sont bien installées.

Si la journalisation stdout n’est pas activée, suivez les étapes ci-dessous :

1. Sur le Portail Azure, sélectionnez le panneau Outils avancés dans la zone OUTILS DE DÉVELOPPEMENT. Sélectionnez le bouton Atteindre. La console Kudu s’ouvre dans un nouvel onglet ou une nouvelle fenêtre du navigateur.
2. Dans la barre de navigation en haut de la page, ouvrez Console de débogage et sélectionnez CMD.
3. Ouvrez les dossiers sur le chemin d’accès site>wwwroot et faites défiler la page jusqu’à révéler le fichier web.config en bas de la liste.
4. Cliquez sur l’icône en forme de crayon à côté du fichier web.config.
5. Définissez stdoutLogEnabled sur true et remplacez le chemin stdoutLogFile par : \\?\%home%\LogFiles\stdout.
6. Sélectionnez Enregistrer pour enregistrer le fichier web.config mis à jour.

Maintenant, activez la journalisation des diagnostics :

1. Sur le Portail Azure, sélectionnez le panneau Journaux de diagnostic.
2. Basculez Journalisation des applications (système de fichiers) et Messages d’erreur détaillés sur Activé. Sélectionnez le bouton Enregistrer en haut du panneau.
3. Pour inclure le suivi des demandes ayant échoué, également appelé Mise en mémoire tampon des événements d’échec des demandes (FREB), basculez Suivi des demandes ayant échoué sur Activé.
4. Sélectionnez le panneau Flux du journal situé juste sous le panneau Journaux de diagnostic sur le portail.
5. Adressez une requête à l’application.
6. La cause de l’erreur est indiquée dans les données de flux de journal.

Veillez à désactiver la journalisation stdout une fois la résolution des problèmes effectuée.

Pour afficher les journaux de suivi des demandes ayant échoué (journaux FREB) :

1. Accédez au panneau Diagnostiquer et résoudre les problèmes du Portail Azure.
2. Sélectionnez Journaux de suivi des demandes ayant échoué dans la zone OUTILS DE PRISE EN CHARGE de la barre latérale.

Voir la section Traces des demandes ayant échoué de la rubrique Activer la journalisation des diagnostics pour les applications web dans Azure App Service et FAQ sur les performances des applications web dans Azure : comment activer le suivi des demandes ayant échoué ? pour plus d’informations.

Pour plus d’informations, voir Activer la journalisation des diagnostics pour les applications web dans Azure App Service.

Avertissement

Si vous ne désactivez pas le journal stdout, l’application ou le serveur risque d’échouer. Il n’existe aucune limite quant à la taille du fichier journal ou au nombre de fichiers journaux créés.

Pour les opérations de journalisation courantes dans une application ASP.NET Core, utilisez une bibliothèque de journalisation qui limite la taille du fichier journal et applique une rotation aux journaux. Pour plus d’informations, consultez Fournisseurs de journalisation tiers.

Résoudre les problèmes sur IIS

Journal des événements d’application (IIS)

Accédez au Journal des événements de l’application :

1. Ouvrez le menu Démarrer, recherchez Observateur d’événements, puis sélectionnez l’application Observateur d’événements.
2. Dans Observateur d’événements, ouvrez le nœud Journaux Windows.
3. Sélectionnez Application pour ouvrir le Journal des événements de l’application.
4. Recherchez les erreurs liées à l’application défectueuse. Les erreurs sont signalées par une valeur IIS AspNetCore Module (Module AspNetCore IIS) ou IIS Express AspNetCore Module (Module AspNetCore IIS Express) dans la colonne Source.

Exécuter l’application depuis une invite de commandes

De nombreuses erreurs de démarrage ne produisent pas d’informations utiles dans le Journal des événements de l’application. Vous pouvez trouver la cause de certaines erreurs en exécutant l’application depuis une invite de commandes sur le système hôte.

Déploiement dépendant du framework

Si l’application est un déploiement dépendant du framework :

1. Depuis une invite de commandes, accédez au dossier de déploiement et exécutez l’application en exécutant l’assembly de l’application avec dotnet.exe. Dans la commande suivante, substituez le nom de l’assembly de l’application pour <assembly_name> : dotnet .\<assembly_name>.dll.
2. La sortie de console de l’application est écrite dans la fenêtre de console, affichant toutes les erreurs éventuelles.
3. Si les erreurs se produisent pendant qu’une requête est adressée à l’application, effectuez une requête en direction de l’hôte et du port sur lequel Kestrel écoute. À l’aide de l’hôte et du port par défaut, faites une requête en direction de http://localhost:5000/. Si l’application répond normalement à l’adresse de point de terminaison Kestrel, le problème est probablement lié à la configuration de l’hébergement plutôt qu’à l’application.

Déploiement autonome

Si l’application est un déploiement autonome :

1. Depuis une invite de commandes, accédez au dossier de déploiement et exécutez l’exécutable de l’application. Dans la commande suivante, substituez le nom de l’assembly de l’application pour <assembly_name> : <assembly_name>.exe.
2. La sortie de console de l’application est écrite dans la fenêtre de console, affichant toutes les erreurs éventuelles.
3. Si les erreurs se produisent pendant qu’une requête est adressée à l’application, effectuez une requête en direction de l’hôte et du port sur lequel Kestrel écoute. À l’aide de l’hôte et du port par défaut, faites une requête en direction de http://localhost:5000/. Si l’application répond normalement à l’adresse de point de terminaison Kestrel, le problème est probablement lié à la configuration de l’hébergement plutôt qu’à l’application.

Journal stdout du module ASP.NET Core (IIS)

Pour activer et afficher les journaux stdout :

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 et créer le dossier logs dans le déploiement automatiquement, consultez la rubrique Structure des répertoires.
3. Modifiez le fichier web.config. Définissez stdoutLogEnabled sur true et faites pointer le chemin stdoutLogFile vers le dossier logs (par exemple, .\logs\stdout). Dans le chemin, stdout est le préfixe du nom du fichier journal. Un horodatage, un ID de processus et une extension de fichier sont ajoutés automatiquement quand le journal est créé. Si stdout est utilisé comme préfixe du nom de fichier, un fichier journal classique porte le nom stdout_20180205184032_5412.log.
4. Vérifiez que l’identité de votre pool d’applications dispose des autorisations d’écriture sur le dossier logs.
5. Enregistrez le fichier web.config mis à jour.
6. Adressez une requête à l’application.
7. Accédez au dossier logs. Recherchez et ouvrez le journal stdout le plus récent.
8. Déterminez si le journal contient des erreurs.

Désactivez la journalisation stdout, une fois les problèmes résolus :

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

Pour plus d’informations, consultez Module ASP.NET Core (ANCM) pour IIS.

Avertissement

Si vous ne désactivez pas le journal stdout, l’application ou le serveur risque d’échouer. Il n’existe aucune limite quant à la taille du fichier journal ou au nombre de fichiers journaux créés.

Pour les opérations de journalisation courantes dans une application ASP.NET Core, utilisez une bibliothèque de journalisation qui limite la taille du fichier journal et applique une rotation aux journaux. Pour plus d’informations, consultez Fournisseurs de journalisation tiers.

Journal de débogage du module ASP.NET Core (IIS)

Ajoutez les paramètres de gestionnaire suivants au fichier web.config de l’application pour activer le journal de débogage du module ASP.NET Core :

<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 des autorisations en écriture pour l’emplacement.

Pour plus d’informations, consultez Création et redirection de journaux avec le module ASP.NET Core.

Afficher la page d’exception de développeur

Vous pouvez ajouter la variable d’environnement ASPNETCORE_ENVIRONMENT au fichier web.config pour exécuter l’application dans l’environnement de développement. Tant que l’environnement n’est pas substitué dans le démarrage de l’application par UseEnvironment sur le générateur de l’hôte, la définition de la variable d’environnement permet à la page d’exception de développeur d’apparaître quand l’application est exécutée.

<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 ASPNETCORE_ENVIRONMENT est recommandée uniquement en vue d’une utilisation sur les serveurs de préproduction et de test qui ne sont pas exposés à Internet. Supprimez la variable d’environnement du fichier web.config une fois la résolution des problèmes effectuée. Pour plus d’informations sur la définition des variables d’environnement dans web.config, consultez la section sur l’élément enfant environmentVariables d’aspNetCore.

Obtenir des données à partir d’une application

Si une application est capable de répondre aux requêtes, obtenez des informations sur une requête, une connexion et d’autres informations supplémentaires à partir d’une application à l’aide de l’intergiciel en ligne terminal. Pour plus d’informations et pour obtenir un exemple de code, consultez Résoudre les problèmes et déboguer les projets ASP.NET Core.

Application lente ou bloquée (IIS)

Un fichier image mémoire après incident est un instantané de la mémoire système et peut aider à déterminer la cause de l’arrêt d’une application, d’un échec de démarrage ou de la lenteur d’une application.

L’application cesse de fonctionner ou rencontre une exception

Obtenez un fichier dump et analysez-le depuis le Rapport d'erreurs Windows :

1. Créez un dossier pour accueillir les fichiers d’image mémoire dans c:\dumps. Le pool d’application doit disposer des accès d’écriture dans le dossier.

2. Exécutez le script PowerShell EnableDumps :

   • Si l’application utilise le modèle d’hébergement in-process, exécutez le script pour w3wp.exe :

     .\EnableDumps w3wp.exe c:\dumps
     

   • Si l’application utilise le modèle d’hébergement out-of-process, exécutez le script pour dotnet.exe :

     .\EnableDumps dotnet.exe c:\dumps
     

3. Exécutez l’application en reproduisant les conditions ayant entraîné l’incident.

4. Une fois l’incident survenu, exécutez le script PowerShell DisableDumps :

   • Si l’application utilise le modèle d’hébergement in-process, exécutez le script pour w3wp.exe :

     .\DisableDumps w3wp.exe
     

   • Si l’application utilise le modèle d’hébergement out-of-process, exécutez le script pour dotnet.exe :

     .\DisableDumps dotnet.exe
     

Après l’arrêt de l’application et après avoir terminé la collection dump, l’application peut être fermée normalement. Le script PowerShell configure le rapport d’erreurs Windows pour collecter jusqu'à cinq fichiers dump par application.

Avertissement

Les fichiers dump d’incident peuvent occuper plus d’espace disque (jusqu’à plusieurs gigaoctets par fichier).

L’application se bloque, ne démarre pas ou s’exécute normalement

Lorsqu’une application se bloque (cesse de répondre mais ne se bloque pas), échoue au démarrage ou s’exécute normalement, consultez Fichiers d’image mémoire en mode utilisateur : choisir le meilleur outil pour sélectionner un outil approprié pour produire l’image mémoire.

Analyser le fichier dump

Un fichier dump peut être analysé à l’aide de plusieurs approches. Pour plus d’informations, consultez Analyzing a User-Mode Dump File (Analyser un fichier dump en mode utilisateur).

Effacer les caches de package

Une application fonctionnelle peut échouer immédiatement après la mise à niveau du kit SDK .NET Core sur l’ordinateur de développement ou la modification des versions de package au sein de l’application. Dans certains cas, les packages incohérents peuvent bloquer une application quand vous effectuez des mises à niveau majeures. Vous pouvez résoudre la plupart de ces problèmes en suivant les instructions suivantes :

1. Supprimez les dossiers bin et obj.

2. Effacez les caches de package en exécutant dotnet nuget locals all --clear à partir d’un interpréteur de commandes.

   Vous pouvez également effacer les caches de package en utilisant l’outil nuget.exe et en exécutant la commande nuget locals all -clear. NuGet.exe n’étant pas une installation fournie avec le système d’exploitation de bureau Windows, il doit être obtenu séparément à partir du site web de NuGet.

3. Restaurez et regénérez le projet.

4. Supprimez tous les fichiers du dossier de déploiement sur le serveur avant de redéployer l’application.

Ressources supplémentaires

• Déboguer du code source .NET et ASP.NET Core avec Visual Studio
• Résoudre les problèmes et effectuer le débogage des projets ASP.NET Core
• Résolution des problèmes courants pour Azure App Service et IIS avec ASP.NET Core
• Gérer les erreurs dans ASP.NET Core
• Module ASP.NET Core Module (ANCM) pour IIS

Documentation Azure

• Application Insights pour ASP.NET Core
• Section de débogage à distance d’applications web de Résoudre les problèmes d’une application web dans Azure App Service avec Visual Studio
• Présentation des diagnostics Azure App Service
• Surveillance des applications dans Azure App Service
• Dépanner une application web dans le Service d’application Microsoft Azure à l’aide de Visual Studio
• Résoudre les erreurs HTTP de type « 502 Passerelle incorrecte » et « 503 Service indisponible » dans vos applications web Azure
• Résoudre les problèmes de baisse de performances d’une application web dans Azure App Service
• FAQ sur les performances des applications web Azure dans Azure
• Bac à sable des applications web Azure (limitations de l’exécution du runtime App Service)

Documentation de Visual Studio

• Débogage à distance d’ASP.NET Core sur IIS dans Azure dans Visual Studio 2017
• Débogage à distance d’ASP.NET Core sur un ordinateur IIS distant dans Visual Studio 2017
• Apprendre à déboguer avec Visual Studio

Documentation de Visual Studio Code

• Débogage avec Visual Studio Code