Hi,

My first suggestion is to actually use the Asynchronous APIs. I have never encountered any such issues using those APIs. I have found scenarios where Windows tries to be "intelligent" about it's threads and actually attempt to keep threads waiting in the hopes that another thread will free up. For example, if you use the System Thread Pool, and block one of the threads, sometimes future calls to dispatch work to the thread pool will block until one of the threads has freed, even if there are free threads in the pool.

If you are unfamiliar or uncomfortable with using Asyncronous programming designs, I would look through your code to make sure that you aren't holding any locks on any of the system threads. In this case, the system thread would be any thread on which one of the upnp callbacks is dispatched on. If those threads are blocked, it may prevent future callbacks from occuring, because of said optimizatons.

I'm also not sure which version of the intel UPnP C# stack you are using, but I found that if you are using .NET/2.0, Microsoft changed the default threading behavior in the system. If you use the v2718 of the tools, you won't need to worry about the problem I'm about to describe:

There is a new flag in the socket object that MS defined,called "UseOnlyOverlappedIO". This value must be set to true. If it is set to false, I found that .net will use the System ThreadPool to dispatch callbacks, which causes many problems, and may be the source of your problems.