Common SharePoint Errors

Some error message nasties you might encounter

Bill Ayers

by Bill Ayers on 3/12/2015

Share this:

Article Details

Date Revised:

Applies to:
common SharePoint errors, farm configuration wizard, HTTP Error 503, Microsoft SharePoint Server State Service, SharePoint console application, SharePoint doctor, SPDoctor

When you are hard at work developing a custom solution, there is nothing worse than hitting one of those rather brutal error messages that seem to have nothing at all to do with the problem you are trying to solve. Not only do you have to waste time figuring out what the problem is, but you completely lose momentum. By the time you have found the solution, you have forgotten what it was you were originally trying to do!

Here are a few examples of the error message nasties you might encounter:

  • HTTP Error 503
  • The form cannot be rendered. This may be due to a misconfiguration of Microsoft SharePoint Server State Service. For more information, contact your server administrator.
  • System.IO.FileNotFoundException
  • Sorry, this site hasn't been shared with you.
  • An Unexpected Error has occurred or Value cannot be null. Parameter name: input.

Please see my solutions and workaround below.

HTTP Error 503. The service is unavailable.

Scenario: You are installing an update or service pack that goes wrong.

Often your development path brings you to a point where you have to do a bit of maintenance. This or that issue is fixed in the service pack, or you can't proceed without adding another language pack. Consider this sequence of events: you try to install a language pack that was already installed (you perhaps did a re-install of SharePoint in the meantime). The language pack installation fails with a helpful message in whatever language you are installing. You go to your web site; gone - 503 error. You go to Central Administration; gone - 503 error. Time to start worrying.

You look at your ULS logs. Nothing. You look in the Windows event log. Nothing. You run IISRESET. No change. You open IIS Manager and look at your web applications. All running. Time to start panicking.

What this means is that the application pools have been stopped. As far as I can tell the cause of this is that they have been stopped by the installation process, which then fails before it can re-start them. Of course there may be other circumstances that produce the same effect, but this is the one that I am aware of.

If you go to Internet Information Server (IIS) Manager and click on Application Pools, you will probably see that all the SharePoint application pools have been stopped. This is likely to include the web applications, central administration and critical web services such as STS. If you start them (right-click then Start) this should solve the problem, and you'll be back in business.

If you can't re-start the application pools, check that the user or permissions haven't changed somehow (right-click then Advanced Settings...). If the password has changed you can select the user identity ("..." button) and use the Set button to update it.

Somebody pointed out to me that another possible cause is if a web application started out as a 32-bit ASP.NET application, and subsequently got converted (upgraded) to a SharePoint 2010 web application. In this case you will see that the application pool has the "Enable 32-Bit Applications" property set to true, which is of course incompatible with SharePoint. Setting this property to false should solve the problem.

The form cannot be rendered. This may be due to a misconfiguration of Microsoft SharePoint Server State Service. For more information, contact your server administrator.

Scenario: You are trying to perform an operation that requires rendering an InfoPath form, e.g., a workflow initiation form.

You have spent hours getting your page layout to perfection and it's time for a demo. Create a new document and, er, publish. Never did that before but it should be fine. Oh dear - call the server administrator - oh wait...

This problem is caused because the State Service is not configured. This would normally be provisioned automatically by the Farm Configuration Wizard, but if you have configured SharePoint without the aid of this wizard (please tell me you didn't use the Farm Configuration Wizard) then you need to ensure that the State Service is set up correctly.

This can be achieved using the following PowerShell:

#Start the State Service (modify db name if multiple farms!)
$ss = New-SPStateServiceApplication -Name "State Service"
New-SPStateServiceDatabase -Name "WSS_StateService" -ServiceApplication $ss
New-SPStateServiceApplicationProxy -Name "State Service Proxy" -ServiceApplication $ss -DefaultProxyGroup

Don't forget to load the SharePoint snap-in if you are not using the "SharePoint Administration Console":

asnp Microsoft.SharePoint.Powershell


Scenario: You have written a simple SharePoint console application and try to pass in the URL to your site.

What could be simpler? You write a trivial console application with the usual first line:

using (var site = new SPSite("http://myurl/")) {

You are sure you got that URL right, and yet every time you try to run it you keep getting that pesky System.IO.FileNotFoundException. Yes, you are definitely running that on a SharePoint server. What on earth is going on?

The trouble is, Visual Studio always assumes you want to write an x86 application. For SharePoint applications you need to be x64. Go to your project settings and on the build tab next to "Platform target" choose "x64" from the drop-down.

It seems so obvious, and yet I seem to somehow forget to set the target platform almost every time I write a "quick" lightweight console application.

On a related note, if you are using SharePoint 2010 and you build against version 4.0 of the .NET Framework (again, the default) you will get a System.PlatformNotSupportedException. For SharePoint 2010 projects you need to select version 3.5 under the Application tab, where it says "Target framework".

Sorry, this site hasn't been shared with you.

Scenario: You want to sign in as a different user with permission to the site.

Just a page with this rather curt message and nothing else. No ribbon; no user welcome menu thingy; nothing. Hmmm.

It can be a bit fraught, especially when testing access permissions by switching between various users. You might well see this if you try to log in as a regular user to a publishing site and you have content that hasn't been published (i.e., there is only a draft copy, which is visible to a user with edit permissions). This can also happen if there is a page layout or just some CSS or JavaScript that isn't published, or of course a master page. The problem is you are now rather stuck, because you don't have that handy "Log in as another user" menu item to work with. Or maybe you can see the page with the user welcome menu, but the "Log in as another user" option just isn't there. Restarting the browser often doesn't solve the problem because the browser has cached the credentials. How on earth are you supposed to sign back in with the right creds?

Answer: use the URL This should get you to the login prompt and you can then change user. No need to restart the browser or fiddle with the stored credentials settings in Control Panel.

Just one caveat: this option uses an unsupported browser feature which is potentially unreliable and apparently does not work in IE 10 and Safari. In those cases an alternative is to start the browser with different credentials using the "Run as different user" context menu option, which you can see if you hold down the shift key while right-clicking the browser link. Another option is to find your credentials cache through Control Panel and remove the item.

An Unexpected Error has occurred or Value cannot be null. Parameter name: input.

Scenario: You are rendering a page with query string parameters as an authenticated user.

This error quite commonly turns up as the dreaded, "An unexpected error has occurred," which to a SharePoint practitioner is anything but unexpected. In fact, that is the most common form in this scenario, but because the error message is so universal I thought I had better qualify it by referring to the other manifestation.

I have been caught by this one a couple of times, once using a query string parameter "Title" and then a couple of years later falling into the same trap with "ID".

If you look at the URL of this page you will see that the actual page name is a constant for all the articles. The page is fixed and the content is inserted when the page is requested according to the query string parameter (often known as a "slug"). I have used this technique as a cheap-and-cheerful publishing model in situations where I was too mean to stump up for a SharePoint Server licence and do content management properly ;-)

You may have noticed that the query string parameter on this site is actually called "slug," and I assume it is a key into the SharePoint list containing the various error messages and their explanations. Well, if that parameter were called "Title" or "ID" (the most obvious choices) then bad things would happen occasionally. Everything works okay for the anonymous user, but sometimes when you browse to the page as an authenticated user, and always when you try to save after editing the page, you get the nasty errors. If you ignore the error and re-load the page you may well find that the edits were saved anyway, phew! But it is pretty disconcerting nonetheless.

You won't find anything useful in the ULS that is helpful—just a null reference exception. You can breakpoint all your custom code but it will never get hit. The error may be intermittent—sometimes only if you edit the page. But you never see it as an anonymous user (or at least I haven't). You can edit the page okay if you strip off the query string parameter—Hmmm.

So what is going on here? Well, the problem is the choice of query string parameter name, because SharePoint has already bagged a few, and that includes some of the ones that are the first to come to mind, like "ID" and "Title" and "List" and "Type". I am not sure if it messes up the SPContext or just upsets the JavaScript somehow, but it seems to be associated with the ribbon control judging from the fact that anonymous users seem to be unaffected.

So if you are going to use query string parameters, I recommend that you avoid choosing the following names (list provided by Stefan Gossner):

  • ContentTypeId
  • FeatureId
  • ID
  • IsDlg
  • List
  • ListTemplate
  • FolderCTID
  • Mode
  • PageVersion
  • RootFolder
  • Title
  • Type
  • VersionNo
  • View

I hope that the error messages above won't ruin your day ever again. If you want to see more examples, visit my blog at

Topic: Administration and Infrastructure

Sign in with

Or register