Mode CustomErrors = «Off»

Je reçois une erreur chaque fois que je télécharge ma webapp vers le fournisseur. En raison du mode customErrors, tout ce que je vois est le message par défaut "Erreur d'exécution", me demandant de désactiver customErrors pour en savoir plus sur l'erreur.

Exaspéré, j'ai configuré mon web.config pour qu'il ressemble à ceci:

<?xml version="1.0"?>
<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>

Et pourtant, tout ce que j'obtiens, c'est la stupide page des erreurs à distance sans aucune information utile. Que puis-je faire d'autre pour désactiver CustomErrors?!

Cela m'a rendu fou ces derniers jours et je n'ai pas pu le contourner, mais j'ai finalement compris:

Dans mon fichier machine.config, j'avais une entrée sous <system.web>:

<deployment retail="true" />

Cela semble remplacer tous les autres paramètres customError que vous avez spécifiés dans un fichier web.config, donc définissez l'entrée ci-dessus sur:

<deployment retail="false" />

signifie maintenant que je peux à nouveau voir les messages d'erreur détaillés dont j'ai besoin.

Le machine.configest situé à

32 bits

%windir%\Microsoft.NET\Framework\[version]\config\machine.config

64 bits

%windir%\Microsoft.NET\Framework64\[version]\config\machine.config 

J'espère que cela aide quelqu'un là-bas et permet d'économiser quelques heures de cheveux.

"Off" est sensible à la casse.

Vérifiez si le "O" est en majuscule dans votre fichier web.config, j'ai souffert plusieurs fois (aussi simple que cela puisse paraître)

Dans l'intérêt d'ajouter plus de situations à cette question (parce que c'est là que j'ai regardé parce que j'avais exactement le même problème), voici ma réponse:

Dans mon cas, j'ai coupé / collé le texte de l'erreur générique en disant que si vous voulez voir ce qui ne va pas, mettez

<system.web>
   <customErrors mode="Off"/>
</system.web>

Donc, cela aurait dû le réparer, mais bien sûr que non! Mon problème était qu'il y avait un nœud <system.web> plusieurs lignes au-dessus (avant un nœud de compilation et d'authentification), et une balise de fermeture </system.web> quelques lignes en dessous. Une fois que j'ai corrigé cela, OK, le problème a été résolu. Ce que j'aurais dû faire, c'est copier / coller uniquement cette ligne:

<customErrors mode="Off"/>

Ceci est tiré des annales des choses stupides que je continue de faire encore et encore, dans le chapitre intitulé "Copiez et collez votre chemin vers la destruction".

Pour les applications Sharepoint 2010, vous devez également modifier C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\web.configet définir<customErrors mode="Off" />

J'ai essayé la plupart des trucs décrits ici. J'utilisais VWD et le fichier web.config par défaut contenait:

    <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
        <error statusCode="403" redirect="NoAccess.htm" />
        <error statusCode="404" redirect="FileNotFound.htm" />
    </customErrors>

J'ai changé le mode = "RemoteOnly" en mode = "Off". Toujours pas de joie. J'ai ensuite utilisé le gestionnaire IIS, les propriétés, l'onglet ASP.Net, Modifier la configuration, puis j'ai choisi l'onglet CustomeErrors. Cela montrait toujours RemoteOnly. J'ai changé cela en Off et j'ai finalement pu voir les messages d'erreur détaillés.

Quand j'ai inspecté le web.config, j'ai vu qu'il y avait deux nœuds CustomErrors dans le system.web; et je viens de remarquer que la deuxième entrée (celle que je modifiais était dans un commentaire). Essayez donc de ne pas utiliser le bloc-notes pour inspecter web.config sur un serveur distant.

Cependant, si vous utilisez les éléments de configuration d'édition IIS, il se plaindra d'erreurs dans le web.config. Ensuite, vous pouvez exclure toutes les réponses qui disent "y a-t-il une erreur de syntaxe XML dans votre web.config"

La seule réponse qui a réellement travaillé pour résoudre ce problème, je l'ai trouvée ici: https://stackoverflow.com/a/18938991/550975

Ajoutez simplement ceci à votre web.config:

<configuration>  
  <system.webServer>  
    <httpErrors existingResponse="PassThrough"/>  
  </system.webServer>  
<configuration>

Vous pouvez généralement trouver plus d'informations concernant l'erreur dans l'Observateur d'événements, si vous y avez accès. Votre fournisseur peut également avoir empêché l'affichage d'erreurs personnalisées, soit en le remplaçant dans leur machine.config, soit en définissant l'attribut retail sur true ( http://msdn.microsoft.com/en-us/library/ms228298 ( VS.80) .aspx ).

J'ai également eu ce problème, mais lors de l'utilisation d'Apache et de mod_mono. Pour toute autre personne dans cette situation, vous devez redémarrer Apache après avoir changé web.config pour forcer la lecture de la nouvelle version.

Si vous obtenez toujours cette page, il est probable qu'elle explose avant de passer sur le Web.

Assurez-vous qu'ASP.Net dispose des autorisations dont il a besoin pour des choses comme les dossiers .Net Framework, la métabase IIS, etc. Avez-vous un moyen de vérifier qu'ASP.Net est installé correctement et associé correctement dans IIS?

Edit: Après le commentaire de Greg, il m'est venu à l'esprit que j'ai supposé que ce que vous avez publié était votre web.config très minimal, y a-t-il plus? Si oui, pouvez-vous publier l'intégralité de web.config?

Mon problème était que je l'avais défini dans mon web.config

<httpErrors errorMode="Custom" existingResponse="Replace">
  <remove statusCode="404" />
  <remove statusCode="500" />
  <error statusCode="404" responseMode="ExecuteURL" path="/Error/NotFound" />
  <error statusCode="500" responseMode="ExecuteURL" path="/Error/Internal" />
</httpErrors>

En fait, ce que j'ai découvert lors de l'hébergement de mon application Web, c'est que le code que vous avez développé sur votre machine locale est d'une version supérieure à celle que la société d'hébergement vous propose. Si vous avez des privilèges d'administrateur, vous pourrez peut-être modifier la prise en charge de la version Microsoft ASP.NET sous le paramètre d'hébergement Web

Nous avons eu ce problème et cela était dû au fait que l'utilisateur IIS n'avait pas accès à la configuration de la machine sur le serveur Web.

Nous avons également rencontré cette erreur et dans notre cas, c'est parce que l'utilisateur du pool d'applications n'avait plus les autorisations sur le fichier web.config. La raison pour laquelle il a perdu ses autorisations (tout allait bien avant) était parce que nous avions une sauvegarde du site dans un fichier rar et j'ai fait glisser une version de sauvegarde du web.config de la rar vers le site. Cela semble avoir supprimé toutes les autorisations sur le fichier web.config à l'exception de moi, l'utilisateur connecté.

Il nous a fallu un certain temps pour comprendre cela car j'ai vérifié à plusieurs reprises les autorisations au niveau du dossier, mais jamais au niveau du fichier.

J'ai eu le même problème mais j'ai trouvé une solution d'une manière différente.

-

Ce que j'ai fait, c'est que j'ai ouvert les paramètres avancés du pool d'applications dans le Gestionnaire des services Internet .

Là, j'ai défini l' option Activer les applications 32 bits sur True .

Essayez de redémarrer l'application (en créant un app_offline.htm plutôt que de le supprimer) et si vous obtenez toujours le même message d'erreur, assurez-vous que vous n'avez déclaré customErrors qu'une seule fois dans le web.config, ou quelque chose comme ça. Les erreurs dans le web.config peuvent avoir un impact étrange sur l'application.

Avez-vous un caractère spécial comme æøå dans votre web.config? Si c'est le cas, assurez-vous que l'encodage est réglé sur utf-8.

Cette application Web est-elle définie sous d'autres applications dans l'arborescence de répertoires d'un site Web? Vérifiez tous les fichiers web.config parent pour d'autres paramètres, le cas échéant. En outre, définissez votre répertoire comme un répertoire d'application dans IIS.

Si vous utilisez l'aperçu MVC 4, vous pouvez rencontrer ce problème car vous utilisez HandleErrorAttribute. Le comportement a changé en 5 afin qu'il ne gère pas les exceptions si vous désactivez les erreurs personnalisées.

Vous pouvez également essayer d'afficher le site Web dans un navigateur sur la machine serveur. Je ne fais pas beaucoup de développement ASP.NET, mais je me souviens que la chose des erreurs personnalisées a un paramètre pour afficher uniquement le texte d'erreur complet sur le serveur, par mesure de sécurité.

Je viens de traiter d'un problème similaire. Dans mon cas, la version par défaut du site asp.net était 1.1 alors que j'essayais de démarrer une application web 2.0. L'erreur était assez banale, mais il n'était pas immédiatement clair pourquoi les erreurs personnalisées ne disparaissaient pas, et le runtime n'a jamais écrit dans le journal des événements. Le correctif évident consistait à faire correspondre la version dans l'onglet Asp.Net d'IIS.

Assurez-vous également que vous modifiez web.config et non website.config, comme je le faisais.

J'ai eu le même problème et la cause était qu'IIS exécutait ASP.NET 1.1 et que le site exigeait .NET 2.0.

Le message d'erreur n'a fait que me jeter hors de piste pendant plusieurs heures.

Assurez-vous d'ajouter juste après le system.web

Je l'ai mis vers la fin du nœud et je n'ai pas fonctionné.

Si vous effectuez une transformation de configuration, vous devrez peut-être également supprimer la ligne suivante du fichier web.config correspondant.

<compilation xdt:Transform="RemoveAttributes(debug)" />

Après avoir essayé toutes les réponses ici, il s'est avéré que ma Application_Errorméthode avait ceci:

Server.ClearError();
Response.Redirect("/Home/Error");

La suppression de ces lignes et la configuration ont résolu le problème. (Le client est toujours redirigé vers la page d'erreur avec customErrors="On").

J'ai eu le même problème, et j'ai parcouru le journal des applications de l'Observateur d'événements où il mentionne clairement en raison de quelle exception cela s'est produit. Dans mon cas, l'exception était comme ci-dessous ...

Informations sur les exceptions:

Exception type: HttpException 
Exception message: The target principal name is incorrect.  Cannot generate SSPI context.
at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

The target principal name is incorrect.  Cannot generate SSPI context.

Je viens de mettre à jour mon mot de passe dans le pool d'applications et cela fonctionne pour moi.

Il est également possible dans certains cas que web.config ne soit pas formaté correctement. Dans ce cas, vous devez le parcourir ligne par ligne avant que cela fonctionne. Souvent, les règles de réécriture sont le coupable ici.

C'est vraiment étrange. J'ai eu cette erreur et après le redémarrage de mon serveur, elle a disparu.

Pour moi, c'était une erreur plus haut dans le web.config au-dessus du system.web.

le fichier blah n'existait pas, il générait alors une erreur. Parce qu'il n'était pas encore arrivé à la section System.Web mais qu'il utilisait le paramètre par défaut du serveur pour CUstomErrors (On)