It's more that the currently active GUI thread(*) gets a small priority boost (+2 on a base priority of 7) to increase interactive performance on the basis that UI should consume very little CPU, but when it needs it, it needs it *now*. When you stop being the foreground thread, you lose that boost.

As to why that causes serial line droppage, who can say. Any modern box really ought to have enough spare oomph to deal with a serial line. You could try doing IO in a pure-IO thread and setting it's thread priority to THREAD_PRIORITY_TIME_CRITICAL (==15).

(*) Foregroundness is a property of a top-level window. If the input focus is in a particular window, then its top-level parent ought to have been automatically foregrounded at some point. Each window is attached to a particular thread by virtue of having called CreateWindow in that thread - each thread for which GUI services have been enabled by calling pretty much any USER32/GDI32 function owns a set of three layered GetMessage message queues for system/synthetic (WM_PAINT etc), input (WM_KEYDOWN) and application (WM_COMMAND) messages, which process messages for any window attached to that thread. The foreground thread is the one to which the foreground window happens to be attached, and any (well, most) keyboard/mouse messages are delivered to its input queue alone.

Aha, found it. It wasn't in fact thread priorities at all, so sorry for sending you off on a wild goose chase. It was actually to do with my event loop occasionally getting wedged in a way that only a Windows message would break it out of, and this didn't cause problems while the window had focus because it was scheduling itself a steady stream of WM_TIMERs for some reason or other. The event loop is now more sensible, and the problem has gone away.