Multiple processes and copies of static DLL data in COM DLL dependencies

Question

I wish to understand some unexpected behaviour in the running of COM DLLs, where is appears static C++ data is being shared across multiple processes. The environment is a little complex and my understanding of the various COM threading models rather weak, which I am hoping someone can help with.

The environment

• An IIS Server on a 64 bit OS running multiple C# web services, with each service in its own 32-bit application pool, and therefore process
  • The pools have the "Enable 32-Bit Applications"=True setting
• each 32 bit C# service calls a different in-process 32 bit COM DLL (so service A calls COM DLL 1, service C calls COM DLL 2. The COM DLLs are written in C++ using Qt 4.8 ActiveQt
• The COM DLLs depend on a number of 32 bit C++ DLLs, which are shared ie both COM DLLs 1 and 2 depend on Utilities.dll
• As far as I can tell, there is no ThreadingModel set for the COM DLLs, so I am expecting the system will fall back on the main STA.
  • I am aware this is frowned upon, but I do not have enough knowledge to change it currently.
• Utilities.dll contains some static C++ data
• The COM DLLs were registered using "regsvr32" and do not appear to be listed in "Component Services", though my knowledge of the latter is minimal.

The observed issue is that the static data in Utilities.dll appears to end up being shared between the different IIS processes, with undesirable consequences. I had expected that as the COM were in the main STA they would be accessed as if it were not thread safe, that each process would get its own copy of the DLL static data, but this appears not to be the case.

Can someone explain how the static data ends up shared between processes?

How can I avoid this? (apart from refactoring the code to remove all static data, which is not really viable currently)

Answer 1

If you are seeing data shared between COM objects, it means they are hosted in the same process. Yes, it's possible to share data between processes, but not accidentally. Since your app pools are different processes, it must be that these COM objects are hosted out of process, and it's just stubs that are loaded into the app pool.

If you have control of the Utilities.dll (and it sounds like you do) I would try adding some debugging information to find out what process id is hosting the COM objects. I expect you'll find that it doesn't match the app pool id, and you'll be able to use that id to find out what's going on.

Ideally it shouldn't matter where well-designed COM objects live, that's supposed to be something of an implementation detail. Is it possible to do away with the shared data structures?