<p>I have an app with the following basic architecture:</p>

<p>A windows service (Service) that registers a .NET type (RemoteObject) for remote access (.NET Remoting). RemoteObject creates non-ThreadPool threads that use the ThreadPool to do IO processing. The size of the ThreadPool must be restricted to a limit  for a particular reason. A GUI app uses .NET Remoting to access RemoteObject. </p>

<p>I've noticed that if the size of the ThreadPool is too low, the GUI app will hang when making a call to RemoteObject.</p>

<p>My question is, how can I figure out why this is hanging, and why would the RemoteObject thread be affected by the ThreadPool?</p>

<p>This is driving me crazy; thank you for your help!</p>

This may not be exceptionally helpful but I will toss it out there anyways.
When debugging services and clients that talk through remoting, I will usually always run two instances of the debugger: one for the client and one for the service.  Just to be clear, I am running two copies of visual studio.  For the service you can use the attach command or you can alter the main and call start directly (bypassing all the service code).
Here is how I typically enable debugging by altering the main, you'll have to and the DebugService call to the service, it really is just a entry point that calls start.  Once I have this I just enable service debug by definine
```
SERVICE_DEBUG
```
or changing the
```
#if
```
by adding a '
```
!'
```
.  Now you basically have converted your service to a console app.
```
```
#if SERVICE_DEBUG
            ServiceHost s = new ServiceHost();
            s.DebugService();
            Thread.Sleep( 300000000 );

#else
            ServiceBase.Run( ServicesToRun );
#endif
```
```
Once you have both setup and running you can step through the client, when the remoting calls hit the service you can step through the service code, allowing you to debug both at the same time.
Out of curiosity
are you calling the remote object directly from the GUI thread?  If so, the GUI thread will block until the remoting call completes.  This will lock up the whole GUI and make it unresponsive.  This isn't the solution to the problem, but if it is the case and your service thread isn't returning, it'll cause the GUI to hang as well.