Resolving WinCC Tahoma Font Errors After VMDK to VHD Conversion

Problem Description

After converting a Windows 7 Ultimate 32-bit virtual machine from a VMware VMDK to a Microsoft Hyper-V VHD/VHDX, SIMATIC WinCC Flexible 2008 SP2 and TIA Portal V11 (with WinCC inside TIA) both refuse to compile existing HMI projects. The same project files compiled successfully on the original VMware image, and the .hmi / .ap11 source archives have not changed. The failure manifests immediately on first compile after the migration. Two distinct error strings appear depending on the engineering tool used:

• WinCC Flexible 2008 SP2: Internal error (detail: Unable to determine the system font folder)
• TIA Portal V11 (WinCC inside TIA): The 'Tahoma' font is not installed. Check the installed fonts.

Inspection of C:\Windows\Fonts\ confirms that both tahoma.ttf and tahomabd.ttf are physically present on disk. The failure is therefore not a missing-file condition but an environmental one: the engineering tool cannot bind the system font folder at runtime.

Affected Software and Versions

Although this article focuses on WinCC Flexible 2008 SP2 and TIA Portal V11, the same diagnostic procedure applies to any 32-bit Siemens HMI engineering tool that queries the system font folder through SHGetFolderPath or SHGetKnownFolderPath. Refer to the official Siemens Knowledge Base article 109744942 on Tahoma/Segoe UI font behavior in TIA Portal projects.

Root Cause Analysis

The migration from a VMware virtual disk controller to a Hyper-V virtual disk controller triggers four overlapping mechanisms. In most field cases at least two of them are active simultaneously.

1. Disk signature and drive-letter reassignment

When the VMDK is converted to a fixed or dynamically expanding VHD/VHDX and attached to a Hyper-V Generation 1 or Generation 2 VM, the Windows Plug and Play storage stack re-enumerates the disk. If the offline conversion tool (such as qemu-img convert -f vmdk -O vhd, StarWind V2V Converter, or Microsoft Virtual Machine Converter) writes a new disk signature, Windows may treat the system disk as a "new" disk during the first boot and reassign the volume mount points. The system partition can land on D: or E: while C: becomes a data volume. WinCC Flexible, however, hard-codes the assumption that the system drive is %SystemDrive% and that %SystemRoot%\Fonts resolves to the font folder referenced by the WinCC API. When the API call resolves against a non-system volume, the engineering tool raises Unable to determine the system font folder. Microsoft's official Hyper-V virtual hard disk conversion documentation describes the signature-handling caveats.

2. Tahoma font registration drift

Tahoma is shipped with Windows 7 by default and is registered under the registry path:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts

with values such as:

"Tahoma (TrueType)"="tahoma.ttf"
"Tahoma Bold (TrueType)"="tahomabd.ttf"

When a system is sysprepped, generalized, or migrated across virtual controllers, the font service can fail to recreate these string values if the profile hive is not fully loaded. The .ttf file is still on disk, but AddFontResource cannot bind it because the registry mapping is absent. TIA Portal V11 calls AddFontResourceEx at compile time and surfaces the explicit Tahoma font is not installed error.

3. Elevation and UAC file-virtualization context

When WinCC Flexible is launched as Administrator on Windows 7 with UAC enabled, the font enumeration call is redirected to the virtual store at %LOCALAPPDATA%\VirtualStore\Windows\Fonts\. WinCC Flexible 2008 SP2 uses an older path-resolution API that does not follow the virtualization redirection, so it returns an empty string for the font folder. Running the same project under a standard user account returns the correct path and the project compiles normally. This behavior is documented for legacy 32-bit applications in the Microsoft Access Control and UAC documentation.

4. Generation 2 Hyper-V virtual machine compatibility

TIA Portal V11 and WinCC Flexible 2008 SP2 are 32-bit (x86) applications built for the Windows 7 / Server 2008 R2 era. They depend on legacy HAL, ACPI 1.0, and IDE-style disk emulation. A Generation 2 Hyper-V VM uses a UEFI firmware and a SCSI-only boot path. The OS still installs, but several legacy APIs return non-standard values. Microsoft's official Generation 1 vs Generation 2 comparison states that legacy OS support is limited to Generation 1.

Pre-Diagnostic Checklist

Run the following checks in order before applying any fix. Each check produces an objective pass/fail result that maps to one of the resolution paths.

1. Open Control Panel → Fonts and confirm Tahoma and Tahoma Bold appear in the list. If absent, jump to Resolution Path 1.
2. Open regedit as Administrator and navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts. Confirm the Tahoma (TrueType) and Tahoma Bold (TrueType) string values exist. If absent, jump to Resolution Path 1.
3. Open an elevated command prompt and run echo %SystemRoot%. The output should be C:\Windows. If it shows another drive letter, jump to Resolution Path 3.
4. Run diskpart → list volume and confirm the System Reserved or Boot partition is mapped to the drive that holds \Windows\System32. If not, jump to Resolution Path 3.
5. Open Task Manager → Details, start WinCC Flexible, and check whether the process is running under an elevated token (the UAC Virtualization column shows "Enabled" in older builds). If elevated, jump to Resolution Path 4.
6. Open Hyper-V Manager → Settings → Security on the affected VM and confirm the generation is Generation 1. If Generation 2, jump to Resolution Path 5.

Resolution Path 1: Re-register the Tahoma Font

Use this path when the Tahoma .ttf files are present on disk but missing from the registry or from the per-user font enumeration.

1. Close all Siemens engineering tools, including WinCC Flexible, TIA Portal, and the WinCC RT preview.
2. Open an elevated command prompt.
3. Verify the physical files exist:

dir "%SystemRoot%\Fonts\tahoma.ttf"
dir "%SystemRoot%\Fonts\tahomabd.ttf"

4. Re-register the font using the legacy registration utility:

cd /d "%SystemRoot%\Fonts"
regsvr32 /s tahoma.ttf
regsvr32 /s tahomabd.ttf

5. If the DLL registration fails with 0x80004005, force the registry entries directly:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts" \
  /v "Tahoma (TrueType)" /t REG_SZ /d "tahoma.ttf" /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts" \
  /v "Tahoma Bold (TrueType)" /t REG_SZ /d "tahomabd.ttf" /f

6. Reboot the VM to allow the font engine to rebuild its cache at %SystemRoot%\System32\FNTCACHE.DAT.

Resolution Path 2: Repair the System Font Folder Binding

Use this path when the WinCC Flexible Unable to determine the system font folder error persists after Tahoma is correctly registered. The error is raised when the API call to resolve FOLDERID_Fonts returns E_FAIL. The fix is to repair the known-folder registry entries:

1. Open regedit as Administrator.
2. Navigate to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders.
3. Confirm the {BD7A2E7B-21CB-4B4D-8501-0D80819DB3F8} entry (FOLDERID_Fonts) has a string value of %SystemRoot%\Fonts. If the value is empty or points to a non-existent path, set it to %SystemRoot%\Fonts.
4. Repeat for HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders.
5. Navigate to HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders and apply the same fix. The Wow6432Node mirror is what 32-bit applications such as WinCC Flexible 2008 SP2 actually read.
6. Sign out and sign back in (or reboot) to refresh the shell folder cache.

Resolution Path 3: Fix Drive Letter and Disk Signature Reassignment

This is the most common silent failure after VMDK-to-VHD conversion. The fix is to force the system partition back to C: using the Windows Recovery Environment or an in-place diskpart session.

1. Boot the VM from a Windows 7 32-bit ISO mounted to the Hyper-V virtual DVD drive.
2. Choose Repair your computer → Command Prompt.
3. Run diskpart → list volume and identify the volume that contains \Windows\System32\config\SYSTEM.
4. If that volume is not mounted at C:, assign the letter C: explicitly:

select volume <n>
assign letter=C

5. If the System Reserved (or EFI System Partition on Gen2) has been reassigned, restore its original letter as well. The reserved partition must remain at the letter Windows assigns it during the BCD enumeration.
6. Reboot into the OS and confirm:

echo %SystemRoot%
echo %SystemDrive%

Both should report C:\Windows and C:. Open WinCC Flexible and recompile.

Resolution Path 4: Run WinCC as a Standard User

If the diagnostic checklist reports that WinCC Flexible is running with the UAC Virtualization column set to Enabled, the engineering tool is running elevated and is being redirected through the VirtualStore. Launch the tool under a non-elevated token.

1. Hold Shift and right-click the WinCC Flexible 2008 SP2 shortcut.
2. Choose Run as different user.
3. Enter the credentials of a member of the local SIMATIC HMI group (or the equivalent engineering group) but not the local Administrator account.
4. Open the project and recompile.

The same procedure applies to TIA Portal V11. The TIA Portal launcher explicitly checks the integrity level of the process and refuses to start the compile pipeline on a High integrity token if the project references a 32-bit faceplate compiled against an older Windows SDK.

Resolution Path 5: Down-Generation the Hyper-V VM

If the converted VHD was attached to a Generation 2 Hyper-V VM, the legacy HAL mismatch described in Root Cause #4 will manifest as inconsistent font and shell-folder API results. The VHD must be reattached to a Generation 1 VM.

1. Shut down the VM.
2. In Hyper-V Manager, export the VHD/VHDX to a safe location.
3. Delete the Generation 2 VM (keep the VHD).
4. Create a new VM and select Generation 1 on the wizard's Specify Generation step.
5. On the Connect Virtual Hard Disk step, choose Use an existing virtual hard disk and point to the exported file.
6. Set the IDE controller 0 to attach the VHD on the primary master channel.
7. Boot and re-run the diagnostic checklist.

Microsoft's Generation 1 vs Generation 2 decision matrix confirms that Windows 7 32-bit is supported only on Generation 1.

Resolution Path 6: Patch the WinCC Flexible Installation

If all five paths above have been applied and WinCC Flexible still reports Unable to determine the system font folder, repair the Siemens installation itself. WinCC Flexible 2008 SP2 ships a self-contained font-cache rebuild utility that re-binds %SystemRoot%\Fonts against the registry on first launch.

1. Insert the WinCC Flexible 2008 SP2 installation media (or mount the ISO).
2. Run setup.exe /repair from the media root.
3. When the installer prompts for the setup type, choose Modify.
4. Enable the WinCC Flexible Engineering Component and the WinCC Flexible Runtime features if they are unchecked.
5. Complete the repair and reboot.

Refer to the Siemens Knowledge Base article 66562462 for the supported repair procedure.

Resolution Path 7: Replace Tahoma with the Correct Revision

In rare cases the Tahoma .ttf shipped with the original Windows 7 image was overwritten during the VMDK-to-VHD conversion by a Windows 10 font cache or by a GenericNonSpecificTahoma placeholder. The replacement file resolves to a different family name and WinCC refuses to bind it. Verify the family name with PowerShell:

$shell = New-Object -ComObject Shell.Application
$folder = $shell.NameSpace(0x14)
foreach ($item in $folder.Items()) {
  if ($item.Name -like '*ahoma*') {
    [PSCustomObject]@{
      Name        = $item.Name
      Type        = $item.Type
      Path        = $item.Path
      SizeBytes   = $item.Size
    }
  }
}

The Name column must contain exactly Tahoma and Tahoma Bold. If the name shows Tahoma Regular or Microsoft Tahoma, replace the file with the stock Windows 7 32-bit version.

Verification

After applying one or more of the resolution paths, run the following verification sequence. Each step produces a concrete pass criterion.

1. Open the project file in WinCC Flexible 2008 SP2. Confirm the project loads without the Internal error dialog.
2. Compile: Project → Compiler → All (rebuild). The Output window must show Compile completed successfully with zero W or E lines.
3. Open the same project in TIA Portal V11: Project → Compile → Software (rebuild all). The Inspector window must show Compilation finished without errors.
4. Open the HMI faceplate in the TIA Portal editor. Click any text element that uses Tahoma. The Properties pane must list Tahoma, 10pt (or the configured size) and not <Missing Font>.
5. Run the WinCC RT preview for ten minutes. The runtime must not emit Event Log entry 7001 or 7002 related to font loading.
6. Reboot the VM. Repeat steps 2 and 3 to confirm the fix survives a power cycle.

Troubleshooting Matrix

Prevention and Best Practices

• Snapshot before conversion. Always take a Hyper-V checkpoint before any virtual-disk-level operation, and a VMware snapshot immediately before exporting the VMDK.
• Document the disk signature. Before conversion, run diskpart → select disk 0 → detail disk and record the Disk ID. After conversion, compare the ID; mismatches indicate that the converter rewrote the signature.
• Pin the system drive. Lock the boot volume to C: by setting the \DosDevices\C: symbolic link in the registry before the conversion, then validate after the first Hyper-V boot.
• Standardize on Generation 1 for any VM that runs WinCC Flexible 2008 SP2, TIA Portal V11, or any 32-bit Siemens HMI engineering tool released before 2016.
• Pre-stage Tahoma. Extract tahoma.ttf and tahomabd.ttf from a verified Windows 7 32-bit install media into a side-load directory (C:\Siemens\Fonts\) and re-register from there during the post-migration hardening script.
• Use a deployment automation script. Bake the registry entries of Resolution Paths 1 and 2 into a PowerShell DSC configuration or a Microsoft Endpoint Manager Intune Win32 app package that runs on first boot.
• Disable Hyper-V dynamic memory on HMI engineering VMs. Memory hot-add can re-trigger font-cache rebuilds and re-introduce the symptom mid-compile.

Related Siemens Error Codes

Frequently Asked Questions