Je viens de déployer une mise à jour sur un site ASP.NET MVC3 existant (il était déjà configuré) et j'obtiens l'écran bleu de la mort d'IIS indiquant
Erreur HTTP 500.0 - Erreur de serveur interne
La page ne peut être affichée car une erreur de serveur interne s'est produite.
Cependant, rien n'apparaît dans le journal des événements de l'application où je m'attendrais à voir une description (plus) détaillée de l'entrée.
Comment puis-je diagnostiquer ce problème ?
Jetez un coup d'œil à la fonction de traçage des requêtes échouées de IIS7 :
Dépannage des requêtes échouées à l'aide du traçage dans IIS 7
Dépannage avec le suivi des requêtes échouées
L'autre chose que je ferais est de modifier votre <httpErrors> car IIS peut avaler un message d'erreur provenant d'un autre endroit :
<configuration>
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
</configuration>Si le site est écrit en ASP classique, assurez-vous d'activer l'option d'accès à l'information. Envoyer les erreurs au navigateur dans la fonction de configuration de l'ASP :
Enfin, si vous utilisez Internet Explorer, assurez-vous d'avoir désactivé la fonction Afficher des messages d'erreur HTTP conviviaux dans les paramètres avancés (mais je suppose que vous l'avez déjà fait ou que vous utilisez un autre navigateur).
Dans mon cas :
web.config n'était pas corrompu - vérifié en utilisant le même sur la machine locale / en utilisant inetmgr
Enfin...
...Chrome/57.0.2987.133+Safari/537.36 500 19 5 312
La clé étant :
sc-status sc-substatus sc-win32-status 500 19 5
ce qui, avec un peu de google, m'a conduit à l'adresse suivante IIS_USRS n'ayant pas les droits de lecture sur le www dossier
Le problème le plus évident est l'absence ou l'insuffisance des droits NTFS sur le dossier de l'application Web. Il faut donc s'assurer que le compte qui dessert le site a les bonnes permissions. Sans droits NTFS appropriés sur le répertoire web, ce que vous mettez dans le web.config n'a aucune importance car il ne sera jamais lu.
Une vérification rapide peut consister à donner à chacun tous les droits - si le site commence à fonctionner, vous savez qu'il s'agit d'un problème de droits et vous pouvez alors vous atteler à attribuer les droits appropriés à un compte plus approprié.
Si vous effectuez une mise à jour à partir de IIS6, il se peut que l'un des web.config fonctionne sur 6, mais pas dans IIS 7.5 ... Double-cliquez sur toutes les icônes du site Web dans IIS et vous obtiendrez peut-être une erreur concernant le format (la section doit se trouver sous une autre section...).
J'ai eu le même problème avec une Azure Web App. Lors du débogage local, les messages d'erreur (JSON) renvoyés par les appels ajax étaient entièrement renvoyés au navigateur. Mais une fois déployés dans l'application Web, les messages étaient avalés et j'ai reçu un message d'erreur 500 par défaut. J'ai donc dû définir explicitement le paramètre existingResponse à la valeur PassThrough dans le web.config httpErrors étiquette.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
