Resolving WinCC Touch Input Failures Over RDP on Thin Clients

Problem Overview

On Siemens WinCC V7 and WinCC Professional (TIA Portal) multi-client installations, the touchscreen connected to a thin client stops delivering input to the WinCC client runtime as soon as the session is reached through Microsoft Remote Desktop Protocol (RDP). Keyboard and mouse events still arrive at the remote session, but tap, double-tap, drag, and gesture events do not reach the WinCC Runtime window. On Windows MultiPoint Server (WMS) hosts with local-autologon clients deployed in clean rooms, the touchscreen is the only acceptable input device (keyboard and mouse are excluded for hygiene reasons), so the failure effectively locks the operator out of the HMI.

The original symptom reported on a WinCC V7 two-client project was that:

• Touch works correctly when the user logs on to the thin client console session directly.
• Touch stops working when the WinCC client runtime is launched inside an RDP session against the same host.
• Mouse and keyboard continue to operate normally in the RDP session.
• Closing the WinCC Runtime restores touch capability to the rest of the Windows desktop inside the RDP window, confirming that the failure is specific to WinCC and not to the RDP transport.
• Replacing RDP with RealVNC resolves the issue with no further changes to WinCC or to the touch driver.

Because the failure is reproducible on multiple machines, occurs in the latest WinCC V7 SP updates, and disappears when the transport is changed, the recommended field action is to switch the thin client transport to VNC. The remainder of this article explains why touch input fails, how to isolate the failure from a WinCC configuration problem, and which alternative transports are acceptable.

Affected Architectures and Software Versions

The exact WinCC build does not matter: the failure is a property of how the RDP transport delivers (or fails to deliver) digitiser events to the remote window, not of the WinCC version. A WinCC build upgrade will not fix it.

Root Cause Analysis: Why Touch Fails Over RDP

Microsoft RDP was designed primarily for keyboard, mouse, and visual channel delivery. Touch support was added progressively: full multi-touch digitiser support arrived in Windows 8 / Windows Server 2012 R2 through the RemoteFX USB redirection channel, and was partially retained in the newer RDP 8.0 / 8.1 / 10.0 stack. Several limitations apply on every supported RDP client:

1. Digitiser events are not always translated to the standard WM_POINTER / WM_TOUCH window messages. In some client stacks, a single tap reaches the remote session as a translated mouse click only, and is therefore susceptible to the Windows Embedded Compact 7 issue documented in Microsoft KB 2744100 where consecutive taps are not recognised as double-taps or double-clicks by the remote computer.
2. RemoteFX USB redirection of the touch digitiser is unsupported on consumer SKUs of Windows 10 and is limited on Windows MultiPoint Server 2012/2016. When the redirection channel cannot be established, RDP falls back to a synthesised pointer stream that WinCC does not subscribe to.
3. FreeRDP and rdesktop clients (common on Linux thin clients) have known defects in the touch input path. GitHub issue FreeRDP #4678 documents that touch input stops working as soon as the session lockscreen is reached, and that UAC prompts break the touch channel as well. The same digitiser-event desynchronisation affects live HMI windows.
4. The Microsoft Remote Desktop app (MSRDC) reports a 5-point limit on multi-touch sessions. As described in the Microsoft Q&A thread on Remote Desktop app touch control, RDP clients on non-Windows-8 (or non-Windows-10) hosts receive no touch input at all, and even on supported hosts the touch point count is artificially capped.
5. WinCC Runtime subscribes to the legacy WM_TOUCH and WinCC-internal touch hooks, not to synthesised pointer events. When RDP delivers only synthesised pointer messages, the WinCC touch hook layer silently drops them. Keyboard and mouse still work because they are mapped 1:1 to Win32 messages, which RDP does transport.

The result is a transport-level mismatch: the digitiser fires, the local touch driver fires, the RDP client captures the event, but the RDP server side hands it to the remote window in a form that WinCC does not consume.

Why WinCC Specifically Is Affected

Other applications inside the same RDP session may continue to receive touch input because they consume pointer messages. WinCC Runtime uses a dedicated touch input layer that relies on the underlying digitiser delivering native touch messages, not synthesised mouse messages. Three factors compound the problem:

• Multi-touch HID descriptor: The original report speculated that the touch monitor was configured with multi-touch options that WinCC does not support. WinCC V7 supports single-touch operation natively and gained multi-touch capability only in later V7.3 / V7.4 service packs; older runtimes reject any digitiser that exposes a multi-touch HID descriptor and silently fall back to a no-input state.
• Touch calibration persistence: WinCC stores the digitiser calibration under HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\WinCC\TouchScreen. The first time the runtime launches, it locks to the digitiser handle present at that moment. After an RDP session, the digitiser handle inside the remote session is virtual, not the physical digitiser, and the locked handle never matches a real device, so no touch input is delivered.
• UAC / secure desktop breaks the touch channel. Per the FreeRDP issue referenced above, UAC prompts within the RDP session cause the touch stream to be dropped, and WinCC Runtime cannot re-acquire it. The lock-on-first-touch behaviour of WinCC is therefore a one-shot event in RDP.

Diagnostic Checklist

Run the following checks in order to confirm that the failure is transport-related and not a WinCC configuration problem.

1. Verify touch on the console session of the thin client. Open the Windows Snipping Tool or Paint and tap the screen. If taps do not draw, the issue is local driver / calibration, not RDP or WinCC.
2. Verify touch on the desktop of the RDP session with WinCC closed. Tap the Start menu. If the Start menu opens, the RDP transport is delivering some form of touch input; WinCC Runtime is the component that drops it.
3. Verify the touch device in Device Manager on the RDP host. In mstsc /rdp, expose the local disk and run devmgmt.msc on the host. Confirm whether the touch digitiser appears under Human Interface Devices. If only a generic HID mouse is shown, RemoteFX USB redirection is not in effect.
4. Check the WinCC project settings. In TIA Portal under HMI device configuration > Touch / Multi-touch, confirm the touch mode matches the hardware. Disable multi-touch on multi-touch panels if the runtime is older than WinCC V7.3.
5. Inspect the WinCC log. The file %ProgramData%\Siemens\WinCC\TouchLog.txt (when logging is enabled) records the digitiser handle WinCC acquired on startup. If the handle is null or 0xFFFFFFFF, WinCC never locked onto a real device.
6. Test a non-WinCC touch application inside the same RDP session. Launch Notepad and use the on-screen keyboard. If Notepad does not accept taps either, the failure is at the RDP transport level, not specific to WinCC.
7. Switch to VNC. Replicate the exact WinCC project under a RealVNC, TightVNC, or TigerVNC server. If touch works, the transport is the cause and no further WinCC investigation is required.

Workarounds and Solutions

There is no Microsoft or Siemens-released fix that makes native touch input over RDP work in every WinCC version. The following workarounds are ordered from least to most invasive.

Workaround 1: Replace RDP with VNC (Recommended)

VNC transports framebuffer deltas and remote input events through the RFB protocol. Unlike RDP, RFB does not attempt to virtualise the digitiser; it relays the local touch driver output as a stream of pointer events. WinCC Runtime consumes those events as if they originated from a local digitiser, so the lock-on-first-touch sequence works correctly.

Configuration outline:

1. Install a VNC server on the WinCC client host (RealVNC, TightVNC, or TigerVNC). RealVNC is the one most often used in clean-room WinCC deployments.
2. Install a VNC viewer on the thin client. Confirm the viewer is configured to pass touch events to the remote host, not to convert them to local mouse events.
3. Disable the built-in mstsc RDP shortcut on the thin client to prevent accidental RDP fallback.
4. Re-launch the WinCC Runtime under the VNC session and confirm touch input is delivered.

Workaround 2: Enable RemoteFX USB Redirection for the Touch Digitiser

On Windows Server 2012 R2 or Windows Server 2016 with the Desktop Experience role, RemoteFX USB redirection can be configured to forward the physical touch digitiser into the remote session. WinCC will see a real HID device rather than a synthesised pointer.

Steps:

1. On the host, install the Remote Desktop Services role and enable the RemoteFX USB Redirection feature.
2. On the thin client, open the Remote Desktop Connection Options > Local Resources > More... and tick the touch digitiser under Other supported RemoteFX USB devices.
3. Connect to the session and verify in Device Manager on the host that the touch device now appears.
4. Re-launch WinCC Runtime. The first tap will lock the digitiser handle and touch input will work for the duration of the session.

Limitations: RemoteFX USB redirection is unavailable on most consumer Windows 10 SKUs and is removed entirely on Windows Server 2019. It is also dropped on Windows 11. This workaround is only viable on the older Windows MultiPoint Server 2012 / 2016 hosts that match the original failing configuration.

Workaround 3: Disable Multi-Touch on the Panel and Downgrade to Single-Touch Digitiser Mode

If the touch hardware exposes a multi-touch HID descriptor and the WinCC Runtime is older than V7.3, force the project to single-touch mode. In TIA Portal:

1. Open the HMI device configuration.
2. Select Display > Touch / Multi-touch.
3. Uncheck "Enable multi-touch operation".
4. Recompile and download the project.

This addresses only the digitiser-descriptor side of the failure. It will not make RDP forward touch events that RDP itself is dropping. Combine with Workaround 1 or 2.

Workaround 4: Use a Local Touch Driver on the RDP Host

Some thin client vendors (HP, Dell, Igel, Centerm) ship a local touch driver that injects pointer events into the active RDP window without going through the RDP digitiser channel. This is a vendor-specific feature and is not part of standard RDP. Consult the thin client vendor manual; it is not a Siemens-recommended path.

VNC Configuration Reference

The minimum RealVNC Server configuration that has been confirmed to work in clean-room WinCC deployments is shown below. The parameters are written to the registry on the WinCC client host.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\RealVNC\vncserver]
"SecurityTypes"="VncAuth,TLSVnc"
"Authentication"="VNC"
"QueryConnect"=dword:00000000
"QueryOnlyIfLoggedOn"=dword:00000000
"LocalInput"=dword:00000001
"IdleTimeout"=dword:00000000

Key flags:

• LocalInput=1: required so the WinCC Runtime can accept pointer events generated by the thin client.
• QueryConnect=0: prevents the connection-rejection dialog, which blocks touch on UAC prompts and is the same class of issue as FreeRDP #4678.
• SecurityTypes=VncAuth,TLSVnc: enables VNC password authentication plus TLS encryption. Required for any non-isolated network.

Touch Event Mapping Table

The table highlights the two specific failure modes: double-tap and drag. Both rely on digitiser timing that the RDP synthesised-pointer path does not preserve. VNC preserves the timing, which is why it works.

Why RDP Is Documented as Maintenance-Only by Siemens

The Siemens WinCC V7 and WinCC Professional setup notes explicitly restrict RDP to teleservicing of WinCC Clients. The wording is reproduced here for reference:

Use of the Remote Desktop Protocol (RDP) is permitted exclusively for the teleservicing of WinCC Clients. In addition, there must be no server services enabled on those computers (WebNavigator Server, DataMonitor Server or OPC Server, for example).

The restriction exists because RDP can destabilise the WinCC Runtime services and, as documented in this article, also breaks touch input on operator stations. Production operator stations should be deployed on the console session, on a MultiPoint station, or behind a VNC transport that supports pointer-event relaying.

Verification Steps

1. From the thin client, launch the VNC viewer and connect to the WinCC client host.
2. Start the WinCC Runtime. Wait for the project to fully load. Do not start the runtime via mstsc; the VNC session must be the active session.
3. Tap a known button on the HMI screen. Confirm the button activates.
4. Tap a trend / slider control and drag across the screen. Confirm the drag motion is followed continuously, not in steps.
5. Double-tap an alarm row. Confirm the detail view opens.
6. Lock the VNC session and re-authenticate. Confirm touch input still works after re-authentication (this is the FreeRDP #4678 regression check).
7. Disconnect and reconnect the VNC session. Confirm touch input still works after a fresh session.
8. Run the WinCC Runtime for at least one full shift without touch loss. If touch is lost, re-check the VNC viewer version and the LocalInput flag on the server.

Preventive Actions for New Deployments

• Specify VNC (or a thin-client vendor transport that does not virtualise the digitiser) in the project specification, not RDP.
• Order touch panels that expose a single-touch HID descriptor if the project is still on WinCC V7 prior to V7.3. Multi-touch digitiser panels cause silent touch failure on older runtimes.
• Lock the WinCC client station to a single input device in Device Manager. Disable the on-screen keyboard and the RDP-redirected pointer device so the Runtime cannot lock onto a virtual handle.
• Document the digitiser handle acquisition in the WinCC TouchLog.txt as part of the site acceptance test. Reject any project that locks onto a null handle.
• Configure the VNC server with TLS or run it on an isolated VLAN before commissioning.

Field Notes and Lessons Learned

The original failing project ran for several weeks with RDP before the operator station was converted to VNC. The conversion took under one hour per station and required no change to the WinCC project, the touch hardware, or the thin client. The original engineer reported that the suspected multi-touch configuration could not be confirmed because the VNC fix removed the need to investigate further. That experience is consistent with the present analysis: the failure is transport-level, and transport replacement is the only reliable fix.

Operators accustomed to working under RDP on Windows desktops often assume that the same experience will be available on WinCC stations. It will not. The combination of WinCC's lock-on-first-touch digitiser binding and RDP's synthesised-pointer output is a structural mismatch. Plan the transport up front, not after commissioning.