This is an error I receive from Sharepoint when I deploy a custom workflow to a forms library. The workflow is very straightforward and doesn't do anything fancy. I was reading from the an infopath form, but have since stripped down all non-essential code to see if I can get it working. As far as I can tell, other workflows are fine (I've developed others on the same box and they are intact and functioning). The design view of the workflow is as follows:
alt text http://img5.imageshack.us/img5/7231/workflowv.jpg
The error occurs after a task is successfully created. This leads me to believe that there is an issue with the while loop, which is waiting for a boolean variable to become true (which is initially set to false). Normally, when the task is altered in any way, the changed event will fire and change the variable to true, then the workflow will continue. I receive this error on the start of this workflow:
ERROR: request not found in the TrackedRequests. We might be creating and closing webs on different threads. ThreadId = 9, Free call stack = at Microsoft.SharePoint.SPRequestManager.Release(SPRequest request) at Microsoft.SharePoint.SPSite.Close()
at Microsoft.SharePoint.SPSite.Dispose() at Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver.AutoStartWorkflow(SPItemEventProperties properties, Boolean bCreate, Boolean bChange, AssocType atyp) at Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver.AutoStartWorkflow(SPItemEventProperties properties, Boolean bCreate, Boolean bChange) at Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver.ItemAdded(SPItemEventProperties properties) at Microsoft.SharePoint.SPEventManager.RunItemEventRec...
...eiver(SPItemEventReceiver receiver, SPItemEventProperties properties, SPEventContext context, String receiverData) at Microsoft.SharePoint.SPEventManager.RunItemEventReceiverHelper(Object receiver, Object properties, SPEventContext context, String receiverData) at Microsoft.SharePoint.SPEventManager.<>c__DisplayClass8`1.b__0() at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state) at Microsoft.SharePoint.SPSecurity.RunAsUser(SPUserToken userToken, Boolean bResetContext, WaitCallback code, Object param)
at Microsoft.SharePoint.SPSecurity.RunAsUser(SPUserToken userToken, CodeToRunElevated code)
at Microsoft.SharePoint.SPEventManager.InvokeEventReceivers[ReceiverType](SPUserToken userToken, RunEventReceiver runEventReceiver, Obj... ...ect receivers, Object properties, Boolean checkCancel) at Microsoft.SharePoint.SPEventManager.InvokeEventReceivers[ReceiverType](Byte[] userTokenBytes, RunEventReceiver runEventReceiver, Object receivers, Object properties, Boolean checkCancel) at Microsoft.SharePoint.SPEventManager.HandleEventCallback[ReceiverType,PropertiesType](Object callbackData) at Microsoft.SharePoint.Utilities.SPThreadPool.WaitCallbackWrapper(Object state) at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state) at System.Threading.ExecutionContext.runTryCode(Object userData) at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData) at System.Threading.ExecutionContext.RunInternal(Execu..
I've searched high and low for an explanation, but cannot find anything that concretely fixes this problem. It really is a straightforward workflow, with nothing special going on...maybe it's the form library it's attached to?