Resolving WinCC Runtime Advanced DPI Scaling and Jumbled Fonts

Problem Overview

When engineers deploy a WinCC Runtime Advanced project to a visualization PC and the runtime launches with shrunken windows, distorted text, or jumbled fonts, the root cause is almost always a DPI (Dots Per Inch) scaling mismatch between the engineering station where the project was authored and the target runtime machine. This is one of the most commonly reported issues on the WinCC Advanced V13 SP1 / Update 4 era on Windows 7 and Windows 10 platforms, and it is particularly visible in dual-monitor installations where one display runs at 100% scaling and another at 125% or 150%.

This article documents the field-proven resolution path used by automation engineers, traces the underlying mechanism that produces the symptom, and provides the verification steps required to prove the fix on a live production system. The methodology is portable across TIA Portal V13 SP1 Update 4, V14, V15, V15.1, V16, and V17 runtime targets, with specific notes where Siemens changed default behavior between releases.

Symptoms and Diagnostic Signatures

The presentation is consistent across deployments:

• Runtime window opens at a smaller physical size than configured.
• Text strings appear clipped, overlapping, or replaced by glyph blocks.
• Button labels and I/O field numerals are misaligned relative to the surrounding graphic.
• Screen-to-screen transitions resize instead of swap at constant canvas dimensions.
• The first monitor displays correctly while the second monitor shows the corrupted layout, or vice versa.
• Recompiling the project on the engineering station with DPI matched to the runtime does not restore the correct display.
• Switching the OS-level DPI from 100% to 125% on the runtime PC fixes the corrupted display but breaks the application on the adjacent monitor.

These are the signatures of Per-Monitor DPI Awareness v1 / v2 interaction with a WinCC Runtime process that was authored without explicit "Resize screen to fit runtime window" enforcement. They are not caused by corrupted fonts, missing typefaces, or GDI subsystem damage, although those secondary conditions can mask the underlying problem.

Environment and Prerequisites

The reported configuration:

Verification before troubleshooting:

• Confirm that the project source on the engineering station compiles cleanly (no warnings about missing fonts or unsupported controls).
• Confirm the .srt / .ap13 file was generated in the same TIA Portal version.
• Confirm both monitors report the same scaling factor in Windows Display Settings.
• Capture the OS build number with winver and the .NET version with reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" for inclusion in any Siemens support ticket.

Root Cause Analysis

DPI Scaling Architecture in Win32

Modern Windows applications must declare their DPI awareness to the Desktop Window Manager (DWM). Three states exist:

1. DPI Unaware — The application renders at 96 DPI (100%) and Windows stretches bitmap output to match the current system DPI. This is the legacy default for older Win32 applications.
2. System DPI Aware — The application renders at the DPI of the primary monitor when it starts. If the user drags the window to a higher-DPI monitor, Windows scales the bitmap, producing the "blurry" or "shrunken" appearance.
3. Per-Monitor DPI Aware (v1 and v2) — The application receives WM_DPICHANGED messages when moved between monitors and can re-layout dynamically.

WinCC Runtime Advanced V13 SP1 ships as a System DPI Aware binary. This is the critical fact: the runtime samples the primary monitor DPI at process launch and renders the entire HMI canvas at that fixed scale factor for the lifetime of the process. If the engineering station used 125% scaling during project authoring, the controls were laid out assuming a 25% larger logical coordinate space. When the runtime launches on a 100% system, the canvas is rasterized at 100% and every text string, button, and I/O field compresses proportionally.

Why Recompiling Does Not Fix It

Changing the engineering station DPI to 100%, saving, and recompiling the project changes the embedded layout coordinates. The runtime should then match. In practice, two issues block this path:

1. The WinCC Advanced compiler caches screen geometry per device and per DPI. Recompiling at a different DPI does not always invalidate the cached size descriptors, particularly for screens that contain complex graphic lists or faceplate instances.
2. The runtime target machine may have a system-level override (manifest, compatibility shim, or registry) that forces the executable to launch as DPI Unaware regardless of its declared awareness. This is the case for many third-party HMI / SCADA runtimes deployed in regulated industries.

The result: even a correctly authored project, compiled at the matching DPI, can be scaled incorrectly on the target if the runtime machine forces Unaware or System awareness.

Two-Monitor Interaction

When Windows detects two monitors with different scaling factors, the Window Manager enters mixed-DPI mode. The behavior of a System DPI Aware application in mixed-DPI mode is the exact failure mode reported:

• Window opened on the 100% monitor: rendered at 100% (correct for the engineering station, wrong for the screen layout).
• Window dragged to the 125% monitor: Windows upscales the bitmap by 1.25x, producing the "jumbled" stretched appearance.

This is the source of the confusing one-monitor-works-one-doesn't signature.

Primary Solution: Configure "Fit to Screen" in TIA Portal

The cleanest field-proven fix is to enforce "Fit to Screen" behavior at the project level so that the runtime stretches the authored canvas to the actual physical window dimensions at launch. This decouples the runtime rendering from the engineering-time DPI.

Procedure

1. Open the affected TIA Portal project on the engineering station.
2. Navigate to the Project View and select the HMI device (for example, HMI_1).
3. From the menu bar, select Options > Settings.
4. In the Options dialog, expand the Visualization node.
5. Select Resize screen.
6. From the Resize screen dropdown, select "Fit to screen" (alternatively labeled "Fit to Screen" depending on the language pack).
7. Click OK to apply.
8. Save the project.
9. Compile the HMI runtime: right-click the HMI device > Compile > Software (rebuild all).
10. Transfer the regenerated runtime file (*.srt, *.ap13, or *.ap14 depending on the HMI target) to the visualization PC using the path Online > HMI Device Maintenance > Transfer or by manual copy to the project folder.
11. Restart the WinCC Runtime Advanced process on the target.

The runtime now scales the HMI canvas to fill the full window dimensions of whatever monitor the window opens on, regardless of the OS-level DPI of the engineering station or the runtime target.

Why This Works

The "Fit to screen" setting writes a flag into the HMI runtime metadata that instructs the runtime to perform a one-time transform of the screen rasterization output to match the actual physical window size reported by the Window Manager. This is independent of DPI awareness and works in mixed-DPI monitor configurations.

Secondary Solution: Windows Compatibility High DPI Override

If "Fit to screen" alone does not fully resolve the problem — particularly on Windows 10 targets with Per-Monitor V2 DPI enabled — apply the compatibility override to the WinCC Runtime executable.

Procedure for Windows 10

1. Locate the WinCC Runtime Advanced executable on the visualization PC. The default path is:

   C:\Program Files (x86)\Siemens\Automation\WinCC RT Advanced\WinCCRTAdv.exe

2. Right-click the executable and select Properties.
3. Click the Compatibility tab.
4. Click Change high DPI settings.
5. Under Override high DPI scaling behavior, check the box labeled Override high DPI scaling behavior. Scaling performed by:.
6. From the dropdown, select Application (this disables the Windows DWM scaling and forces the application to manage its own layout).
7. Optionally, check Use this setting to fix scaling problems for this program instead of the one in Display settings to prevent the system-wide DPI change from affecting the runtime.
8. Click OK twice to close both dialogs.
9. Restart the runtime.

Procedure for Windows 7

Windows 7 does not expose the Per-Monitor V2 override in the compatibility UI, but the same flag can be set through the registry:

1. Open regedit as Administrator.
2. Navigate to:

   HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

3. If the Layers key does not exist, create it.
4. Add a String Value (REG_SZ) with the full path to the WinCC Runtime executable as the value name.
5. Set the value data to:

   HIGHDPIAWARE

   For Per-Monitor V1 behavior, use:

   PERMONITORV1

6. Restart the runtime.

Microsoft Documentation Reference

The compatibility override behavior is documented in the official Microsoft Learn article on DPI problems with new programs, which details the exact "Override high DPI scaling behavior" path and the meaning of the three options (Application, System, System Enhanced). See Microsoft Learn - Weird font and icon. DPI problem with new programs for the screenshot sequence and per-option semantics.

Multi-Monitor Configuration Best Practices

For dual-monitor HMI installations in industrial control rooms, the following configuration matrix is recommended:

Best practice: set both monitors to the same scaling factor at the OS level (preferably 100% for HMI displays, since 100% produces the sharpest 1:1 pixel mapping for HMI graphics) and author the project at 100% DPI on the engineering station. This eliminates the DPI variable entirely and produces the most predictable runtime behavior.

Step-by-Step Commissioning Procedure

The complete commissioning sequence for a fresh dual-monitor deployment:

1. Standardize display scaling on the visualization PC. In Windows Display Settings, select both monitors, set scaling to 100%, and apply.
2. Verify resolution match in the WinCC project. In TIA Portal, open the HMI device configuration and confirm the resolution property matches the actual physical resolution of the target monitor (typically 1920x1080 for Full HD panels).
3. Configure Fit to Screen in Options > Settings > Visualization > Resize screen.
4. Apply compatibility override on the runtime executable. Choose "Application" scaling.
5. Compile and transfer the project. Use Rebuild All to clear the screen geometry cache.
6. Launch the runtime and verify the canvas fills the primary monitor.
7. Drag the runtime window to the secondary monitor and verify the canvas reflows correctly. If the secondary monitor scaling differs, the "Fit to Screen" setting should still produce a full-screen, undistorted layout.
8. Log the final configuration in the project commissioning report: engineering station DPI, runtime PC OS build, display 1/2 scaling factors, TIA Portal version, runtime version, and the "Resize screen" setting.

Verification and Validation

To prove the fix is stable across reboots and OS updates:

• Reboot the visualization PC and confirm the runtime launches at the correct size on first paint.
• Trigger a screen change in the runtime and verify text remains sharp on both monitors.
• Disconnect and reconnect the secondary monitor while the runtime is running; confirm the runtime window either reflows or recovers to the correct size when the secondary monitor returns.
• Open the Windows Event Viewer and check for Application errors from WinCCRTAdv.exe that would indicate a DPI mismatch exception.
• Open Task Manager, right-click the column header, enable the "DPI awareness" column, and confirm the process reports "Per-Monitor" or "System" rather than "Unaware".
• Capture a screenshot of winver and the HMI runtime in the production environment for inclusion in the validation log.

Common Pitfalls and Field-Tested Caveats

Pitfall 1: Only changing OS DPI without re-authoring. Switching the runtime PC from 100% to 125% DPI may make the corrupted display look correct, but the OS will then scale all other applications on the same display, including any SCADA clients, MES terminals, or operator work-instruction viewers. This is not a fix; it is a propagation of the problem. Use the compatibility override to fix only the WinCC Runtime process.

Pitfall 2: Recompiling at the matching DPI without "Fit to Screen". If the project was authored at 125% DPI on the engineering station, changing the engineering station to 100% and recompiling changes the layout coordinates but does not always clear the cached screen size descriptors. The runtime may continue to launch at the old size. Always combine DPI matching with the "Fit to Screen" enforcement.

Pitfall 3: Ignoring Windows display per-monitor scaling settings. On Windows 10 1903 and later, the "Let me choose one scaling level for all my displays" option must be set explicitly to avoid the mixed-DPI bitmap stretch. Open Settings > Display > Advanced scaling settings and confirm the per-monitor scaling override is consistent.

Pitfall 4: Forgetting the rebuild-all step. A regular compile may not regenerate the screen geometry cache. Always use Compile > Software (rebuild all) after changing the Resize screen setting.

Pitfall 5: Running the engineering station on a high-DPI laptop display. Authoring HMI screens on a 4K laptop display at 200% scaling, then transferring to a 1080p runtime panel at 100% scaling, will produce the shrunken-window symptom on every deployment. Configure the engineering station to a 100% scaling 1080p or 1440p display for HMI authoring work.

Pitfall 6: Mixing TIA Portal versions. A project compiled in V13 SP1 Update 4 and then opened in V14 or later for incremental edits can introduce DPI metadata that the V13 runtime does not understand. Pin the runtime version to the engineering version and use the same TIA Portal installation on both the engineering station and the runtime build server.

Pitfall 7: Disabling the runtime service. On Panel PC and IPC targets, the WinCC Runtime Advanced service (SIMATIC WinCC RT Advanced) must remain set to "Automatic" startup. If the engineer stops the service to manually launch the executable for debugging, the runtime launches outside the service context and may inherit a different DPI awareness mask. Always debug through the service or use the "Start Runtime" option in the WinCC Advanced control panel.

Siemens Knowledge Base References

The following official Siemens Support articles document the underlying behaviors and are the authoritative references for the symptom and the fix:

• Siemens Support - FAQ on DPI scaling and WinCC Runtime — covers the general DPI awareness model for WinCC Runtime Advanced.
• Siemens Support - WinCC Runtime Advanced: Distorted display in dual-monitor installations — covers the specific dual-monitor symptom and the "Fit to Screen" resolution.

FAQ