A solution for SharePoint’s common DISP_E_EXCEPTION COM error
Clavin Fernandes
Another post from our ‘customer support archives’. We’ll call this one ‘The case where code executed by workflows behaves differently from code executed by Application pages and why it actually was our own fault’.
We were contacted by a SharePoint developer who is using our PDF Converter to convert files to PDF format from a SharePoint Designer workflow, a common requirement. This developer clearly knew what they were doing and decided to test the system under stress by activating the workflow on a number of files simultaneously, which resulted in a number of horrible SharePoint errors in the Event log, most notably the following ones:
_Message: Exception occurred. (Exception from HRESULT: 0x80020009 (DISP\_E\_EXCEPTION))_ _\- Exception: System.Runtime.InteropServices.COMException_ _\- StackTrace: at System.Runtime.InteropServices.ComTypes.IStream.Seek(Int64 dlibMove, Int32 dwOrigin, IntPtr plibNewPosition)_ _at Microsoft.SharePoint.SPFileStream.get\_Position() …. etc_
and
_Message: Attempted to read or write protected memory. This is often an indication that other memory is corrupt._ _\- Exception: System.AccessViolationException_ _\- StackTrace: at System.Runtime.InteropServices.ComTypes.IStream.Seek(Int64 dlibMove, Int32 dwOrigin, IntPtr plibNewPosition)_ _at Microsoft.SharePoint.SPFileStream.Seek(Int64 offset, SeekOrigin origin)_ _at Microsoft.SharePoint.SPFileCollection.AddInternal(String urlOfFile, Object file, PutFileOpt fileOpt, String createdBy, String modifiedBy, Int32 createdByID, Int32 modifiedByID, DateTime timeCreated, DateTime timeLastModified, Object varProperties, String checkInComment, SPVirusCheckStatus& virusCheckStatus, String& virusCheckMessage)_ _at Microsoft.SharePoint.SPFileCollection.Add(String urlOfFile, Stream stream, Hashtable properties, Boolean overwrite)_
and the SharePoint trace log (in verbose mode) showed the following, all too familiar, messages
_ERROR: request not found in the TrackedRequests. We might be creating and closing webs on different threads. ThreadId = 10, 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.ItemUpdated(SPItemEventProperties properties) at Microsoft.SharePoint.SPEventManager.RunItemEvent..._
and
_An SPRequest object was not disposed before the end of this thread. To avoid wasting system resources, dispose of this object or its parent (such as an SPSite or SPWeb) as soon as you are done using it. This object will now be disposed. Allocation Id: {1BA98355-FDFB-4757-92E6-644DD7CED638} To determine where this object was allocated, create a registry key at HKEY\_LOCAL\_MACHINE\\SOFTWARE\\Microsoft\\Shared Tools\\Web Server Extensions\\HeapSettings. Then create a new DWORD named SPRequestStackTrace with the value 1 under this key._and
_36 heaps created, above warning threshold of 32. Check for excessive SPWeb or SPSite usage._
Anyone who has done any SharePoint development, including us, will immediately draw the conclusion that somewhere we are not disposing an SPWeb or SPSite object and if it wasn’t for the following we would agree.
-
When invoking exactly the same code through a SharePoint Application Page, which is how our end-user - non workflow - interface works, everything works great. No errors, no warnings and no memory leaks.
-
As part of our development process we thoroughly check our code for typical SharePoint dispose leaks using SPDisposeCheck. The PDF Converter comes out completely clean.
-
When using an out-of-the-box Workflow Activity such as Copy List Item, you get the same ‘errors’ in the SharePoint trace log.
-
A Google search for DISP_E_EXCEPTION SharePoint returns 1420 results, all from people tearing their hair out in despair. This problem appears to have many different causes and few common solutions.
Bummer!
So, with a nice problem that only occurs under stress at hand we fired up our debuggers. Naturally it all works great when stepping through the code. We tried all kinds of common temporary workarounds such as a big mutex around the entire Workflow Activity, a couple of Sleeps in the code to let the system ‘recover’ and even acts of desperation such as manually calling the Garbage Collector (!)….. nada.
After stripping the code down to its bare minimum, removing all calls to anything remotely complex such as the actual PDF Conversion, we noticed that we were not disposing the stream that comes of our SPFile Object. After adding a Dispose() for that stream all problems went away.
using(Stream stream = someSPFileObject.OpenBinaryStream())
{
… do your stuff
stream.Close();
}Why this is only a problem when invoked via workflows and why this has not turned up during our own stress tests is anyone’s guess. We just hope that this solution will help anyone else with the same problem.
On a separate note, I would really like to thank our customers. They are extremely cooperative when it comes to troubleshooting these kinds of errors. They happily send log files, install interim versions while staying friendly and helpful. Thanks for making our lives a lot easier.
Clavin is a Microsoft Business Applications MVP who supports 1,000+ high-level enterprise customers with challenges related to PDF conversion in combination with SharePoint on-premises Office 365, Azure, Nintex, K2, and Power Platform mostly no-code solutions.
