Application hung during CoCreateInstance when using Isolated COM

Question

When I don\'t configure a client DLL (globalsd.dll) to use Isolated COM to access a .NET assembly that exposes a COM interface (FSCulture.dll) before r

Answer 1

There are many pitfalls when attempting to set up isolated COM between an un-managed client and a managed server. One of them is the fact that the isolated COM settings are not intended for this scenario (I believe they are for referencing an un-managed server). I suspect another is that trying to debug this configuration without having the proper manifest files embedded can result in different results between release mode and debug mode because of where, how and when manifest files are generated. All the answers for fixing the scenario in this question are now covered at https://stackoverflow.com/a/34076433/78162.

Update: More details about the root cause of this issue have been discovered after discussions with Microsoft on related issue Application hanging during CoCreateInstance of .NET-based COM object

Namely, one must be careful when creating static instances of objects that require dynamic initialization in a DLL because those will run during DllMain if the /clr compiler switch is not applied to the source file, and DllMain can cause deadlocks if managed code is referenced within its scope due to loader locks documented in more detail at https://msdn.microsoft.com/en-us/library/ms173266(v=vs.120).aspx

One simple solution (the one I used when re-encountering this issue on another context) is to apply the /clr compiler switch to the source file that had a static instance of an object whose constructor referenced a managed-code COM object.