How Windows XP Fast User Switching Handled Apps

Introduced in Windows XP, Fast User Switching (FUS) revolutionized multi-user environments by allowing multiple accounts to stay logged in simultaneously without closing active applications. Instead of terminating a session, the operating system maintained the user's state, running processes, and memory allocations in the background. This article explains the underlying Terminal Services architecture, how background processes were handled, and the hardware and software implications of this feature.

The Underlying Terminal Services Architecture

Fast User Switching was built directly on the Terminal Services architecture originally developed for Windows NT 4.0 and Windows 2000 Server. Rather than running a single interactive session, Windows XP treated each logged-in user as an independent, isolated session (such as Session 0, Session 1, and so on).

When a user opted to switch accounts, the operating system did not log them off. Instead, it disconnected the physical console (the monitor, keyboard, and mouse) from the active user's session and reattached it to the new user's session. The disconnected session simply entered an unattached state while continuing to exist in system memory.

Behavior of Background Processes and Applications

Because disconnected sessions remained active, processes running inside them did not pause automatically:

  • Continuous Execution: Tasks that required CPU cycles—such as file downloads, CD ripping, video rendering, or defragmentation—continued running in the background while another user worked on the desktop.
  • Audio Playback: Audio output typically continued playing across the system by default unless the application relied on an exclusive audio device lock or the sound driver did not support multi-stream mixing.
  • Network Connections: Dial-up connections, virtual private networks (VPNs), and local network connections established by an inactive user remained active, maintaining network connectivity across sessions unless explicitly disconnected.

Memory Allocation and Paging

Fast User Switching placed a significant load on system resources, particularly physical RAM:

  • Resource Sharing: All logged-in sessions competed for the same pool of physical memory and CPU resources.
  • Virtual Memory Paging: When the active user launched demanding applications and physical RAM became scarce, the Windows XP Virtual Memory Manager automatically paged the memory working sets of inactive sessions out to the pagefile (pagefile.sys).
  • Switching Latency: While paging allowed the system to prevent out-of-memory crashes, it introduced notable disk thrashing when returning to an inactive session. Switching back often caused noticeable delay while the system read the user's minimized applications and desktop state back into physical RAM.

Compatibility Issues and Hardware Locks

The architecture of Fast User Switching exposed several compatibility challenges for legacy 32-bit software:

  • Global Mutexes and Named Objects: Many pre-XP applications used global named objects to enforce single-instance limits. If User A had such an application open, User B would be blocked from launching it, often receiving an error or failing silently.
  • Exclusive Hardware Access: Hardware components that did not support multi-client virtualization—such as 3D graphics cards running DirectX/OpenGL applications, scanners, or dial-up modems—could lock up or crash if a second user attempted to access the same resource simultaneously.
  • Shared File Locks: If an application held an exclusive read/write lock on a file in a shared directory, another user could not open or edit that file until the original user saved, closed the file, or logged off entirely.