CoInitialize failure with many processes

Tech-Archive recommends: Fix windows errors by optimizing your registry

I have very limited experience with COM, so hopefully someone can point me in
the right direction here. I'm working with a large pile of legacy code that
uses COM, but no one here knows COM anymore. And there is no time available
to rewrite this code using .NET.

Here's the setup: We have a .NET window service that manages hundreds of C++
processes on a server. Each C++ process handles a single connection and has
to be in its own process because of everything using globals (ick, I know).
In the past, each process was it's own Windows Service, but due to
limitations on the number of services (and it's a major pain to manage), we
wrote a wrapper service to handle all these sub-processes.

Here's the problem: When we create a large number of these C++ processes
(>65 on the server, >35 on my development machine), the CoInitialize()
function returns an error indicating "The class does not exist". The
existing processes work just fine, only the new ones fail. If I kill working
processes, the new ones start working equal to the number of working ones
that I killed. If I create a new process myself and not from the service, it
works fine.

It was suggested that this may have something to do with Window Stations and
a limit within COM per station. Since each service runs in it's own station,
the previous one process per service implementation apparently worked, but
when all are in the same station we have this problem.

I have several questions probing for possible solutions. Is there a way to
kick off processes in their own station? If so, would I still have access to
kill them programmatically as needed? Is there a way to increase COM limits
to prevent this problem? If so, any issues that could result from this
change? Is there any other method for modifying how COM operates to prevent
this limit from being reached without having to rewrite all the legacy code?

We're using WinXP Pro SP2 and Server 2003, .NET Framework 2.0, VS2005. Not
upgrading to .NET 3.5 or VS2008 until after we release.

Thanks,
Dan
.