¿Por qué mi aplicación asp.net está lanzando ThreadAbortException?

Question

pregunta auto explicativa.

¿Por qué esta cosa burbujea en mi captura de prueba, incluso cuando no pasa nada?

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

Sé que es una pregunta Novato, pero si este sitio es va a conseguir el ranking de búsqueda y atraer a los novatos que tenemos que pedirles que

Answer 1

Esto probablemente proviene de una llamada Response.Redirect. Compruebe 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, falsa) soluciona el problema)

Answer 2

La razón más común para un ThreadAbortException está llamando Response.End, Response.Redirect, or Server.Transfer. Microsoft ha publicado algunas funciones sugeridas que deberían utilizarse en lugar de esas funciones.

Answer 3

Como han dicho otros, se produce cuando se llama a Response.End() (que ocurre cuando se llama a Response.Redirect sin pasar falso como el segundo parámetro). Esto está funcionando según lo diseñado; Por lo general, si llama a Response.Redirect, desea que la redirección se realice de inmediato. Ver este para obtener más información:

Response.Redirect and the 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, la forma de resolver qué hacer al respecto .

Para nosotros, este error comenzó a registrarse de repente. ¿Qué cambió? Solucionamos un error en algún procedimiento de base de datos que estaba tratando con sitemaps.

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 del sitemap que lleva a Google a rastrear nuestro sitio de forma más agresiva. para imágenes.

Lo primero fue descubrir por qué solo el robot de Google pudo causar este problema. Ningún otro cliente estaba activando la ruta de código que usa Response.Redirect, o lo que sea.

Así en el controlador HttpApplication.Error, he añadido algo de código para registrar la salida adicional detallado con todas las cabeceras, y la mayoría de los datos en la HttpResponse y HttpContext vomitado para iniciar la sesión.

Esto me dejó ver que el problema era que el robot de Google está utilizando una cadena de agente de usuario de iPhone y armado con eso, yo era capaz de buscar en la base de código para el "iPhone" y llegar a:

private void CheckIPhoneAccess() { ... } 

Y que usa un redireccionamiento

¿Qué hacer al respecto?

Bueno, para esta base de código antigua, no vale la pena retroceder todas las llamadas Response.Redirect, por lo que voy a reducir el nivel de registro para ThreadAbortException para la aplicación.

que va a cambiar el comportamiento para el rastreador móvil del robot de Google, que haría no plomo a 'mentiras' sobre lo que nuestro sitio sirve a los móviles, ya que sólo vuelve a dirigir en el primer golpe, posteriormente se lee una cookie y muestra la imagen. Googlebot no parece almacenar en caché esa cookie.

No es perfecto, pero el sitio debe ser reconstruido. probablemente por otro equipo que use Scala o algo así, así que en términos prácticos, creo que esta es una buena opción. Voy a añadir comentarios y puede retomar el tema más adelante, construir una extensión Response.SafeRedirect que encapsula este consejo:

Why Response.Redirect causes System.Threading.ThreadAbortException?

Lucas

Answer 5

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