+1  A: 

It is looking like your COM interface is not properly marshaling a parameter/return variable, causing either managed memory to be free'd unexpectedly by the GC or unmanaged memory to be trashed due to some improper marshaling. You can get some finer grained control over the COM interface created by building your own Primary Interop Assembly for the COM component. With a little bit of work you can examine the offending method on the COM object and ensure all of its parameters have the correct metadata to ensure they are marshal'd correctly.

Now, the other possibility is you're marshaling everything properly, but you're not quite calling the interface correctly, manifesting itself as an improper usage of a parameter which eventually trashes unmanaged memory. These are less fun to track down, especially if you do not have access to the COM source.

One trick is to allow the program to crash outside your debugger, click Debug, which brings up the pick JIT Debugger window. Then check the 'Choose Debugging Engine' (or something to that effect) and ensure both the Managed and Native checkboxes are ticked. The VS instance which comes up should be broken in the actual code that died, rather than the closest managed code to the death.

sixlettervariables
I don't think it's the COM part, though; there's no COM usage in my test Console app usage. I suspect it's something to do with the Visual Studio automation classes, but I have no idea how to debug it.
Nick
Have you tried the crash trick to get a better callstack?
sixlettervariables