I’ve been struggling with a nasty bug that I haven’t been able to crack so I’ll throw it out here.

I have an app that is hosting the ASP.Net runtime for processing MailMerge like templates. The pages contain embedded logic of business objects that are run into HTML documents that are emailed to recipients. It works well – MOST of the time.

Specifically, I have problems when the machine is first started. Yes, ONLY the first time the app runs on this machine. What happens is that I get a fatal exception of System.ExecutionEngineException. The Exception is not trappable – the code that is called and fails has an Exception block around it, which never catches the exception. Instead I get a hard exception with an option to pop up the Debugger.

For those of you not familiar with the ASP. Net runtime hosted in a client app, it works by creating a remote proxy in another AppDomain. There’s a factory method that hands back a remoted Proxy reference to the ASP.Net runtime in the other AppDomain. From there you can call methods of a custom implementation of a worker request. I wrote about this here if you’re interested in the gory details of hosting the ASP. Net runtime. To make life easier I wrote a wrapper class around the process you can with a few lines of code host the runtime and fire requests in a configured directory.

This all works very well. Except I get this failure the very first time the runtime routine is accessed. If I get the failure, I can quit run again and it works fine. If I first run another application that hosts the ASP.Net runtime (such as IIS or another hosted app) then the error will not occur.

It gets even weirder in that if I try to run it in Debug mode, it works the first time. Even hooking up tools like the Fusion Log Viewer it also works. It will work, but if I then go and run the app without a debugger hooked up it will still bomb.

I’ve duplicated this on several machines including a clean VPC XP install.

The load sequence looks something like this where wwaspruntimehost.dll is my wrapper around the HttpRuntime I use (in other apps that don’t have any of these issues).

'WebStoreClient.exe': Loaded 'd:\programs\webstoreclient\wwaspruntimehost.dll', No symbols loaded.

'WebStoreClient.exe': Loaded 'd:\windows\assembly\gac\system.web\1.0.5000.0__b03f5f7f11d50a3a\system.web.dll', No symbols loaded.

'ASPHOST_7f5352b7': Loaded 'd:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll', No symbols loaded.

'ASPHOST_7f5352b7': Loaded 'd:\programs\webstoreclient\wwaspruntimehost.dll', No symbols loaded.

'ASPHOST_7f5352b7': Loaded 'd:\windows\assembly\gac\system.web\1.0.5000.0__b03f5f7f11d50a3a\system.web.dll', No symbols loaded.

'ASPHOST_7f5352b7': Loaded 'd:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll', No symbols loaded.

'ASPHOST_7f5352b7': Loaded 'd:\windows\assembly\gac\system.xml\1.0.5000.0__b77a5c561934e089\system.xml.dll', No symbols loaded.

An unhandled exception of type 'System.ExecutionEngineException' occurred in mscorlib.dll

The actual failure in code occurs in the call to the HttpRuntime.ProcessRequest() method which looks something like this:

public virtual string ProcessRequestToString(string Page, string QueryString)

{

      TextWriter loOutput = new StringWriter();

      // *** Reset the Response settings

      this.ResponseHeaders = null;

      this.Cookies = null;

      this.ResponseStatusCode = 200;

      wwWorkerRequest Request = new wwWorkerRequest(Page, QueryString, loOutput);

      Request.ParameterData = this.ParameterData;

      Request.PostData = this.PostData;

      Request.PostContentType = this.PostContentType;

      Request.RequestHeaders = this.RequestHeaders;

      try

      {

            // *** ERROR OCCURS HERE!

            HttpRuntime.ProcessRequest(Request);

      }

      catch(Exception ex)

      {

            this.ResponseStatusCode = Request.ResponseStatusCode;

            this.cErrorMsg = ex.Message;

            this.bError = true;

            return null;

      }

      string lcResult = loOutput.ToString();

      loOutput.Close();

      this.ResponseHeaders = Request.ResponseHeaders;

      this.ResponseStatusCode = Request.ResponseStatusCode;

      this.ResponseData = Request.ResponseData;

      this.Cookies = Request.Cookies;

      return lcResult;

}

Note that this method is called over remoting boundaries from the main application, into the AppDomain that hosts the ASP.Net runtime. At this point the runtime started OK (the client app got a Remoting Proxy back to make this call on). IOW, the runtime apparently seems to have initialized properly. The failure then occurs when the first call is made against an ASPX page contains the template code.

Note the try/catch around the code – the error never gets handled though causing the fatal exception in the Process.

I’m kind of at the end of my rope in trying to figure out what’s causing this behavior which is only made worse by the fact that I can’t duplicate it except when the machine has just booted. I can’t dupe it in a simpler scenario (although the code from the form is straight forward – it sits in a very complex form).

I’ve been messing with the SysInternals Process Explorer which BTW is an awesome tool for checking out system status. I’ve been able to make the failure occur without a restart by killing off a number of processes, but I can’t seem to find rhyme or reason which ones affect this behavior.

If anybody has any ideas on how to further trace this I would be much obliged…