ASP.NET yellow screen of death - where does it get the stack trace from?

Question

I have a remoting-type set up within my application where I avoid TargetInvocationExceptions and grab the inner exception. I invoke the internal PrepForRemoting method on the Exception class to preserve the stack trace from the invoked method.

This appears to construct the stack trace property correctly:

"\r\nServer stack trace: \r\n

at ZBooking.Environment.Services.BookingService.<>c_DisplayClass9`1.b_5(BookingSlot p) in C:\dev\ZBookings\core\ZZBookings.Services\BookingService.cs:line 79\r\n

at System.Linq.Enumerable.All[TSource](IEnumerable'1 source, Func'2 predicate)\r\n

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

Exception rethrown at [0]: \r\n at ZBookings.BookingService.<>c_DisplayClass9`1.b_5(BookingSlot p) in C:\dev\ZBookings\core\ZBookings.Services\BookingService.cs:line 79\r\n

at System.Linq.Enumerable.All[TSource](IEnumerable'1 source, Func'2 predicate)\r\n

at ZBookings.BookingService.MoveBooking[TBookingType](Int32 bookingId, IEnumerable`1 bookingSlots) in C:\dev\ZBookings\core\ZBookings.Services\BookingService.cs:line 79"

However, when this is displayed by the standard ASP.NET yellow screen it is:

[NullReferenceException: Object reference not set to an instance of an object.] ZBooking.ApplicationServices.MethodMarshaller.Invoke(Delegate del, ZipIdentity zipIdentity, Object[] args) in C:\dev\ZBooking\core\ZBooking.ApplicationServices\MethodMarshaller.cs:147 ZBooking.ApplicationServices.MethodMarshaller.Invoke(Delegate del, ZipIdentity zipIdentity, Object[] args) in C:\dev\ZBooking\core\ZBooking.ApplicationServices\MethodMarshaller.cs:105 ZBooking.ApplicationServices.MethodMarshaller.Call(Func'3 del, T1 arg1, T2 arg2, ZipIdentity zipIdentity) in C:\dev\ZBooking\core\ZBooking.ApplicationServices\MethodMarshaller.cs:72
...etc.

Calling Server.GetLastError(); on Application_Error in Global.asax shows the correct stack trace. Where is the yellow screen stack trace coming from?

Glycogenesis

Are you sure you don't have a secondary exception that "covers" the first one? The two exceptions seem to be too much different. Can you put a breakpoint at line 147 of MethodMarshaler? (and 105 and 72) and see what happens? And perhaps you could try to make the debugger stop to all the NullReferenceException . – Lockup

That's kind of the point. One exception is covering the other - I am re-throwing the correct inner exception and then rewriting its stack trace from there. The stack trace re-write works but doesn't appear to bubble up to the YSOD. – Glycogenesis

Answer 1

ASP.NET's yellow screen of death gets the stack trace by constructing a StackTrace from the exception. It does this using the StackTrace(Exception, Boolean) constructor. It then dumps the stack by walking the StackFrame objects supplied by the StackTrace object. It does not use the Exception.StackTrace property.

Vada

That sounds promising. It appears to boil down to the internal static extern void GetStackFramesInternal(StackFrameHelper sfh, int iSkip, Exception e); call - I'll have a look at the SSCLI to see what method it invokes. – Glycogenesis

Meanwhile, I think the question, “Where is the yellow screen stack trace coming from?” has been answered. ;) Rest of your mileage, I'm afraid, may be longer. – Vada