SharePoint 2007 ULS Error System.NullReferenceException on workflow start

Question

(MOSS 2007 32bit SP2)

I have a workflow which was developed in Visual Studio and is deployed as a feature and associated with my list. Items in that list are created programmatically, and the last step of the process is to look through the SPWorkflowAssociation collection on the list and start the WF which matches a specific name:

// code to create the list item & get the new item's index (itemIndex)...

foreach (Microsoft.SharePoint.Workflow.SPWorkflowAssociation flowAssoc in SPContext.Current.Web.Lists["{listname}"].WorkflowAssociations) {
    if (flowAssoc.Enabled && flowAssoc.AllowManual && (flowAssoc.Name.Trim() == workflowNameToLookFor.Trim())) 
        SPContext.Current.Site.WorkflowManager.StartWorkflow(SPContext.Current.Web.Lists["{listname}"].Items[itemIndex], flowAssoc, flowAssoc.AssociationData, true);
}

(please forgive the ugly fully-qualified names and the constant re-fetching of the SPListItem, unless you think that's actually to blame somehow)

This has been in production use for months, where the workflow being started was a SharePoint Designer workflow. Now that I've deployed my custom WF (which has a different name) I'm getting some "odd behavior":

Everything works 100% if I (not the system account, but a site collection admin) run the code to create the item and start the workflow. But if any other user (even someone with Full Control on the site and all involved lists) does the same they get a generic "Error, An unexpected error has occurred" page from SharePoint, but the item was created correctly, there's no WF error associated with it (the WF history for the item is completely blank), and they can then manually start the specified workflow without any problem.

The only error being generated in ULS when this happens is:

Engine RunWorkflow: System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.SharePoint.Workflow.SPWorkflowHostServiceBase.LoadInstanceData(Guid instanceId, Boolean& compressedData) at Microsoft.SharePoint.Workflow.SPWinOePersistenceService.LoadWorkflowInstanceState(Guid instanceId) at System.Workflow.Runtime.WorkflowRuntime.InitializeExecutor(Guid instanceId, CreationContext context, WorkflowExecutor executor, WorkflowInstance workflowInstance) at System.Workflow.Runtime.WorkflowRuntime.Load(Guid key, CreationContext context, WorkflowInstance workflowInstance) at System.Workflow.Runtime.WorkflowRuntime.GetWorkflow(Guid instanceId) at Microsoft.SharePoint.Workflow.SPWinOeHostServices.Send(SPWinOeWorkflow winoeworkflow, SPWorkflowEvent e) at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(Guid trackingId, SPWorkflowHostService host, SPWorkflow workflow, Collection`1 events, TimeSpan timeOut)

If I change the name of the workflow I'm looking for to something which doesn't exist, there is no error at all (as my IF statement in the FOREACH never finds a match), so it's definitely finding my workflow and trying to start it.

But (again), if I look at the Workflow Status/History page on an item which generated the error, there is no error or record of the WF ever trying to start there, and from that page the user can manually start the workflow without a problem.

I am using an InfoPath Association Form for the WF, but if that was at the root of this (e.g. if I need to be passing something with its data/schema to WorkflowManager.StartWorkflow) I'd expect to see the same error for my Site Collection Admin user. I am not using any sort of WF Initiation Form.

I'm going nuts trying to find the source of this. Hoping someone has seen this ULS error or this sort of behavior before...

Can you verfiy that SPContext.Current.Web.Lists["{listname}"].Items[itemIndex] is not null? Did you try updating the list before you execute the code above? — int32
I can't really verify that directly... {listname} there is coming from a SP List so that I can point it to any WF at runtime, and despite this having been in use with a SPD WF before, now any WF (even a brand new simple SPD WF which just writes 1 message to hist list) fails unless the user is a SiteCollection Admin. If I add a new user to SCA, it works for them. So this must be a permissions issue, but still lost after that... — DaveD
Given that it works for a SCA, I'm assuming that Lists[].Items[] is either a) Never Null, or b) Null Unless User Is SCA (Full Control still fails, and every list/library on the site is now inheriting perms) — DaveD
very strange behaviour indeed... try running the code block with SPSecurity.RunWithElevatedPrivileges and see what happens — int32
I think I got it... See my answer below. Thanks for the suggestions though! — DaveD

DaveD DaveD · Accepted Answer · 2011-08-17T13:48:51

Haven't really found the cause of this, but I was able to fix it...

After resetting every list/library in All Site Content to inherit permissions from the site, and giving my test user Full Control at the site level, I was still getting an error/failure from my test user. However, if I granted my test user Site Collection Admin rights (this is a subsite/web directly under the SC, i.e. http://mossServer/sites/SC/thisSite/) then everything worked.

So I set this site to reinherit its permissions from the SC, then broke the inheritance and added back in my "normal" group for this site (which the test user is in) with Contribute and Approve permissions, and got rid of all the obviously non-applicable entries from the SC. Now everything works for the test user.

I still have a few extraneous groups with access to the site that I need to clean up, but I don't think my test user is in any of them, so I don't think they were the difference. I think somehow (I made the mistake of making "one minor permissions clean-up" change alongside the deployment of my new WF) I broke a "hidden" (not on any object visible from All Site Content) permission assignment which was crucial to the process (although I'm still baffled as to what it could have been, since the user was able to see the WF and manually start it on the item they created).

I'll leave a comment if I find anything else out, but it seems like reinheriting permissions from the site collection fixed whatever was broken.

SharePoint 2007 ULS Error System.NullReferenceException on workflow start

1 Answers