KISS = “Keep it Simple, Stupid.”  Remember that acronym as you continue reading.  Today I received StackOverflowException errors when deploying custom solutions to a new SharePoint environment at my client.  Previously I was under the impression that all of our environments were configured as identical to each other as possible, but as I will explain later that was not the case.  Technically speaking this error could happen to any .Net web application, not just a SharePoint one.

Little back story, we are migrating a custom solution (series of multiple applications) packaged as WSPs through various environments at my client.  We have made it through all but a few environments with no major problems deploying our custom solution.  So the fact that we saw this major error in a later environment (and none previous) was reason for concern.  At first I was worried that variations to this environment (load balanced WFEs, new AD domain, etc) were to blame.  That was not the case.  Next I thought deploying our custom code was somehow breaking this environment.  We are using a fairly methodical process for deployments between environments which you can read about here.  The environment threw StackOverflowExceptions when activating a feature on almost any deployed solutions, but strangely that was not the real cause either.  Finally I decided to go back to the KISS principle which ended up isolating the real issue.

For starters I tried deploying a plain vanilla web application with a blank site collection.  The web app and site collection created successfully which was good news.  I then tried to navigate to the newly created site and was greeted by the wonderful “Server Application Unavailable” error seen below along with the 2 event log errors.

Server Application Unavailable

Event 1334 – Failed to initialize AppDomain…Could not load file or assembly “System.Web”…

Event ID 1088 – Failed to execute request because the App-Domain could not be created

Considering I was getting this error with a blank site and no custom code installed I ruled out our custom solutions as the root cause (sigh of relief for myself and the rest of the development team.)  Upon closer inspection of the event log error id 1334, I saw that there was an access denied error when trying to read System.Web from the GAC.  Strange that IIS was having trouble reading a standard .Net assembly from the GAC.  A quick tour of the interwebs and a few hits pointed to possibly needing to run “aspnet_regiis –i” to register ASP.Net with IIS on the server.  Typically I run that command as a pre-requisite for installing SharePoint, but I was not present for the installation of this environment so assumed it had been completed.  I have also heard some say it depends on which order you install IIS and .Net on your server if you need to run it.  Please leave feedback if you can clarify that for me.  So I decide to try running the command in the off chance it fixes things.

aspnet_regiis.exe -i

As luck would have it, running that command fixed my issues.  I was then able to successfully pull up the blank site.  In a random turn of fate we did have to re-install SharePoint in that farm as service packs and other upgrades had been deployed prematurely to the farm without proper testing.  We are still clearing up those items of the re-install, but early indications suggest we are in the clear with our deployments.

For my part I made a few assumptions that proved faulty.  These included that a) SharePoint was properly installed and configured b) someone had previously verified basic site functionality existed and c) that the problem lay with the most complex pieces of the puzzle.  So in closing, sometimes it’s necessary to step back and start from the beginning…KISS as they say.  Hopefully this post can save someone a headache of troubleshooting.  Leave feedback if you have any questions, comments, or suggestions.

-Frog Out