Why GUI Automation Stops When the Remote Desktop Window Is Minimized — Disabling the RDP Client's Render Suppression on the Connecting PC

GUI automation runs while the Remote Desktop window is visible, but stops the moment it is minimized. If you have ever run RPA, GUI tests, or AI-driven Computer Use over a Windows remote session, you may have hit this pattern. The remote server itself is still alive; what breaks is screen capture, foregrounding, or a subset of click and key operations.

Windows Remote Desktop connections use the Remote Desktop Protocol (RDP), and the connecting PC runs the built-in Remote Desktop Connection client (mstsc.exe). In the rest of this post I’ll call the protocol “RDP” and the client application “the RDP client”. When I refer to the thing being minimized, I’ll call it “the Remote Desktop window”.

One contributor to this behavior is the render suppression the RDP client applies when the window is minimized. The impact can show up in RPA, GUI tests, and Computer Use alike, though how far it propagates depends on the implementation and the environment. Setting the registry value RemoteDesktop_SuppressWhenMinimized to 2 on the connecting PC can mitigate this suppression, and both the Microsoft and UiPath official docs mention it. This post walks through the mechanism, the configuration procedure, how to verify the effect, and the states this setting does not fix.

What you observe

The typical symptoms when running GUI automation over RDP look like this:

While the Remote Desktop window is visible, screen capture, foregrounding, and clicks or keystrokes all work.
With the same session still connected, minimizing the Remote Desktop window causes only the automation to fail: screen capture returns the same image repeatedly, the target window cannot be brought to the foreground, and input events don’t register.
Services or batch jobs already running on the remote PC continue to run.

It is worth separating two things: “the remote PC’s processing has stopped” is a server-side issue; “GUI automation no longer completes” is a client-side issue tied to how the connecting RDP client’s rendering and input paths behave. This post is only about the latter.

The same symptom can occur across unattended RPA, UI-element-based GUI tests, and screenshot-driven Computer Use. The exact impact depends on factors such as:

Whether the automation operates on images or on UI elements via UI Automation.
Whether the target application needs the screen to be drawn at all (some apps only need to receive events), or whether the automation needs to read the on-screen contents.
How much the automation tool depends on bringing the target window to the foreground or giving it focus.

Image-based automation is more directly exposed to the screen no longer being updated. UI-element-based approaches may still work in some implementations. There is no safe generalization like “minimizing always removes the foreground window” or “all UI Automation stops when the window is minimized”.

Why it happens

To cut transfer and render cost, the RDP client throttles display-related work when its window is minimized. Microsoft’s Power Automate troubleshooting article lists a minimized RDP window as one cause of UI automation failures and documents setting RemoteDesktop_SuppressWhenMinimized to 2. UiPath Robot’s documentation has the same value name and the same value under its “Minimized RDP window interference” section.

When render suppression is in effect, the automation can see impacts like these:

Screen capture: the screen stops updating while minimized, so captures return the last visible frame (or a blank frame).
Foregrounding and focus: bringing a minimized window to the foreground or moving focus to it may not have the expected effect.
Mouse and keyboard input: approaches that simulate physical input often assume coordinates and foregrounding that break when the window is minimized.

How much of this you hit depends on which layer the automation operates on. Image-based automation depends on the pixels actually being drawn, so render suppression hits it directly. UI Automation reads element properties and positions and dispatches clicks and keystrokes through APIs, so some operations can succeed even without drawing. That said, if a tool mixes physical input or screenshots internally, the overall flow is still affected by minimization. Check your automation tool’s documentation for the specifics.

Computer Use, in most current implementations, sends screenshots to the model and acts via coordinate-based clicks and keystrokes. If the same render suppression is the cause, the setting below can be expected to help. Implementations differ across clients, though, so it would not be accurate to call this setting universally required or universally effective for Computer Use.

The setting

The registry value both vendors document is as follows.

Field	Value
Value name	`RemoteDesktop_SuppressWhenMinimized`
Type	DWORD (32-bit)
Value data	`2`

The setting is applied on the connecting PC, meaning the PC that opens the Remote Desktop window. It is not applied on the remote server. UiPath’s documentation explicitly notes that the change goes on the PC that connects to the Robot machine, not on the Robot machine itself.

The setting targets the built-in Windows RDP client (mstsc.exe). It is not a value owned by any specific RPA product; it affects the RDP client’s own behavior. UiPath and Power Automate are simply two vendors whose documentation points at the same registry value. Whether the same value takes effect in other RDP clients (third-party clients, Windows App, and so on) is something to verify in each client’s own documentation.

Even on 64-bit Windows, the value type is DWORD (32-bit). It is not a 64-bit QWORD.

Procedure

The target key differs between the two references. Microsoft’s troubleshooting article points at a single location:

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Terminal Server Client

UiPath’s documentation lists four locations, covering both HKCU and HKLM, and both the normal path and the Wow6432Node path.

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client
HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Terminal Server Client
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Terminal Server Client

Whether a single location is enough or whether multiple locations are needed is not clearly stated by either doc. The answer depends on the RDP client’s implementation details and on how WoW64 registry redirection applies here. Rather than guessing, apply the setting to the narrowest scope that matches your environment, then confirm the behavior. Rough guidance:

Apply to one user only: an HKCU key.
Apply to all users on the connecting PC: an HKLM key.
Match Microsoft’s article: HKLM under Wow6432Node.
Match UiPath’s documentation, covering any read path: all four locations.

In all cases, do the following before you change anything.

Back up the registry. Right-click the target key and choose Export to save a .reg file. For a full backup procedure, follow Microsoft’s registry backup guide.
Record the current value. If the value already exists, write down its current type and data so you can restore it later.
Close existing RDP sessions. Microsoft’s doc tells you to close active Remote Desktop sessions before editing the registry; closing the RDP client beforehand also gives the change a clean reload path.

Creating the value

Through the GUI, start regedit on the connecting PC (as administrator, if you are editing HKLM), navigate to the target key, and do the following:

Right-click in the right pane and choose New > DWORD (32-bit) Value.
Name the value RemoteDesktop_SuppressWhenMinimized.
Double-click the value, enter 2 under Value data, and click OK.
Close the Registry Editor.

If you prefer the command line, run the commands on the connecting PC with privileges that match the scope. HKCU writes run as the current user; HKLM writes need an elevated Command Prompt or PowerShell. A reg command that writes the HKCU normal path is:

reg add "HKCU\Software\Microsoft\Terminal Server Client" ^
  /v RemoteDesktop_SuppressWhenMinimized /t REG_DWORD /d 2 /f

To write to the HKLM Wow6432Node location that Microsoft’s doc points at, run the following from an elevated prompt:

reg add "HKLM\Software\Wow6432Node\Microsoft\Terminal Server Client" ^
  /v RemoteDesktop_SuppressWhenMinimized /t REG_DWORD /d 2 /f

After the write, exit the RDP client (mstsc.exe) and reconnect. The change is not guaranteed to apply to a live session, so always reconnect to test.

Verifying the value

Read the value back with reg query and confirm that the REG_DWORD value is 0x2.

reg query "HKCU\Software\Microsoft\Terminal Server Client" ^
  /v RemoteDesktop_SuppressWhenMinimized

Reverting

When reverting, separate two cases: the value existed before you changed it, or you created it from scratch.

If a value was already present, write back the original type and data under the same name. If it was 0, use /d 0.
If you created the value, delete it.

reg delete "HKCU\Software\Microsoft\Terminal Server Client" ^
  /v RemoteDesktop_SuppressWhenMinimized /f

After the revert, restart the RDP client before you retest.

Verification

When measuring the effect, hold conditions steady between before and after, and between visible and minimized. At a minimum, fix the following:

The connecting PC, the remote PC, the RDP client, and its version.
The automation tool, its version, and the script or flow being run.
Screen resolution, scaling, and multi-monitor configuration.
The target app’s launch state, sign-in state, and on-screen layout.

Check more than just “did the capture succeed”. Cover the steps your operation style depends on.

Did screen capture succeed, and is the captured image actually updating between successive captures? A sample app with a visible clock or counter makes this easy to confirm.
If your automation tool brings the window to the foreground or moves focus, is that step succeeding?
Do the clicks and keystrokes produce the expected UI changes in the target window? Prefer side-effect-free operations such as moving focus to a button or typing a harmless string into a scratch field.

Use a sample application that does not touch production data. Windows Notepad, Calculator, or a small WPF or WinForms app of your own with a button that updates a label all give you a clear view of both the pixels and the events.

Record the results together with the Windows version, the RDP client version, the automation tool version, and the session’s configuration (resolution, windowed vs. full-screen, multi-monitor). Don’t label anything as “improved” or “not improved” based on steps you didn’t actually run; the written record is what later teammates will read.

What this setting does not fix

RemoteDesktop_SuppressWhenMinimized is specific to render suppression when the Remote Desktop window is minimized. These are distinct states that the setting does not address:

RDP session disconnected (network drop, mstsc.exe closed, and so on).
The remote PC showing a lock screen or sign-in screen.
Signed out (logged off).
The connecting or remote PC asleep, or its display off.

In these states, either the session itself is gone or the interactive session can no longer render the target app. They need different measures (keeping the session active, disabling automatic lock or screen savers, adjusting power plans), all of which are out of scope here.

Whether the same registry value applies to other RDP clients (third-party clients, Windows App) or on non-Windows hosts isn’t clearly stated by the official references. Check each client’s documentation.

Do not disable the automation tool’s own target-window checks or safe-stop paths in the hope of boosting the effect. Those checks exist to catch misoperation; turning them off just opens the door to different failure modes.

If the setting doesn’t help, suspect a different cause. Keeping the differential to things the references actually cover:

Connection state: is the session actually disconnected or locked rather than minimized?
Privilege: is the target app running elevated while the automation isn’t, hitting UIPI restrictions? Microsoft’s troubleshooting article lists this as another cause of failure.
Capture and input method: is the automation tool using image-based, UI-element-based, or physical input, and what preconditions does each mode have? The tool’s documentation is the source of truth.

Trying unrelated remedies at random makes it hard to tell what helped and what can safely be rolled back. Keep changes small and verify one at a time.

That’s all from investigating why minimizing the Remote Desktop window stops RPA, GUI tests, and Computer Use, and from laying out the RemoteDesktop_SuppressWhenMinimized setting on the connecting PC along with its limits, from the Gemba.

Search