Many .NET developers sooner or later will have to do interop with unmanaged world. Let’s say for example that you need to use some Dll written in C++. Passing integers or floats relatively easy, but things are much more complicated with strings. Many C++ Dll still uses ANSI strings, so let’s talk about them. Normally when you read Microsoft documentation you will be slightly confused. Some pages states that you have to use UnmanagedType.LPStr like it stated here: https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.unmanagedtype?view=netframework-4.8#System_Runtime_InteropServices_UnmanagedType_LPStr. And that looks like correct for ANSI strings. Moreover, you can try it and it works just fine.

Some pages stated that you have to use IntPtr: https://docs.microsoft.com/en-us/previous-versions/ms172514(v=vs.100)?redirectedfrom=MSDN and then manually prepare strings to pass

One of complications for STA COM interfaces that they have thread affinity and any function from that interface should be called only from that thread. For example, imagine that main thread actively using some COM interfaces. And in some moment GC thread started to release unused interfaces.

But GC cannot call Release function of that interface in GC finalizer thread. GC thread should switch to main thread to call Release. This is quite slow and main thread could be busy. In case when there are a lot of interfaces went on .NET side it can create huge queue of interfaces waiting for their release and there could be some other objects waiting for finalizer to be called.

As mitigate that,

Another thing that developer should be aware when consuming COM interface is apartment. It is quite long topic and I will not explain it in detail. For today discussion let’s talk about STA. If you never use COM interface in .NET from different threads you can ignore this post.

STA means single thread apartment. Normally main thread has STA. COM interface that arrives to .NET runtime usually will be marked as STA. It means that that COM interface will be used only from thread it originally passed to. It called thread affinity. There are ways to change that behavior, but it will be in later posts.

As result when you call any function on STA COM interface and current thread is not one that originally received that interface then .NET runtime will attempt to switch to that thread.

COM in .NET is very tricky to do properly, and it is source of a lot of confusions. It is quite extensive area and I will try to explain stuff I learnt from it. I would like to mention that all that I got from practice and from exploring source code of CLR and call stacks in WinDbg. But some conclusions could be wrong so use it at own risk.

Firstly, we have to start with basics. Let’s talk about case when .NET code consumes some external COM object.

.NET cannot consume COM interfaces directly, so when COM interface crosses .NET boundary runtime will create special structure called Runtime Callable Wrapper (RCW for short) and .NET native objects (it called