Resolving 'Simulator Start Skipped' Error in WinCC Flexible 2005

1. Problem Statement

When launching the Runtime with Simulator in WinCC Flexible 2005 Standard (and the closely related 2005 SP1 / 2005 SP1 HF7 builds), engineers can hit a dialog or output-window line that reads:

The simulator start was skipped because of compiler errors

Two symptoms make this fault deceptive:

1. Check Project Consistency (Project → Compiler → Check Consistency) reports no errors and no warnings.
2. Rebuild All reports compilation finished with no errors and no warnings in the Output window.

Despite the green compile output, the simulator refuses to start. The Runtime is never loaded, the simulator stub never opens, and the engineer is left with a non-functional offline test bed. The same class of failure has been reported on WinCC Flexible 2007 + HF7 and on early WinCC Flexible 2008 service packs, where the failure mode is identical: silent build, but blocked simulator start.

2. Environment and Affected Versions

Operating system coverage in the field spans Windows XP SP3, Windows Server 2003, and (with the 2008 branch) Windows 7. The 2005 branch is not officially supported on Windows 7 or later, which is one of the most common root causes observed when this fault appears in modern plants.

3. Root Cause Analysis

Five distinct root causes have been observed to produce the same surface symptom. They are listed in order of frequency in field reports.

3.1 Stale Internal Cache and Log Files

WinCC Flexible maintains per-project and global cache directories. When the project is closed unexpectedly (BSOD, kill process, power loss), or when the ES is restarted repeatedly, the following files can become inconsistent with the project database:

• <project>\*.hmi_cache\
• <project>\logs\
• %APPDATA%\Siemens\WinCC flexible\*.log
• %TEMP%\Siemens\WinCC flexible\

The launcher parses these files before invoking the simulator. A parse failure causes the launcher to refuse to start the simulator and report the generic "compiler errors" text even though the live project compiles cleanly.

3.2 Corrupt Compiler Output

When the Rebuild All operation is interrupted (for example, by an antivirus quarantine of an intermediate object file, or by a network share going offline mid-build), the *.bin and *.crc files in the transfer directory can be left half-written. The next compile run is incremental, sees its own previous output, and produces a consistent-looking build. The simulator then fails to load the half-written image.

3.3 Target / Panel Type Mismatch

If the project's target device was changed (for example, OP 177B → MP 277) without a Rebuild All, the compiled binary can reference symbol sets, screen objects, or alarm classes that are valid for the new target but inconsistent with what the simulator stub expects. The consistency checker does not always flag cross-target leftovers from a prior build.

3.4 Broken ES Installation

Missing or mismatched MS*.dll, WCFSimRT.dll, or RT.dll in the WinCC Flexible install directory will produce the same symptom. This is common after a partial reinstall, a Windows update that downgraded the Visual C++ runtime, or after switching the ES between machines using a cloned image.

3.5 Unsupported Host OS

Running WinCC Flexible 2005 on Windows 7 / Server 2008 R2 / 10 triggers UAC and file-system virtualization issues. The simulator binary writes to %ProgramFiles%\Siemens\... and the redirect to %LOCALAPPDATA%\VirtualStore\ can be invisible to the launcher, producing the same "skipped" error.

4. Diagnostic Procedure

Work the following checklist top-down. Each step takes under a minute and is non-destructive until Step 5.

1. Capture the full Output window from → View → Output. Look for any line containing warning, W0xxx, info, or skipped — not just error. A line such as Info: skipping simulation, no RT image found is the most common hidden cause.
2. Confirm the project target in Project → Device → [Panel type]. If the target was changed since the last successful build, a Rebuild All is mandatory.
3. Verify the OS: right-click This PC → Properties. WinCC Flexible 2005 only supports Windows 2000 SP4, XP SP2/SP3, and Server 2003. Anything newer is unsupported.
4. Check disk space on the project drive and on %SystemDrive%. A full or near-full disk silently breaks the simulator image write.
5. Inspect antivirus logs for quarantine of any file under %ProgramFiles%\Siemens\Automation\WinCC flexible\ in the last 30 days.
6. Create an isolation sample project: File → New → select a minimal target, add one screen with a single text field, and try to start the simulator. If the sample works, the fault is project-local, not ES-wide.

5. Resolution Method 1 — Rebuild All

The fastest, most common fix.

1. Close the project in WinCC Flexible.
2. Open the project folder in Windows Explorer and rename *.hmi_cache to *.hmi_cache_old (forces the next build to recreate it).
3. Reopen the project.
4. Select Project → Compiler → Rebuild All (or in localized builds: Projekt → Compiler → Alles neu erzeugen).
5. Wait for compilation finished — 0 errors, 0 warnings in the Output window.
6. Start the Runtime with Simulator (Ctrl+Shift+R or Start → Runtime with Simulator).

If the fault recurs after a clean shutdown, repeat with a full rebuild after rename of the cache directory, not just an incremental rebuild. The incremental rebuild path was the most frequent reason a previously working build suddenly failed after deleting compiler warnings.

6. Resolution Method 2 — Delete Temporary Files

Use this if Rebuild All did not help, or if the ES itself becomes unresponsive (the “stuck on initialisation screen” variant reported on 2007 + HF7).

1. Close WinCC Flexible completely (including the splash screen and the process tree — check Task Manager for WCFSimRT.exe and HmiEs.exe).
2. In WinCC Flexible: Options → Delete Temporary Files (in 2008+: Options → Settings → Delete temporary files).
3. If the menu is unreachable, delete the following by hand while the ES is closed:
   %APPDATA%\Siemens\WinCC flexible\
%LOCALAPPDATA%\Siemens\WinCC flexible\
%TEMP%\Siemens\*
%ProgramData%\Siemens\Automation\WinCC flexible\Logs\
4. Reboot the engineering station. This step is not optional on Windows 7 / 10 even if you have permission to write into the cache directories.
5. Reopen the project and Rebuild All.

7. Resolution Method 3 — Sample Project Isolation

Purpose: determine whether the fault is project-local (corrupt objects, broken tag connections, leftover VBScript) or ES-wide (broken installation).

1. File → New → choose a target identical to the failing project.
2. Add one screen, one text I/O field bound to an internal tag.
3. Compile and start the simulator.

If the sample project simulator starts cleanly, the original project's compiled image is corrupt. Move to Method 4. If the sample project also fails with the same message, the ES install is broken — move to Method 5.

8. Resolution Method 4 — Project-Local Recovery

1. Locate the project's backup directory: <project>\backup\. WinCC Flexible writes a *.hmi.bak snapshot on every save.
2. Open the most recent *.bak as a project, rebuild all, and start the simulator.
3. If no *.bak exists, use Project → Compiler → Check Consistency with the Verbose output option enabled. Verbose mode lists orphaned connections that the standard check suppresses.
4. Delete any screen, tag, or alarm object that was added in the same session in which the simulator last started working. The most common offender is a screen with an unsupported ActiveX control or a faceplate that references a removed library.

9. Resolution Method 5 — ES-Wide Recovery

1. Use Control Panel → Programs and Features → Siemens WinCC flexible → Repair. The repair reinstalls the simulator DLLs and re-registers the COM components.
2. If Repair is not available (common on cloned images), use the original install media and run setup.exe /repair.
3. Reapply the latest service pack: for 2005 branch, install SP1 HF7; for 2007, install the matching HF7 package from the Siemens support portal.
4. Reboot and rerun the sample project test from Method 3.

10. Resolution Method 6 — Version Upgrade

If all of the above fail and the station hardware is recent enough, the documented escape route is to migrate to WinCC Flexible 2008 SP2 (or, for new projects, WinCC Comfort/Advanced in TIA Portal V13+). The reporter who hit this on 2005 confirmed that an upgrade to 2007 cleared the fault. Migration steps:

1. Open the project in 2007 / 2008 with File → Open → Migrate.
2. Re-enter the license key — WinCC Flexible licenses are version-locked.
3. Rebuild All in the new version.
4. Test the simulator before touching the panel.

11. Verification

After any resolution path, confirm the fix with the following sequence:

1. Start → Runtime with Simulator. The simulator window must appear within 5–15 s on a modern workstation; older XP SP3 stations may take up to 30 s.
2. Verify the title bar of the simulator window contains the configured panel name (e.g., Simulator — MP 277 10" Touch).
3. Click into the simulator. The configured start screen must render without red X placeholders for missing graphics.
4. Force a tag update on the simulator (e.g., toggle a button or write to an internal tag) to confirm the tag subsystem is live.
5. Close the simulator cleanly via File → Exit, not by killing the process. A clean exit is the only way to confirm the launcher state is consistent for the next session.

12. Troubleshooting Matrix

13. Prevention

• Add the WinCC Flexible install folder, the project folder, and %APPDATA%\Siemens\ to the antivirus exclusion list on every engineering station.
• Schedule a weekly Delete Temporary Files as part of the ES hygiene routine.
• Maintain the engineering station on a Windows version that is officially supported by the installed WinCC Flexible version. The 2005 branch on Windows 7 / 10 is the most common long-term root cause of this fault class.
• Always use Rebuild All (not incremental compile) after changing the panel target, adding libraries, or importing a screen from another project.
• Document the installed service pack and hotfix level in the project header so the next engineer does not waste time on a version-mismatch diagnosis.