AccessViolationException occurs randomly in .NET application using COM interop

0
votes

Recently we rewrote a working prototype library using structured programming techniques for maintainability. It accesses data from a third-party application (TPA) using the application's COM-based API. The API uses Win32 messaging (WM_COPYDATA) to communicate with TPA.

The new library code:

  1. Is written in C# with Visual Studio 2010 SP1.
  2. Targets .NET Framework 4 (was 3.5 in the prototype).
  3. Uses anonymous methods and new custom generic classes to factorise and simplify the original code, which does not use either (except for a few .NET Framework utility types like HashSet<>).
  4. References the COM-based API using unembedded interop types (Embed Interop Types=False) and registration-free COM (Isolated=True).
  5. Uses Marshal.ReleaseComObject for deterministic memory management with objects returned by the COM-based API.
  6. Uses the COM-based API only on a worker thread which runs in a single-threaded apartment (the COM-based API is apartment-threaded).
  7. Uses early binding when calling into the COM-based API.

Our tester application crashes randomly with AccessViolationException in the COM-based API. The stack trace shows that this occurs either in a call to UnsafeNativeMethods.DispatchMessageW (see sample below) or any of several different properties in the COM-based API. The tester application is a simple WinForms app with a menu, status bar and RichTextBox.

This behaviour is common to Windows XP and Windows 7, whether or not inter-thread communication between the worker thread and UI thread is enabled, whether or not we replace ReleaseComObject by FinalReleaseComObject. It seems to crash more frequently when TPA is very busy, eg. while it is starting up.

The prototype library was developed using VS 2008. After converting the project to VS 2010, the prototype application still does not crash.

System.AccessViolationException was unhandled Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Source=System.Windows.Forms StackTrace: at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg) at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData) at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.Run(Form mainForm) at IndexerTester.Program.Main() in D:\TestApps\Indexer\IndexerTester\Program.cs:line 17

Have you seen similar problems?

Can you offer any advice on isolating the cause and/or a potential workaround?

1
c#.netcom-interop
The call stack shows a call being marshaled from the worker thread to the main thread. Your STA only works if you create the COM object on that STA thread. But that's not likely the problem, native code rarely needs much help from a C# program to bomb on an AV. You can't see anything because you didn't enable unmanaged debugging. - Hans Passant
Thanks, I didn't know this call stack represents inter-thread marshaling. Unfortunately I'm not experienced with unmanaged debugging. I'm not sure I can use it because I don't have access to the COM source code or its PDB file. Can you suggest some resources for learning how to do this? - groverboy
There's little you can without those resources. Write a unit test to repro the crash. And send it to the owner of the code to get him to help you out. - Hans Passant
Thanks again. Your point about inter-thread marshaling helped me to realize that this happens whether or not the worker thread sends its status/progress to the UI thread. I guessed that the COM object is responsible for this marshaling. When I removed the worker thread the error went away; so there is a conflict between the COM object and the worker thread. The COM object uses Win32 messaging; I am going to try restoring the worker thread, adding a message pump for the COM object to use. - groverboy
Update: we sent a bug report to the vendor of the COM object. The vendor confirmed there is a bug in its code (a non-threadsafe static variable) and issued a fix. - groverboy

1 Answers

1
votes

This is a little late but may help someone.

We sent a bug report to the vendor of the COM object: AccessViolationException occurs when using two instances, each on a different thread. The vendor confirmed there was a bug in its code (a non-threadsafe static variable) and issued a fix.

We noticed that crashes were more frequent when both the third-party application (TPA) and our tester application (reading data from TPA) were busy.

Crucially, we found that with a heavy workload, crashes occurred also using the prototype application; we had assumed wrongly that our rewrite had introduced a bug. That discovery convinced us to report this to the vendor.