Resolving WinCC PCS7 Compilation Freeze: Root Cause and Fix Guide

When a WinCC operator station inside a Siemens PCS 7 plant project is recompiled, engineers occasionally see the Compile window disappear abruptly and the entire PCS 7 engineering station lock up. The symptom is consistent across PCS 7 V8.x and V9.x projects: the compile process never reaches 100 %, the WinCC Explorer stops responding, and the OS project editor no longer accepts input. The freeze is recoverable only by terminating the WinCC process tree from Task Manager, and subsequent compile attempts reproduce the same behavior. This article documents how to capture the right log files, interpret the failure, and apply the three corrections that resolve the majority of cases.

Problem Description

The failure presents with the following observable signature on the engineering station:

• The WinCC Explorer "Compile OS" dialog opens and starts the pass (OS objects, pictures, tag export, archive configuration).
• The progress bar halts at an arbitrary point, often before reaching the "Tag Logging" or "Alarm Logging" sub-step.
• The dialog window closes silently without an error message.
• WinCC Explorer, the Component View, and in some cases the entire SIMATIC Manager stop responding to user input for 30 s to several minutes.
• CPU usage of the process CCExplorer.exe sits at 0 % while WCCILdataBuilder.exe or WCCILchartBuilder.exe remain active and peg a single logical core at 100 %.

Affected Versions and Environment

The behavior is documented for the following engineering stacks:

The root cause is not version-specific; the compile pipeline interacts with Windows services and on-disk WinCC template databases that are vulnerable to corruption regardless of the PCS 7 release.

Root Cause Analysis

Three root causes account for nearly all reported WinCC compile freeze cases. They are documented in the Siemens Knowledge Base entry 109766432 - Activating WinCC Runtime freezes during Alarm/Tag Logging and apply equally to the compile pass because the OS compile rehydrates the same Alarm Logging and Tag Logging databases that runtime activation uses.

Cause 1: Message Queuing Service Not Started

WinCC Alarm Logging depends on Microsoft Message Queuing (MSMQ) for internal event transport. If the MSMQ service is set to "Manual" start type and is currently stopped, the compile of the alarm subsystem hangs while waiting for the queue to accept a write.

Verify the service state:

1. Open services.msc.
2. Locate Message Queuing (display name) / MSMQ (service name).
3. Confirm the Status column reads Running and Startup Type is Automatic.

Cause 2: Damaged WinCC Template Database

The template databases ALG_TEMPLATE.MDF and TLG_TEMPLATE.MDF ship with WinCC and act as the seed for every OS project database. A power loss, disk full event, or antivirus quarantine can leave a template in a state where the WinCC Configuration Studio cannot read the metadata, and the compile process waits indefinitely for a response from the database engine.

Cause 3: Damaged Project Configuration File

The active project file [ProjectName].MCF (Master Configuration File) and the per-subcomponent files CCAlgHlConfig.XML, CCTlgHlConfig.XML can become inconsistent when WinCC is closed during a write. The compile routine opens these files with exclusive locks and, if the file structure is invalid, blocks forever on a read.

Diagnostic Data Collection

Before applying any fix, collect the following artifacts. They are the same artifacts that Siemens Technical Support requests when a Service Request (SR) is opened, and they will dramatically shorten time-to-resolution.

TRANSFER.log Capture

The compilation log is written to a file named TRANSFER.log inside the WinCC project directory.

Default path:

To access the log from the WinCC Explorer:

1. Select the WinCC application in the WinCC Explorer tree.
2. Right-click and choose Display compilation log (or navigate to the path above directly).
3. Copy the last 200 lines of the file. Pay particular attention to any line containing ERROR, FATAL, timeout, or a hex return code such as 0x80004005.

WinCC Diagnose Files

WinCC writes detailed diagnostic output to a fixed folder that is not deleted on uninstall.

Default path:

Compress the entire folder before attaching it to a support request. The folder contains *.log, *.txt, *.dmp, and snapshot XML files. Mini-dumps of WCCILdataBuilder.exe or WCCILchartBuilder.exe in this directory are the strongest indicator that the compile process has stopped in a database conversion routine.

Siemens Assessment Suite Snapshot

The Siemens Assessment Suite is a portable diagnostic tool that does not require installation. It enumerates installed Siemens software, Windows version, .NET runtimes, and security policies, then produces a single report file.

1. Download the Assessment Suite from the Siemens Support download center (search "Assessment Suite" under your SR portal).
2. Run it elevated from a local path that does not require write permission into Program Files.
3. Upload the generated *.zip report to your open Service Request.

TRANSFER.log Interpretation

The TRANSFER.log is a flat ASCII file with one event per line. The pattern below is diagnostic of a freeze caused by MSMQ:

2024-11-08 14:02:11.452  INFO    Compile OS - Pass 1 (Pictures)
2024-11-08 14:02:48.901  INFO    Compile OS - Pass 2 (Tags)
2024-11-08 14:03:09.118  INFO    Compile OS - Pass 3 (Alarm Logging)
2024-11-08 14:03:09.122  WARN    MSMQ queue open failed (0x80004005)
2024-11-08 14:03:09.123  WARN    Retry open in 5000 ms

If the log stops after the "MSMQ queue open failed" line, the compile is hung on Cause 1.

The pattern diagnostic of a damaged template database uses different keywords:

2024-11-08 14:05:11.118  INFO    Open TLG template database
2024-11-08 14:05:11.211  ERROR   TLG_TEMPLATE.MDF page checksum invalid (0xC0200001)
2024-11-08 14:05:11.212  FATAL   Abort compile

The pattern diagnostic of a damaged project configuration file is a parse error referencing the .MCF or one of the .XML subcomponents:

2024-11-08 14:07:31.045  INFO    Open project config: PlantView.MCF
2024-11-08 14:07:31.061  ERROR   XML parse error at line 1428 (unexpected EOF)
2024-11-08 14:07:31.062  FATAL   Abort compile

Step-by-Step Resolution

Apply the corrections in the order listed. Each step is non-destructive to the project database; however, always snapshot the project folder and the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\WinCC before starting.

Step 1: Enable and Start Message Queuing

1. Open Server Manager → Manage → Add Roles and Features.
2. Navigate to Features and enable Message Queuing (full installation including directory integration and HTTP support).
3. Reboot the engineering station if the feature was not previously installed.
4. Set the MSMQ service to Automatic (Delayed Start) and start it.
5. Retry the WinCC compile.

If MSMQ was already installed but the service was stopped, simply starting it is sufficient; do not change the startup type unless you want the service to recover from a reboot automatically.

Step 2: Repair the WinCC Template Databases

The template files live inside the WinCC installation directory:

C:\Program Files (x86)\SIEMENS\WinCC\bin\ALG_TEMPLATE.MDF
C:\Program Files (x86)\SIEMENS\WinCC\bin\TLG_TEMPLATE.MDF

Two repair paths are available:

Path A - Repair Installation

1. Insert the original WinCC installation media matching the installed version (e.g., WinCC V7.5 SP1 for PCS 7 V9.0 SP2).
2. Run Setup.exe and choose Repair Installation.
3. When prompted, select the WinCC Template Databases component.
4. Reboot when the repair finishes.

Path B - Manual Replacement

1. On a second engineering station with the identical WinCC version and language pack, copy the two *_TEMPLATE.MDF files from the same bin directory.
2. Verify the file sizes match exactly; mismatched sizes indicate a different service pack or hotfix level.
3. Stop the CCAlgHlServer and CCTlgHlServer services on the affected station.
4. Replace the damaged files and restart the services.

Step 3: Recover the Project Configuration File

The Master Configuration File and its XML siblings are backed up automatically by WinCC into the project backup subfolder. Restore the most recent good copy:

1. Close WinCC Explorer and confirm the CCExplorer.exe process is not running.
2. Open the project folder: [ProjectPath]\wincproj\[WinCCApplicationName].
3. Sort the backup subfolder by date modified and select the most recent set written before the compile began to fail.
4. Copy the .MCF file and the CC*.XML files into the project root, overwriting the current versions.
5. Right-click the WinCC application in WinCC Explorer and choose Compile OS to test.

If the backup is also corrupted, an entire project restore from the most recent *.pccbackup archive is the next option. This is destructive to post-backup changes; coordinate with the plant operations team before performing it.

Full Project Rebuild Procedure

If the OS-specific fixes above do not unblock the compile, perform a full WinCC project rebuild. This is the same procedure that the TIA Portal uses for HMI projects, adapted for the WinCC Explorer.

1. Close the WinCC application in WinCC Explorer.
2. Right-click the OS in the component view and select Compile OS > Software (rebuild all).\li>
3. Monitor the TRANSFER.log in real time using the Display compilation log context menu; the log is overwritten on each compile pass.
4. If the rebuild passes, re-apply any delta configuration (added tags, alarms, scripts) and re-compile incrementally.

The rebuild-all pass is documented in the TIA Portal WinCC readme at Compiling and loading - WinCC and applies to the equivalent operation in WinCC Explorer.

Verification

After each fix, validate that the compile completes and the runtime can be activated without freezing:

Escalation via Service Request

If the compile still freezes after the three corrective actions have been verified, escalate to Siemens Technical Support with the following package:

1. The complete TRANSFER.log from the most recent failed compile.
2. The zipped C:\Program Files (x86)\SIEMENS\WinCC\diagnose folder.
3. The Siemens Assessment Suite report.
4. The exact PCS 7, WinCC, and Windows versions and patch levels.
5. A list of recently installed software, Windows updates, or antivirus events.
6. Steps already attempted.

Reference Siemens Knowledge Base entry 109766432 in the SR description; it is the same article that documents the three primary causes and accelerates the triage.

Preventive Recommendations

• Exclude the WinCC project directory and C:\Program Files (x86)\SIEMENS\WinCC from real-time antivirus scanning. Many enterprise endpoint protection products quarantine .MDF files mid-write, which is the most common trigger of the template database cause.
• Set the MSMQ service to Automatic via Group Policy so the service is restored after a reboot without operator intervention.
• Schedule a daily project backup that copies the WinCC project folder to a network share with a 7-day retention.
• Use a UPS on every engineering station to prevent mid-write corruption of *.MDF and *.MCF files.
• After any Windows cumulative update on the engineering station, perform a test compile on a non-production project to catch regressions early.

FAQ