Is there something about C++ / C# interop that initializes the threading
model to MTA so that OleInitialize will fail?

I have a mostly C++ app that calls a single C# class DLL. Only one source
file in the C++ app is compiled as managed (with /clr) – the single file in
which only one of the many functions creates a class object from the C# DLL
and invokes its methods (to decode an XML file the easy way).

During normal execution my code eventually creates an instance of an
MSFlexGrid ocx object (a grid control with column and row headers), which in
turn calls AfxOleInit and therefore OleInitialize. Works fine in normal
execution. I believe OleInitialize is by default STA.

By “normal” execution I mean the situation when I do not execute any code in
that single C++ file that calls into the C# DLL. If, however, I call
functions in that C++ file (even if they do not call the only function that
invokes C#), then when I create the MSFlexGrid object the internal call to
OleInitialize fails with the Trace message “Warning: OleInitialize returned
scode = RPC_E_CHANGED_MODE ($80010106)”.  

From the help files it sounds like OleInitialize expects to be run in STA
mode, and the error message means “A previous call to CoInitializeEx
specified the concurrency model for this apartment as multithread apartment
(MTA)”. I tried putting breakpoints on every bit of MFC / ATL source code
that calls OleInitialize or CoInitialize to see if I could find the offender,
but nothing trapped.

If I create the MSFlexGrid before invoking C#, all is fine, and if I call
OleInitialize at the very beginning of my app all is fine. But I’m worried
there is a threading disaster waiting to happen.

What’s the deal?