¿Por qué mi aplicación asp.net arroja ThreadAbortException?

Question

pregunta que se explica por sí misma.

¿Por qué esta cosa burbujea en mis capturas de prueba incluso cuando no pasa nada?

¿Por qué aparece en mi registro cientos de veces?

Sé que es una pregunta para principiantes, pero si este sitio va a obtener un ranking de búsqueda y atraer a nuevos usuarios, tenemos que preguntarles.

Answer 1

Probablemente esto provenga de una llamada Response.Redirect.Consulte este enlace para obtener una explicación:

http://dotnet.org.za/armand/archive/2004/11/16/7088.aspx

(En la mayoría de los casos, llamar a Response.Redirect(url, false) soluciona el problema)

Answer 2

La razón más común para una ThreadAbortException es llamar Respuesta.Fin, Respuesta.Redireccionamiento o Servidor.Transferencia.Microsoft ha publicado algunas funciones sugeridas que deberían usarse en lugar de esas funciones.

Answer 3

Como han dicho otros, ocurre cuando llamas a Response.End() (lo que ocurre cuando llamas a Response.Redirect sin pasar false como segundo parámetro).Esto está funcionando según lo diseñado;normalmente, si llama a Response.Redirect, querrá que la redirección se realice de inmediato.Vea esto para más información:

Response.Redirect y ThreadAbortException

Answer 4

Sabiendo que hay (al menos) tres API que utilizan internamente Thread.Abort, Me gustaría responder en términos más prácticos, cómo saber qué hacer al respecto.

Para nosotros, este error comenzó a registrarse de repente.¿Qué cambió?Arreglamos un error en algún procedimiento de base de datos que trataba con mapas de sitio.

Los registros de log4net mostraron que el encabezado X-Forwarded-For (estamos detrás de un NLB) era la dirección IP del robot de Google, 66.249.78.x, lo que reforzó mi teoría sobre el cambio en el mapa del sitio que llevó a Google a rastrear nuestro sitio de manera más agresiva en busca de imágenes.

Lo primero fue descubrir por qué sólo el robot de Google era capaz de provocar este problema.Ningún otro cliente estaba activando cualquier ruta de código utilizada. Response.Redirect, o lo que sea.

Entonces en el HttpApplication.Error controlador, agregué algo de código para registrar resultados adicionales detallados con todos los encabezados y la mayoría de los datos en el HttpResponse y HttpContext arrojado para iniciar sesión.

Esto me permitió ver que el problema era que el robot de Google está usando una cadena de agente de usuario de iPhone y, armado con eso, pude buscar en el código base "iPhone" y obtener:

private void CheckIPhoneAccess() { ... }

Y eso usa una redirección.

¿Qué hacer al respecto?

Bueno, para este código base antiguo, no vale la pena aplicar parches retroactivos a todos los Response.Redirect llamadas, así que voy a bajar el nivel de registro para ThreadAbortException para la aplicación.

Cambiaré el comportamiento del rastreador móvil del robot de Google, eso no conducen a 'mentiras' sobre lo que nuestro sitio ofrece a los móviles, ya que solo redirige en el primer acceso, posteriormente lee una cookie y muestra la imagen.El robot de Google no parece almacenar en caché esa cookie.

No es perfecto, pero el sitio debe ser reconstruido.probablemente por otro equipo que usa Scala o algo así, así que en términos prácticos, creo que esta es una buena opción.Agregaré comentarios y es posible que vuelva a abordar el tema más adelante, cree una Response.SafeRedirect extensión que resume este consejo:

¿Por qué Response.Redirect provoca System.Threading.ThreadAbortException?

lucas

Answer 5

La razón por la cual Response.Redirect dará esta excepción es que asp.net implementa internamente esta API con Thread.Abort().Cuando se llama a este método, se lanza una ThreadAbortException especial. Esta excepción no será absorbida por ningún bloque catch.Se volverá a lanzar al final de cada bloque de captura.