Type initializer error at startup

We’ve been using ServiceStack and the C# client for about a year and this is the first time we’ve encountered this error. It coincided with a new deployment that had very few code changes and no changes, as least as we can tell, to our configuration. The same code base is working in our Dev environment.

Full error entry from Event log:

Exception information:
Exception type: TypeInitializationException
Exception message: The type initializer for ‘ServiceStack.HttpHandlerFactory’ threw an exception.
at ServiceStack.HttpHandlerFactory…ctor()

Object reference not set to an instance of an object.
at ServiceStack.HttpHandlerFactory…cctor()

I double checked that the AppHost() was called from Global.asax ApplicationStart() event and all of the IOC registrations look correct in the Configure method. There was no change to the AppHost code from prior working deployments. Any suggestions about how to debug this?

Many thanks.

Hi Ryan,

It’s unusual for there to be an exception in the HttpHandlerFactory constructor. But it does a fair bit of work to set itself up, if you have any custom configuration you’ll want to first uncomment them to see if you can identify the culprit, you may also want to check file permissions to see ServiceStack has read access.

Some tips than can help are mentioned in the Debugging docs, where first you want to enable DebugMode, e.g:

SetConfig(new HostConfig {
    DebugMode = true

Then you can view if there were any StartUp exceptions by going to the ?debug=requestinfo route. If there were any StartUp errors they’ll be in the StartUpErrors collection.

You can also enable debug logging with your preferred Logging Provider.

Otherwise we’ve started publishing the pdb NuGet symbol packages for each release at https://github.com/ServiceStack/Assets/tree/master/nuget since http://symbolsource.org has been broken for months.

mythz - thanks so much for your reply. Will keep this topic posted on progress, and thanks for all the great work on a great dev stack. Ryan

1 Like

Just wanted to update this topic…your suggestion to double-check file permissions led to the solution. IT folks had decided to change some directory permissions and we didn’t “get the memo”. Understandable under the circumstances, given that we appear to be under constant hack efforts recently, so I’ll give those system guys some slack.

1 Like