I've seen this error a couple of times now and the fix unfortunately hasn't been all that consistent. The event log item looks like:
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1309
Time: 5:31:59 PM
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 7/18/2008 5:31:59 PM
Event time (UTC): 7/19/2008 12:31:59 AM
Event ID: 5e5f200f0a3042648734373e1a3e2fc6
Event sequence: 356
Event occurrence: 1
Event detail code: 0
Application domain: /LM/W3SVC/773312491/Root-1-128608981453287591
Trust level: WSS_Minimal
Application Virtual Path: /
Application Path: [PATH]
Machine name: [COMPUTERNAME]
Process ID: 5428
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE
Exception type: NullReferenceException
Exception message: Object reference not set to an instance of an object.
Stack trace: at
Microsoft.Office.Server.Administration.SqlSessionStateResolver.System. Web.IPartitionResolver.ResolvePartition(Object key)
at System.Web.PartitionManager.GetPartition(IPartitionResolver partitionResolver, String id)
at System.Web.SessionState.SqlSessionStateStore.GetConnection(String id, Boolean& usePooling)
at System.Web.SessionState.SqlSessionStateStore.DoGet(HttpContext context, String id, Boolean getExclusive, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actionFlags)
at System.Web.SessionState.SqlSessionStateStore.GetItemExclusive(HttpContext context, String id, Boolean& locked, TimeSpan& lockAge, Object& lockId, SessionStateActions& actionFlags)
at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)
at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web. HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Custom event details:
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
The more we bump into it the more frustrating it gets.
As far as we can tell the exception is a function of Session State not being properly serialized/de-serialized into the Session State database. SharePoint, because of its farm like nature is geared to use database tables in the Shared Services database to store session.
This way if your SharePoint is deployed to a farm and users continue to get bounced around from one Web Front End to another, they won't lose they're session (like they would if it were stored in memory on the WFEs). This Session is stored in the ASPStateTempApplications and ASPStateTempSessions tables of the Shared Services database.
What's kind of creepy about this fix is that it still doesn't make a ton of sense to us. Your options are as follows:
- If you only have one WFE, or you have in IP Source Sticky Load Balancer servicing your web servers you can turn on InProcess session for the session state. IE. turn the following line in the web.config from this: <sessionState mode="SQLServer" timeout="60" allowCustomSqlDatabase="true" partitionResolverType="Microsoft.Office.Server.Administration. SqlSessionStateResolver, Microsoft.Office.Server, Version=22.214.171.124, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
to this:<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"/>
You can also experiment with using the classic ASP.NET ASPState database and SQL Session Provider. You should know that even in the IP Sticky scenario some users (like AOL users) may still come at the farm using different IP's which will log them out if you're using InProcess session. I'm not positive that AOL still does this.
- If you're not happy with the above, the following will fix it most of the time (I'm still not 100% from the field with this one).
- Go to the Farm database server and open up SQL Management Studio. Connect to the SharePoint database server.
- Get the name of the Web Front End that is experiencing the error. Expand the Logins folder in the SQL Management Studio on the Farm database server and add an account named DOMAIN\WFEMachineName$.
- Open up the User Mappings for that user, ensure that they have db_owner and public roles for the Shared Services Database (often of the form SharedServices_DB_[GUID]).
- Restart IIS on the WFE that you just added an account for. The error should stop appearing.
I have no idea why adding more an account would help fix this in most cases. You would think that you would see connectivity errors or failed audits if connection/authentication/authorization was the issue. Either way I have seen this fix work too often to not pass it on.
May it help you, or better yet you never see this error in the first place.