title: Multiple processes and copies of static DLL data in COM DLL dependencies
body: <p>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.</p>
  
  <p><strong>The environment</strong></p>
  
  <ul>
  <li>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
  <ul>
  <li>The pools have the "Enable 32-Bit Applications"=True setting </li>
  </ul></li>
  <li>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</li>
  <li>The COM DLLs depend on a number of 32 bit C++ DLLs, which are shared i.e. both COM DLLs 1 and 2 depend on Utilities.dll</li>
  <li>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. 
  <ul>
  <li>I am aware this is frowned upon, but I do not have enough knowledge to change it currently.</li>
  </ul></li>
  <li>Utilities.dll contains some static C++ data</li>
  <li>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.</li>
  </ul>
  
  <p>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.</p>
  
  <p>Can someone explain how the static data ends up shared between processes?  </p>
  
  <p>How can I avoid this?  (apart from refactoring the code to remove all static data, which is not really viable currently)</p>