Mike,

>This is an interesting observation, but I do not that think it is the culprit. The reason is my COM object has a Login() function that opens a DBC.
>
>When app1 creates the COM object and logs in an EXE shows up in the Task Manager. When app2 create the COM object and logs in with a different DBC no additional EXE shows up.
>
>Then, when app1 runs something it is affecting the database specified by app2!

Those are the typical symptoms (and part of the definition) of a Multi-Use EXE. One "instance" sees the data intended for another "instance." In WC COM apps incorrectly built as Multi-Use instancing, you end up with page contents being returned for a different user, customer, whatever.

So, I think it is pretty clear from that -- you are running a Multi-Use instanced EXE whether you want to or not. Sounds like time to either build it with another name and CLSID or clean out the registry and re-register the correct Single-Use version. Maybe there are some duplicate registry entries?

>Whats interesting is that any more instances created in app2 create their own EXE processes. And when I release the extra ones, and release the app1 instance, and then recreate the app1 instance, we get the new EXE as we expected the first time around.

Well, that pretty much blows away my theory above. I think. Except maybe for duplicate registry entries. :-)

>It seems pretty flaky, what I'm seeing. Kindof like the flakyness you're seeing, but anoyingly different.

Another question: Is this happening on the machine you use to build the EXE or on another machine? IOW, is it possible that there is both an EXE and DLL version on the same machine with the same CLSID?