Modo CustomErrors = "Apagado"

Recibo un error cada vez que subo mi aplicación web al proveedor. Debido al modo customErrors, todo lo que veo es el mensaje predeterminado "Error de tiempo de ejecución", que me indica que apague customErrors para ver más sobre el error.

Exasperado, configuré mi web.config para que se vea así:

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

Y aún así, todo lo que obtengo es la estúpida página de errores remotos sin información útil. ¿Qué más puedo hacer para desactivar CustomErrors?

Esto me ha vuelto loco durante los últimos días y no pude evitarlo, pero finalmente lo descubrí:

En mi archivo machine.config tenía una entrada en <system.web>:

<deployment retail="true" />

Esto parece anular cualquier otra configuración de CustomError que haya especificado en un archivo web.config, por lo que debe configurar la entrada anterior en:

<deployment retail="false" />

ahora significa que una vez más puedo ver los mensajes de error detallados que necesito.

El machine.configse encuentra en

32 bits

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

64 bits

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

Espero que ayude a alguien y ahorre unas horas de tirones de cabello.

"Desactivado" distingue entre mayúsculas y minúsculas.

Compruebe si la "O" está en mayúscula en su archivo web.config, lo he sufrido varias veces (por simple que parezca)

En el interés de agregar más situaciones a esta pregunta (porque aquí es donde busqué porque tenía exactamente el mismo problema), esta es mi respuesta:

En mi caso, corté / pegué el texto del error genérico que decía en efecto si quieres ver qué pasa, pon

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

Así que esto debería haberlo solucionado, ¡pero por supuesto que no! Mi problema era que había un nodo <system.web> varias líneas arriba (antes de un nodo de compilación y autenticación), y una etiqueta de cierre </system.web> unas pocas líneas debajo de eso. Una vez que corregí esto, OK, el problema se resolvió. Lo que debería haber hecho es copiar / pegar solo esta línea:

<customErrors mode="Off"/>

Esto es de los anales de Stupid Things que sigo haciendo una y otra vez, en el capítulo titulado "Copie y pegue su camino hacia la destrucción".

Para las aplicaciones de Sharepoint 2010, también debe editar C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\web.configy definir<customErrors mode="Off" />

Probé la mayoría de las cosas descritas aquí. Estaba usando VWD y el archivo web.config predeterminado contenía:

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

Cambié mode = "RemoteOnly" a mode = "Off". Aún no hay alegría. Luego utilicé el administrador IIS, las propiedades, la pestaña ASP.Net, Editar configuración, luego elegí la pestaña CustomeErrors. Esto todavía mostró RemoteOnly. Cambié esto a Off y finalmente pude ver los mensajes de error detallados.

Cuando inspeccioné web.config, vi que había dos nodos CustomErrors en system.web; y acabo de notar que la segunda entrada (la que estaba cambiando estaba dentro de un comentario). Intente no usar el bloc de notas para inspeccionar web.config en un servidor remoto.

Sin embargo, si usa el material de configuración de edición de IIS, se quejará de errores en web.config. Luego puede descartar todas las respuestas que dicen "¿hay un error de sintaxis XML en su web.config"?

La única respuesta que realmente funcionó para solucionar esto la encontré aquí: https://stackoverflow.com/a/18938991/550975

Simplemente agregue esto a su web.config:

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

En general, puede encontrar más información sobre el error en el Visor de eventos, si tiene acceso a él. Es posible que su proveedor también haya evitado que se muestren errores personalizados, ya sea sobrescribiéndolo en su machine.config o configurando el atributo minorista como verdadero ( http://msdn.microsoft.com/en-us/library/ms228298 ( VS.80) .aspx ).

También tuve este problema, pero cuando usaba Apache y mod_mono. Para cualquier otra persona en esa situación, debe reiniciar Apache después de cambiar web.config para forzar la lectura de la nueva versión.

Si todavía está recibiendo esa página, es probable que esté explotando antes de pasar la Web.

Asegúrese de que ASP.Net tiene los permisos que necesita para cosas como las carpetas de .Net Framework, la Metabase de IIS, etc. ¿Tiene alguna forma de verificar que ASP.Net esté instalado correctamente y asociado en IIS correctamente?

Editar: después de que se me ocurrió el comentario de Greg, supuse que lo que publicaste era tu web.config muy mínima, ¿hay más? Si es así, ¿puedes publicar todo el web.config?

Mi problema fue que tenía esto definido en mi 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 realidad, lo que descubrí al alojar mi aplicación web es que el código que desarrolló en su máquina local es de una versión superior a la que le ofrece la empresa de alojamiento. Si tiene privilegios de administrador, puede cambiar la compatibilidad con la versión de Microsoft ASP.NET en la configuración de alojamiento web

Tuvimos este problema y se debió a que el usuario de IIS no tenía acceso a la configuración de la máquina en el servidor web.

También nos encontramos con este error y en nuestro caso fue porque el usuario del grupo de aplicaciones ya no tenía permisos para el archivo web.config. La razón por la que perdió sus permisos (todo estaba bien antes) fue porque teníamos una copia de seguridad del sitio en un archivo rar y arrastré una versión de copia de seguridad de web.config desde el rar al sitio. Esto parece haber eliminado todos los permisos para el archivo web.config, excepto para mí, el usuario conectado.

Nos tomó un tiempo resolver esto porque revisé repetidamente los permisos en el nivel de carpeta, pero nunca en el nivel de archivo.

Tuve el mismo problema pero encontré la resolución de una manera diferente.

-

Lo que hice fue abrir Configuración avanzada para el grupo de aplicaciones en el Administrador IIS .

Allí configuré Habilitar aplicaciones de 32 bits en Verdadero .

Intente reiniciar la aplicación (crear un app_offline.htm que eliminarlo) y si aún recibe el mismo mensaje de error, asegúrese de que solo haya declarado customErrors una vez en web.config, o algo así. Los errores en web.config pueden tener un impacto extraño en la aplicación.

¿Tienes algún personaje especial como æøå en tu web.config? Si es así, asegúrese de que la codificación esté establecida en utf-8.

¿Está esta aplicación web configurada debajo de otras aplicaciones en el árbol de directorios de un sitio web? Verifique cualquier archivo web.config principal para otras configuraciones, si las hay. Además, haga que su directorio esté configurado como un directorio de aplicaciones en IIS.

Si está utilizando la vista previa 4 de MVC, podría estar experimentando esto porque está utilizando el atributo HandleErrorAttribute. El comportamiento cambió en 5 para que no maneje excepciones si desactiva los errores personalizados.

También puede intentar abrir el sitio web en un navegador en la máquina del servidor. No hago mucho desarrollo de ASP.NET, pero recuerdo que los errores personalizados tienen una configuración para mostrar solo el texto de error completo en el servidor, como medida de seguridad.

Acabo de tratar un problema similar. En mi caso, la versión predeterminada del sitio asp.net era 1.1 mientras intentaba iniciar una aplicación web 2.0. El error fue bastante trivial, pero no estaba claro de inmediato por qué los errores personalizados no desaparecerían, y el tiempo de ejecución nunca escribió en el registro de eventos. La solución obvia era hacer coincidir la versión en la pestaña Asp.Net de IIS.

También asegúrese de editar web.config y no website.config, como estaba haciendo.

He tenido el mismo problema, y ​​la causa fue que IIS estaba ejecutando ASP.NET 1.1, y el sitio requería .NET 2.0.

El mensaje de error no hizo nada más que desviarme durante varias horas.

Asegúrate de agregar justo después del sistema.web

Lo puse hacia el final del nodo y no funcionó.

Si está realizando una transformación de configuración, es posible que también deba eliminar la siguiente línea del archivo web.config correspondiente.

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

Después de haber intentado todas las respuestas aquí, resultó que mi Application_Errormétodo tenía esto:

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

Eliminar estas líneas y configurarlo solucionó el problema. (El cliente aún fue redirigido a la página de error con customErrors="On").

Tuve el mismo problema y revisé el registro de la aplicación Visor de eventos donde menciona claramente debido a qué excepción sucedió esto. En mi caso, la excepción fue la siguiente ...

Información de excepción:

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.

Acabo de actualizar mi contraseña en el grupo de aplicaciones y funciona para mí.

También es posible en algunos casos que web.config no esté formateado correctamente. En ese caso, debe revisarlo línea por línea antes de que funcione. A menudo, las reglas de reescritura son las culpables aquí.

Eso es realmente extraño Recibí este error y después de reiniciar mi servidor desapareció.

Para mí fue un error más arriba en la web.config sobre el system.web.

el archivo bla no existía, por lo que arrojaba un error en ese momento. Debido a que aún no había llegado a la sección System.Web, todavía estaba usando la configuración predeterminada del servidor para CUstomErrors (Activado)