Resolving Strange Font Rendering in STEP 7 V5.6 on Windows 10

Problem Details

Engineers running STEP 7 V5.6 SP2 / STEP 7 Professional 2017 SR2 on Windows 10 Pro build 1803 (and later builds up to 20H2) report a rendering defect inside the classic SIMATIC Manager project view. The default text, normally rendered in a clean Sans-Serif style, appears bold, condensed, and visually corrupted. The defect is not cosmetic: the substituted glyphs overlap the tree-view icons, consume extra vertical space, and make long block names unreadable in the project navigator.

Affected components in the affected installations:

• SIMATIC Manager – project tree, symbol table, reference data view, diagnostic buffer windows.
• F-Config (S7 F-FB, S7 F-Systems) – all editable text fields and the safety program tree.
• HW Config – catalog tree on the right pane, station/rack labels, address comments.
• NetPro – subnet view, station labels, connection table.

Components not displaying the defect in the same installation:

• WinCC Flexible 2008 SP5 – the runtime designer and the transfer dialogs render normally, but sporadic SQL Server connection faults appear during translation/compilation. The two symptoms are unrelated and should be tracked separately (see Siemens Support entry 109769927 – WinCC Flexible SQL connection diagnostics).

Root Cause

SIMATIC Manager V5.6 is a Win32 application built before Windows Display Driver Model v2 (WDDM 2.0) became the default graphics stack on Windows 10. The IDE requests the Windows system font MS Shell Dlg 2 (a Microsoft shim that maps internally to Microsoft Sans Serif) and several legacy Tahoma / Arial / Verdana cuts. When the requested face is missing, corrupted in the %WINDIR%\Fonts cache, or has its associated TrueType collection (.ttc) flagged for integrity check, the GDI/DWrite fallback layer substitutes an arbitrary replacement, which is what produces the bold, condensed appearance in the project view.

Three concrete trigger paths have been observed on Win10 1803 and 20H2:

1. System font store corruption after a Windows feature update. Build 1803 introduced a font-cache rebuild step that occasionally leaves the TTF metrics database in an inconsistent state. This explains the random resolution reported after upgrading from Windows 7 or from an earlier Windows 10 release.
2. Locale / regional font pruning. Some multi-language Windows installations (notably certain Asian SKUs and ghosted language packs) prune Tahoma, MS Shell Dlg 2, or the Arial Unicode MS face. SIMATIC Manager's Win32 control set then resolves to the GDI fallback, which renders with heavier stroke weight on HiDPI virtual sessions.
3. Anti-malware / DLP hooking of the AddFontResourceEx API during package install. Several endpoint-protection suites hold an exclusive handle on fontCache* services during a setup.exe run, which prevents the installer from writing the legacy Tahoma fallback. Result: only the bolded substitute reaches the running process.

Per Microsoft Q&A: "The font looks very strange", the same class of substitution manifests in any application that has lost access to the requested GDI face, and the recommended isolation step is to verify that the corruption reproduces in other Win32 apps (Notepad, WordPad) using the same request. If it does, the cause is system-level; if it does not, the cause is application-level (in this case, a STEP 7 hotfix gap).

Solution

Apply the fixes in the order listed. Each step is independently sufficient on a clean install, but accumulated cruft is common on field laptops, so the full sequence is recommended.

Step 1 – Patch STEP 7 to the latest service pack and hotfix

1. Download STEP 7 V5.6 SP2 / STEP 7 Professional 2017 SR2 from the official trial/license portal (entry ID 109769405 on Siemens Support).
2. Download Hotfix 9 for STEP 7 V5.6 SP2 / STEP 7 Professional 2017 SR2 (Siemens Support entry 109769930). HF9 explicitly bundles the Win32 control rendering fix that addresses MS Shell Dlg 2 substitution when the system font cache is partially rebuilt.
3. Install SP2 first, then HF9, then reboot. Do not skip the reboot; the font cache service is rebuilt during the next logon.

Step 2 – Validate the Windows font cache

1. Open an elevated PowerShell and run Get-Service FontCache | Restart-Service -Force to force the Windows Font Cache Service to rebuild its in-memory map.
2. Run DISM /Online /Cleanup-Image /RestoreHealth and then sfc /scannow to repair any TTF files flagged as integrity violations.
3. Verify the presence of the legacy faces used by SIMATIC Manager:

   Test-Path "$env:WINDIR\Fonts\tahoma.ttf"
   Test-Path "$env:WINDIR\Fonts\tahomabd.ttf"
   Test-Path "$env:WINDIR\Fonts\arial.ttf"
   Test-Path "$env:WINDIR\Fonts\micross.ttf"

   If any path returns False, copy the face from another reference machine, or install the optional feature Desktop Experience equivalents via Add-WindowsCapability -Online -Name "Language.Fonts.Hans~~~und-HANS~0.0.1.0" for the relevant script.

Step 3 – Force a font-cache rebuild

1. Stop the Windows Font Cache Service: net stop FontCache3.0.0.0 and net stop FontCache.
2. Delete %WINDIR%\System32\FNTCACHE.DAT and %WINDIR%\ServiceProfiles\LocalService\AppData\Local\FontCache\*.
3. Restart the services. Windows will re-enumerate the %WINDIR%\Fonts directory and rebuild the hash map on the next logon.
4. Log off and log on (a reboot is not strictly required for the desktop, but a full restart is preferred on 1803/20H2 because the AppReadiness service also holds font handles).

Step 4 – Confirm display scaling is at a Siemens-supported value

Siemens officially supports the classic engineering tools at 100 % scaling (96 DPI) only. HiDPI laptops running at 125 %, 150 %, or 200 % historically render SIMATIC Manager and WinCC Flexible with substituted glyphs because the embedded bitmap fonts in SIMATICManager.exe were authored for 96 DPI. To set the canonical value:

1. Settings → System → Display → Scale and layout → Change the size of text, apps, and other items.
2. Select 100 % (Recommended).
3. Log off and back on for the desktop session to pick up the new DPI cache.

Step 5 – Repair the Visual C++ and .NET prerequisites

STEP 7 V5.6 SP2 ships with Visual C++ 2005 SP1 (x86) and .NET Framework 3.5 SP1. A corrupted VC++ redistributable can re-route the GDI font path through an embedded resource that is itself substituted. Repair from Apps & Features → Microsoft Visual C++ 2005 Redistributable → Modify → Repair, then re-run the SIMATIC Manager setup.exe in Repair mode.

Verification

After completing Steps 1–4, validate the fix using the procedure below. All four checks should pass; if any one fails, return to the diagnostic matrix in the next section.

V1 – Project-view glyph audit

1. Launch SIMATIC Manager and open a representative S7-300 or S7-400 project.
2. Expand S7 Program → Blocks in the project tree.
3. Confirm that the OB1, FB, FC, and DB labels render in a non-bold, normal-weight face.
4. Open HW Config and confirm the catalog tree on the right pane is non-bold.

V2 – Reference cross-check with Notepad / WordPad

1. Open Notepad, type the string The quick brown fox 0123456789, set the font to Tahoma 8 pt.
2. Confirm the rendered text is visually identical to a known-good reference machine.
3. Open WordPad, set the same text to MS Shell Dlg 2 8 pt, repeat the comparison.

If Notepad/WordPad show the same defect, the problem is system-level (Step 2 / Step 3). If only SIMATIC Manager is affected, repeat Step 1 (Hotfix 9 install) and Step 5 (VC++ repair).

V3 – DPI / scaling audit

1. Open Settings → System → Display and record the scaling value.
2. Launch dxdiag.exe from the Run dialog and confirm Current Display Mode reports 96 DPI.
3. If dxdiag reports a different value, the per-monitor override is enabled. Disable it from Settings → System → Display → Advanced scaling settings → Let Windows try to fix apps so they're not blurry, then reboot.

V4 – Registry fingerprint

Confirm the patch level is recorded in the registry so that a future Windows feature update does not silently regress the fix:

reg query "HKLM\SOFTWARE\Siemens\Automation\STEP 7\2.0\CurrentVersion" /v InstalledHotfixes
reg query "HKLM\SOFTWARE\Wow6432Node\Siemens\Automation\STEP 7\2.0\CurrentVersion" /v InstalledHotfixes

The InstalledHotfixes value should contain the string HF9 (or a later cumulative HF).

Troubleshooting Matrix

Field-Commissioning Notes

The original report indicated that upgrading from Windows 10 1803 to 1809 "solved" the problem. The most defensible explanation is that the 1809 cumulative wave forced a clean FNTCACHE.DAT rebuild and re-pinned Tahoma / MS Shell Dlg 2 in the cache. While 1809 does resolve the symptom, it is a heavy-handed fix because 1809 is a feature update with its own regression profile. Applying HF9 plus the explicit font-cache rebuild achieves the same outcome without forcing a major Windows migration, and it is the recommended path for production engineering laptops that must remain on a validated OS image.

On multi-user terminal servers (Citrix / RDS), the substitution appears in every published session simultaneously because the font cache is shared at the host level. In that topology, rebuild FNTCACHE.DAT on the host once, then log every user off; the substitution will not return until the next font-cache invalidation event.

For engineers who maintain a custom Windows 10 image (for example, an MDT/WDS capture), the post-deploy task sequence must include the four steps in the order listed. The HF9 install must come after the language pack and desktop experience features, otherwise the installer will re-route the legacy font to the bolded substitute at first logon.

Edge Cases and Alternate Platforms

• STEP 7 V5.7 (last classic release) does not exhibit the defect because it ships with its own GDI+ shim that ignores MS Shell Dlg 2 requests. Sites on V5.7 with the same symptom should still run Steps 2–4 to rule out the system-level causes.
• TIA Portal V16 and later use a WPF renderer and are immune to the GDI substitution path. If the engineering toolchain can be migrated, the TIA portal is the long-term answer; however, the SIMATIC Manager V5.6 must remain on the same machine for legacy project compatibility, and the fix above keeps it usable.
• VMware / Hyper-V virtual desktops with the VMware SVGA 3D driver occasionally report a similar bolded font after a vGPU reset. The mitigation is to lock the vGPU memory size and disable 3D acceleration in the guest properties; do not run Step 1 against a virtual desktop without first snapshotting the VM.
• Windows 11 22H2 and later – the GDI fallback path was rewritten, so the substitution does not reproduce. Sites planning an OS migration should still apply HF9 first to keep SIMATIC Manager V5.6 supported on the new host.

Safety and Validation Constraints

STEP 7 V5.6 SP2 is a safety-relevant engineering tool (S7 F-systems). Any change to the development host must be recorded in the project's Change Log per IEC 61131-3 / IEC 61508 workflow, and the version of SIMATIC Manager used to author each F-block must be preserved with the project archive. The fixes listed above do not alter project binaries, but HF9 does change the build fingerprint recorded in the block header, so the comparison utility SIMATIC Manager → Options → Block Consistency Check must be run against the archived project after the patch is applied to confirm that no unintended block changes have been introduced.

Frequently Asked Questions