Memory leak when using Workflow 4.0 SqlWorkflowInstanceStore and PersistableIdleAction.Unload

This particular problem is driving me nuts. I wonder if anyone has experienced a similar problem. If I load up a workflow then unload it and perform a memory snapshot then the result is predictable - my workflow is no longer in memory. However, if I load up a workflow and set the PersistableIdle action to PersistableIdleAction.Unload and let the workflow idle the workflow remains in memory even though the Unload action fires.

I used ANTS Memory Profiler to debug this issue. This is the object retention graph outputted showing that an internal object is hanging onto my workflow instance.

_{(source: rohland.co.za)}

Can anyone else verify this problem? My code amounts to the following:

1. Create SqlWorkflowInstanceStore and setup lock owner handle
   -- At this point I take a memory snapshot
2. Create an instance of Workflow1
3. Set the PersistableIdle action
4. Apply the instancestore to Workflow1
5. Setup action event handlers for Idle, Unload, UnhandledException etc.
6. Persist the workflow instance
7. Run the workflow instance
8. Wait for instance to idle (caused by Delay activity)
9. Ensure the Unload action is fired
   -- At this point I take a second memory snapshot

From the above image, it is clear that the only object referencing Workflow1 is some internal event handlers result which I have no ability to dispose of.

Any clues?

Seems like an interesting bug? I don't have the profiler you mention so a couple questions.

• Is your investigation driven by some significant memory usage problems?

• How sure are you that the unload action is really completed at the time of profiling (vs about to happen asynchronously, etc)?

• It seems like the asynchronous chain is OK but the TdsParserStateObject would probably be the real object being leaked. I notice that class has a Dispose() method but doesn't implement IDisposable. So another idea is that Dispose() is used to manually 'reset' or 'recycle' the object at some distinct point in time - but that point in time turns out to be 'not yet (unload time) but later', e.g. lazy recycling. Does your profiler let you see whether the number of TdsParserStateObjects over time is increasing, to indicate a real leak there? As opposed to 'just a finite number of objects so not a real leak' leak.