Have you got the complete stacktrace from the errorscreen?

Looks like some internal asp.net-code expects the workerrequestobject we use to create the phony HttpContext in order to be able to render page's html to be of type IIS7WorkerRequest, which it's not. (its inheriting from HttpWorkerRequest).

/johan

uhm yeah...

A quick run through ILSpy (now Reflectors gone commercial) reveals that some internal code in EtwTrace assumes the given HttpWorkerRequest can be casted to an II7WorkerRequest....

The problem is that the flag determining the type of the workerequest (s_wrType) is static, and it's set the first time it gets called, probably from a "normal" webrequest (which of course really *is* of type IIS7WorkerRequest):

internal static void Trace(EtwTraceType traceType, HttpWorkerRequest workerRequest, string data1, string data2, string data3, string data4)
{
	if (EtwTrace.s_WrType == EtwWorkerRequestType.Undefined)
	{
		EtwTrace.ResolveWorkerRequestType(workerRequest);
	}
	if (EtwTrace.s_WrType == EtwWorkerRequestType.Unknown)
	{
		return;
	}
	if (workerRequest == null)
	{
		return;
	}
	if (EtwTrace.s_WrType == EtwWorkerRequestType.IIS7Integrated)
	{
		UnsafeNativeMethods.TraceRaiseEventMgdHandler((int)traceType, ((IIS7WorkerRequest)workerRequest).RequestContext, data1, data2, data3, data4);
		return;
	}
	if (EtwTrace.s_WrType == EtwWorkerRequestType.InProc)
	{
		UnsafeNativeMethods.TraceRaiseEventWithEcb((int)traceType, ((ISAPIWorkerRequest)workerRequest).Ecb, data1, data2, data3, data4);
		return;
	}
	if (EtwTrace.s_WrType == EtwWorkerRequestType.OutOfProc)
	{
		UnsafeNativeMethods.PMTraceRaiseEvent((int)traceType, ((ISAPIWorkerRequest)workerRequest).Ecb, data1, data2, data3, data4);
	}
}

Personally, I think this is a bug with the EtwTrace-code, 
and to be able to workaround, you would have to turn off tracing...

/johan