Fix WinCC Flexible 2005 SP1 Runtime Error on TP177micro Transfer

Problem Description

During project transfer from Siemens WinCC Flexible 2005 SP1 to a TP177micro HMI panel over a USB-PPI adapter cable, the engineering tool terminates abruptly with the following modal dialog:

Microsoft Visual C++ Runtime Library
Runtime Error
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application’s support team for more information.

The dialog is generated by the Microsoft C/C++ runtime DLL (typically MSVCRT.dll or MSVCR80.dll) loaded into the WinCC Flexible process. The transfer has typically progressed through project compile, communication-channel setup, and the first read attempt to the panel before the runtime aborts; the project is therefore partially prepared on the target, and a follow-up transfer is usually required even after the underlying cause is corrected.

Reproduction environment observed in the field:

• Engineering tool: SIMATIC WinCC Flexible 2005 SP1 (build 12.0.0.0), Hotfix KB918120 or later.
• Target device: SIMATIC TP177micro 6" mono (6AV6 640-0BA11-0AX0, firmware V1.1.x).
• Cable: USB-PPI (6ES7 901-3DB30-0XA0), PPI mode 187.5 kbps.
• Host OS: Windows XP Professional Version 2002, Service Pack 2, 512 MB RAM.
• Project origin: Originally compiled under a different WinCC Flexible service pack or a full version newer than 2005 SP1, then opened, edited, and re-saved in 2005 SP1.

The error is identical for both first-time transfers and re-transfers. It is a host-side crash, not a panel-side fault: the TP177micro continues to run the previously loaded image, and the panel is not bricked.

Affected Versions and Components

The following matrix summarizes the configurations in which the runtime abort has been reproduced. Items marked fixed in are minimum revisions where the underlying cause is corrected.

Root Cause Analysis

Three independent triggers combine to produce the runtime abort, and on most field units at least two of them are active. Treat each in turn before retrying transfer.

1. Graphics Library Version Skew

WinCC Flexible stores compiled screen objects with a resource signature that records the build number of the graphics runtime that produced them. When a project is opened in a service pack different from the one in which it was originally compiled, the resources are upgraded on the fly. If the upgrade encounters an icon set, custom OCX, or vector primitive that the running service pack cannot map, the runtime issues an unhandled exception 0xC0000005 inside Siemens.Simatic.Hmi.Es.Graphices.dll. The C++ wrapper above it does not catch the structured exception, so the OS terminates the process and presents the standard Microsoft C++ Runtime dialog.

2. Missing or Corrupted VC++ 2005 Side-by-Side Assembly

WinCC Flexible 2005 SP1 was rebuilt against Visual Studio 2005 SP1 and depends on the assembly:

If the SxS manifest in C:\Program Files\Siemens\WinCC flexible 2005 SP1\WinCC flexible 2005 SP1.exe.manifest cannot resolve this assembly (because the redistributable was uninstalled, replaced by a later VC++ version that removed the older SxS folder, or blocked by Windows File Protection), the loader raises an R6034 or, when the binding fails deeper in the call stack, the visible runtime abort.

3. USB-PPI Driver Mismatch with COM Wrapper

The USB-PPI cable exposes a virtual COM port. WinCC Flexible 2005 SP1 talks to the cable through a 16-bit compatible wrapper around the Siemens PC Adapter driver. When the driver has been upgraded but the wrapper DLL (s7epaapi.dll) has not, an access violation inside the wrapper during the first connect call presents itself as a generic runtime error rather than as a typed driver fault.

The diagnostic flow below separates these three causes quickly:

1. Open the project in WinCC Flexible 2005 SP1. Choose Project > Compiler > Check Consistency. If consistency fails on any screen, the graphics library is the primary cause.
2. Without the project open, start WinCC Flexible 2005 SP1 and try to create a blank project, then click Transfer. If the runtime abort reproduces on an empty project, the VC++ assembly is the primary cause.
3. Open Device Manager > Ports (COM & LPT). Confirm that the USB-PPI cable is bound to a single fixed COM port (COM1–COM8) and that the driver version in the Details tab is dated 2006 or later. If it is older, the driver is the primary cause.

Solution 1 — Reinstall WinCC Flexible 2005 SP1

A clean reinstall restores the SxS assembly, the graphics runtime, and the COM wrapper together. The steps assume the original installation media and a valid license key on the parallel port or hard disk key (dongle).

1. Insert the WinCC Flexible 2005 SP1 DVD or mount the ISO. Stop the service CCAgent and any HMI runtime instances via services.msc.
2. Open Control Panel > Add or Remove Programs and uninstall SIMATIC WinCC flexible 2005 SP1. If SIMATIC WinCC flexible 2005 (no service pack) is also present, remove it first.
3. Open %ProgramFiles%\Siemens\WinCC flexible 2005 SP1 and verify the folder is gone. If traces remain, delete them manually.
4. From the elevated command prompt, run sfc /scannow to confirm Windows File Protection is intact. Reboot.
5. Insert the media. If autorun is disabled, run Setup.exe from the root of the DVD.
6. Choose Install > WinCC flexible 2005 SP1. When prompted, install the matching language pack (English, German, French, Italian, Spanish, Chinese — the tool refuses to run without a language resource that matches the project locale).
7. When the installer offers to install SIMATIC USB-PPI Adapter, accept. This is the path that re-registers the SxS assembly and the COM wrapper together.
8. Reboot. Confirm that C:\Windows\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e69279c1 exists. (Folder hash will vary; the key tokens are 1fc8b3b9a1e18e3b and version 8.0.50727.x.)

Solution 2 — Repair the Project and Rebuild the Graphics Library

If the runtime abort only occurs with a specific project, the project itself is the trigger. WinCC Flexible 2005 SP1 stores compiled screen objects in <project>\im\<hmi>\*.rdy; older files reference icons and OCX types that the 2005 SP1 graphics runtime cannot render. The fix is to recompile cleanly.

1. Make a backup copy of the project folder.
2. Open the project in WinCC Flexible 2005 SP1.
3. Open Project > Compiler > Check Consistency. Resolve every warning and error. Pay particular attention to references on screens named with non-ASCII characters — these are the most common source of resource upgrade failures.
4. Open Options > Settings > Compile and confirm the target device is set to TP177micro, not a larger panel such as TP177A or TP270. A larger target adds graphics classes that the TP177micro firmware refuses to load.
5. For every screen, open the screen editor, click once on a free area, and press Ctrl+A then Delete on any orphaned graphic objects (they will be visible as the small empty boxes that remain when a referenced bitmap has been deleted from \grafic).
6. Choose Project > Compiler > Rebuild All. The progress bar at the bottom should reach 100% without warnings.
7. Save the project under a new name. This forces a fresh project signature.

For projects that originated in WinCC Flexible 2007 or later, the rebuild will silently downgrade some screen objects and may lose functionality. In that case, the recommended approach is to recreate the project in 2005 SP1 from scratch and copy screens via the clipboard, not via Save As.

Solution 3 — Repair the Visual C++ 2005 Runtime

If the runtime abort still appears with a brand-new empty project, install or repair the redistributable.

1. Download the Microsoft Visual C++ 2005 SP1 Redistributable (x86) from the official Microsoft redistribution page (refer to the Latest supported Visual C++ Redistributable downloads page for the current mirror).
2. Run vcredist_x86.exe /repair. On Windows XP SP2 the /repair switch is supported and re-registers every SxS file.
3. If the repair reports a missing dependency, install the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) over the top of the existing install with vcredist_x86.exe /q:a.
4. Confirm that the following files exist on disk and are the same version:
   C:\Windows\System32\MSVCR80.DLL
C:\Windows\System32\MSVCP80.DLL
C:\Windows\System32\MSVCM80.DLL
5. Reboot and re-test with an empty project.

Solution 4 — Verify the USB-PPI Cable and PC Adapter

The Siemens USB-PPI cable (6ES7 901-3DB30-0XA0) is the most common, but the original PC Adapter (6ES7 972-0CA23-0XA0, RS-232) is also supported by WinCC Flexible 2005 SP1. If the cable swap still produces the runtime abort, the driver or the COM port assignment is suspect.

1. Plug the USB-PPI cable directly into a root hub on the motherboard, not a front-panel header or a USB 2.0 hub. The 2005-era driver does not enumerate correctly through some USB 3.0 controllers on down-level operating systems.
2. Open Device Manager > Ports (COM & LPT). The cable should appear as Siemens PC USB-PPI Adapter (COMx). Right-click, choose Properties > Port Settings > Advanced and force the COM number below COM10. WinCC Flexible 2005 SP1 cannot bind to COM10 or higher when started from a non-elevated context.
3. In Device Manager > Universal Serial Bus controllers, confirm the cable is bound to a UHCI root hub, not an xHCI controller. If it is on xHCI, the cable may enumerate but the data pump will fail mid-transfer.
4. Open Start > Programs > Siemens Automation > SIMATIC > PC Adapter > Set PC/PPI Cable PG/PC Interface. Set the cable to PPI mode, 187.5 kbps, station address 0, and the timeout to 3000 ms.
5. From the same applet, run Test > All Nodes. The TP177micro must respond as node 1 (or whichever address is configured on the panel). If All Nodes reports a timeout, the runtime abort will reproduce on the next transfer attempt.

Solution 5 — Operating-System Level Recovery

Where the runtime abort reproduces on a freshly reinstalled WinCC Flexible 2005 SP1 with a fresh project and a known-good cable, the host operating system is the residual cause. A targeted recovery is faster than a full Windows reinstall.

1. Apply the latest Windows XP SP3 rollup plus the post-SP3 hotfix rollup. Several C-runtime patches (notably KB974571 and KB2535512) modify the SxS store in ways that affect MSVCR80.
2. Run regsvr32 /u mscoree.dll followed by regsvr32 mscoree.dll to reset the .NET runtime interop layer.
3. Clear the WinCC Flexible user profile: rename %USERPROFILE%\Siemens\WinCC flexible 2005 SP1 to .bak. The runtime keeps cached project metadata here; corruption is rare but documented.
4. Verify that no security suite (Symantec, McAfee, Trend Micro, Kaspersky) is injecting itself into kernel32.dll. Several 2008-era suites hook CreateProcess and corrupt the SxS binding context for child processes, which manifests as a generic runtime abort.
5. If the host has more than 4 GB of RAM installed, reduce to 2 GB or boot with the /MAXMEM=2048 switch. WinCC Flexible 2005 SP1 is a 32-bit process and was tested with up to 2 GB; larger heaps expose latent buffer overruns in the graphics engine.

Alternative Transfer Paths

When the host-side runtime abort cannot be cleared quickly, a viable workaround is to move the transfer off the USB-PPI path. The TP177micro supports PPI, MPI, and PROFIBUS-DP on the same 9-pin Sub-D connector; only the protocol framing differs.

The RS-232 path through the original PC Adapter is the most reliable workaround because it uses a different COM wrapper DLL (s7emapi.dll) that does not depend on the USB-PPI SxS assembly. If the project is large (above 4 MB compiled) the transfer will simply take longer, but it will complete.

For an overview of the transfer-error category that this runtime abort belongs to, the Pro-face documentation groups similar issues under T.6.5 Errors displayed during transfer; the same root-cause taxonomy (project mismatch, runtime mismatch, driver mismatch) applies across vendors.

Prevention and Best Practices

Once the transfer succeeds, lock the configuration so the runtime abort does not return on the next commissioning.

1. Standardize on a single WinCC Flexible service pack across the engineering team. Mix-and-match of 2005 / 2005 SP1 / 2005 SP1 HF2 across machines is the leading cause of graphics-library skew.
2. Place the WinCC Flexible install media and the latest hotfix in a versioned network share. Force the engineering team to install from the share, not from local copies.
3. Keep a copy of vcredist_x86.exe in the same share. Reinstall it as part of the standard workstation image.
4. Tag every TP177micro firmware with the panel’s serial number and the firmware build. Update the firmware to V1.1.0.0 or later; the V1.0.0.0 firmware has a transfer-state machine that is incompatible with WinCC Flexible 2005 SP1 hotfix 1 and later. See the Siemens Industry Online Support entry search for the TP177micro firmware update package (search term: TP177micro firmware update).
5. Document the COM port assignment for every USB-PPI cable in use, and disable the Windows feature Allow the computer to turn off this device to save power on the USB root hub. Suspend events mid-transfer trigger the same access violation inside the COM wrapper.
6. On commissioning day, run Project > Compiler > Check Consistency and Rebuild All on the laptop that will perform the transfer, not on the development workstation. This prevents a corrupted intermediate file from following the cable.

Verification

After applying the relevant solutions, perform the following checks in order. The transfer is considered healthy only when all checks pass.

1. Open the project in WinCC Flexible 2005 SP1. The status bar must read No errors after Check Consistency.
2. Click Transfer > Transfer. The progress dialog must reach 100% without showing a red X. A successful transfer writes the new project image to the TP177micro and triggers an automatic restart of the HMI runtime on the panel.
3. On the TP177micro, navigate to Start Center > Settings > Transfer > Information. The screen must show the new project name, the new version, and the new build date.
4. From the host, open Start > Programs > Siemens Automation > SIMATIC > PC Adapter > Set PC/PPI Cable PG/PC Interface and run Test > All Nodes. The TP177micro must respond within the 3000 ms timeout, every time, for ten consecutive polls.
5. Reboot the TP177micro from the front-panel power button. The new project must start within 30 s and the tag database must show live values for any connected PLC. A timeout here indicates that the transfer succeeded but the runtime aborted in the panel image; reflash the firmware and retry.
6. Run the panel for at least 4 hours under real load. Check the panel’s diagnostic buffer (Start Center > System > Diagnostic Buffer) for any Transfer error or Runtime error entries. A clean buffer is the final confirmation that the host-side runtime abort has been eliminated.

Troubleshooting Matrix

FAQ