ERROR: request not found in the TrackedRequests. We might be creating and closing webs on different threads

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?