2011-03-17 11 views
6

Tengo una configuración de tipo remoto en mi aplicación donde evito TargetInvocationExceptions y tomo la excepción interna. Invoco el método interno PrepForRemoting en la clase Exception para preservar el seguimiento de la pila del método invocado.ASP.NET pantalla amarilla de la muerte: ¿de dónde obtiene el seguimiento de la pila?

Esto parece construir la propiedad de seguimiento de la pila correctamente:

"\ r \ nserver seguimiento de la pila:. \ R \ n

en ZBooking.Environment.Services.BookingService <> c_ DisplayClass9 `1.b _5 (BookingSlot p) en C: \ dev \ ZBookings \ core \ ZZBookings.Services \ BookingService.cs: línea 79 \ r \ n

en System.Linq.Enumerable.All [TSource] (Fuente IEnumerable'1, predicado Func'2) \ r \ n

en ZBookings.BookingService.MoveBooking [TBookingType] (Int32 bookingId,> IEnumerable`1 bookingSlots) en C: \ dev \ ZBooking.Client \ core \ ZBookings.Services \ BookingService.cs: Línea 79 \ r \ n \ r \ n

Excepción retroproyectada en [0]: \ r \ n en ZBookings.BookingService. <> c_ DisplayClass9`1.b _5 (BookingSlot p) en C: \ dev \ ZBookings \ core \ ZBookings.Services \ BookingService.cs: Línea 79 \ r \ n

en System.Linq.Enumerable .Todas [TSource] (fuente IEnumerable'1, Func'2 predicado) \ r \ n

en ZBookings.BookingService.MoveBooking [TBookingType] (Int32 bookingId, IEnumerable`1 bookingSlots) en C: \ dev \ ZBookings \ core \ ZBookings.Services \ BookingService.cs: línea 79 "

Sin embargo, cuando esto se muestra mediante el estándar ASP.NET ye llow pantalla que es:

[NullReferenceException: referencia a objeto no establecida como una instancia de un objeto.] ZBooking.ApplicationServices.MethodMarshaller.Invoke (Delegado del, ZipIdentity zipIdentity, Object [] args) en C: \ dev \ ZBooking \ core \ ZBooking.ApplicationServices \ MethodMarshaller.cs: 147 ZBooking.ApplicationServices.MethodMarshaller.Invoke (Delegate del, ZipIdentity zipIdentity, Object [] args) en C: \ dev \ ZBooking \ core \ ZBooking.ApplicationServices \ MethodMarshaller .cs: ​​105 ZBooking.ApplicationServices.MethodMarshaller.Call (Func'3 del, T1 arg1, T2 arg2, ZipIdentity zipIdentity) en C: \ dev \ ZBooking \ core \ ZBooking.ApplicationServices \ MethodMarshaller.cs: 72
.. .etc.

Llamando Server.GetLastError(); en Application_Error en Global.asax muestra el seguimiento de pila correcto. ¿De dónde viene la traza de la pila de pantalla amarilla?

+0

¿Estás seguro de que no tienes una excepción secundaria que "cubre" la primera? Las dos excepciones parecen ser demasiado diferentes.¿Puedes poner un punto de interrupción en la línea 147 de MethodMarshaler? (y 105 y 72) y ver qué pasa? Y quizás podría tratar de hacer que el depurador se detenga a toda la NullReferenceException. – xanatos

+0

Ese es el punto. Una excepción cubre al otro: estoy volviendo a lanzar la excepción interna correcta y luego reescribo su rastro de pila desde allí. La reescritura de traza de pila funciona pero no aparece para el YSOD. –

Respuesta

6

La pantalla amarilla de la muerte de ASP.NET obtiene la traza de la pila construyendo un StackTrace de la excepción. Lo hace usando el constructor StackTrace(Exception, Boolean). A continuación, vuelca la pila al recorrer los objetos StackFrame suministrados por el objeto StackTrace. No utiliza la propiedad Exception.StackTrace.

+0

Eso suena prometedor. Parece reducirse a la llamada 'inner static extern void GetStackFramesInternal (StackFrameHelper sfh, int iSkip, Exception e);' - Echaré un vistazo al SSCLI para ver qué método invoca. –

+0

Mientras tanto, creo que la pregunta, "¿De dónde viene la traza de la pila de la pantalla amarilla?" Ha sido respondida. ;) El resto de su kilometraje, me temo, puede ser más largo. –

+0

Punto tomado - respondido :) –

Cuestiones relacionadas