Troubleshooting WinCC 7.0 SP3 DataManager "Update Data Lost, Actual Queue Size" Error

SIMATIC WinCC V7.0 SP3 engineers frequently encounter a runtime alarm of the form 1000200,4,DataManager Runtime, Update data lost, actual queue size = 1048764 bytes, high water mark = 1048576, low water mark = 819200. The message is generated by the WinCC DataManager when its internal tag-value queue saturates faster than the consumer processes can drain it. This article decodes the alarm, walks through the root causes, documents the diagnostic procedure inside the WinCC Diagnose folder, and lists the configuration and platform-level mitigations that bring the queue under control. The companion Update 2 for WinCC V7.0 SP3 (and WinCC V7.0 SP3 ASIA) should be applied as a baseline fix for any project still running the released-to-market (RTM) build.

1. Problem Overview

On a single-station WinCC V7.0 SP3 project (no WinCC Client attached) the operator console starts logging the following entries in WinCC Explorer > Computer > WinCC Explorer > Logs or in the *.LOG files of the project:

255,20.07.2016,01:01:16:567,1000200,4,,USER-PC,DataManager Runtime,
Update data lost, actual queue size = 1048764 bytes,
high water mark = 1048576, low water mark = 819200

The same alarm may also be raised on the WinCC Server side of a distributed (multi-client) project, in which case the alarm points to a WinCC Client that is not fetching values from the server queue. The variants share the same root cause - the DataManager cannot place new tag values in the queue because the buffer is full and the consumer (Graphics Runtime, Alarm Logging, Tag Logging, Global Script, the OPC UA / OPC DA server, the redundancy partner, or a WinCC Client) is not draining it.

2. Decoding the Alarm Header

The WinCC alarm line follows the canonical CSV grammar State,Date,Time,MsgNr,MsgClass,MsgType,Computer,Application,Text. Decoded against the entry above:

The free-text portion carries the actual queue telemetry. Translating the three numbers to binary multiples shows the default thresholds shipped with V7.0 SP3:

The hysteresis is significant: once the queue trips the high water mark, additional overflow alarms are suppressed until the buffer drains below 819200 bytes. The next sample, 188 bytes past the high water mark, indicates a transient burst that lasted long enough to cross 1 MiB but short enough to recover without sustained loss.

3. DataManager Queue Architecture

The WinCC DataManager (DM) is the in-process broker that owns every configured tag. Its lifecycle in the runtime stack is:

1. The DataManager requests process image values from the channel DLLs (S7CHN, OPCCHN, MODBUSCHN, Allen-Bradley Channel DLLs, etc.).
2. Each channel returns the raw value with an associated quality code and timestamp.
3. The DataManager copies the value into its internal request queue and notifies every subscriber that has registered an interest in the tag (Graphics Runtime, Alarm Logging, Tag Logging, Global Script C/VB actions, the OPC server, redundancy partner, and remote WinCC Clients).
4. Each consumer thread fetches the value through its own subscriber handle. If a consumer is busy, slow, or stalled, the subscriber queue for that consumer fills first; if all consumers stall, the central DataManager queue fills last and the 1000200 alarm fires.

Because WinCC V7.0 SP3 is a 32-bit process, the DataManager shares the standard 2 GB user-mode virtual address space with Graphics Runtime, GfxRuntime, the script interpreter, and the project database. Memory fragmentation under load is therefore the silent partner of any 1000200 alarm.

4. Root Cause Taxonomy

After applying Update 2 for WinCC V7.0 SP3 to eliminate the known DataManager defects, the residual causes fall into five buckets. Use the table as a triage matrix.

5. Diagnostic Procedure

Run the following steps in order. The order is chosen so that the cheap, non-invasive checks run first.

5.1 Read the WinCC Diagnose folder

On the affected station, open %ProgramFiles%\Siemens\Automation\WinCC\Diagnose (or %ProgramFiles(x86)%\Siemens\Automation\WinCC\Diagnose on a 64-bit OS). The folder is populated by the runtime and contains the current state of every WinCC subsystem. The relevant files for this alarm are:

• WinCC_Sys_<computername>.log - global startup and shutdown trace.
• WinCC_Realtime_<computername>.log - hot trace of the runtime; entries are correlated by the same 1000200 message number.
• DM_<computername>.log - DataManager-specific trace (only generated when Computer > Properties > Diagnostics > Data Manager is enabled).
• ALG_<computername>.log, TLG_<computername>.log - Alarm and Tag Logging subsystem traces.

Grep for the message number 1000200 to find the matched consumer crash. The pattern is typically DM: queue overflow, consumer=<process name>, pending frames=<n> when DataManager diagnostics is enabled.

5.2 Enable the DataManager trace temporarily

Open WinCC Explorer > Computer > right-click > Properties > Graphics Runtime > Diagnostics > Data Manager and switch the level from Error to Error + Warning while reproducing the alarm. The trace will be written to DM_<computername>.log in the Diagnose folder. Reset the level back to Error after collecting 10-15 minutes of data - the verbose trace itself consumes the queue if left on permanently.

5.3 Correlate with the Windows event log

Open eventvwr.msc and inspect:

• Windows Logs > Application - look for Application Error entries from CCAlgRt.exe, CCArchiveManager.exe, CCMsg.exe, or GfxRuntime.exe that occurred within one minute of the 1000200 alarm.
• Windows Logs > System - look for disk or network adapter events that coincide with the alarm. A burst of disk timeout 153 events on the archive drive is a strong indicator of bucket B.
• Applications and Services Logs > Siemens Automation > WinCC - the WinCC event provider emits a structured event that mirrors the alarm line and is easier to filter by Event ID.

5.4 Live performance capture

Use Windows Performance Monitor (Perfmon) with a data collector set that includes the following counters sampled at 5 s for at least 30 minutes covering the next alarm:

\Process(CCAlgRt*)\% Processor Time
\Process(CCArchiveManager*)\% Processor Time
\Process(GfxRuntime*)\% Processor Time
\Process(CCExplorer*)\Working Set - Private
\Process(CCExplorer*)\Handle Count
\LogicalDisk(*)\% Idle Time
\LogicalDisk(*)\Avg. Disk Queue Length
\Memory\Available MBytes
\Network Interface(*)\Bytes Total/sec

Sustained Avg. Disk Queue Length > 2 on the archive volume, or Memory\Available MBytes < 200 on a WinCC Server with 4 GB RAM, is enough on its own to explain the queue overflow.

5.5 Sizing rule of thumb

Use the formula below to estimate the steady-state queue occupancy that the alarm is reporting on:

Q_in   = N_tags × f_update  (frames / second, summed across all tags)
Q_size ≈ Q_in × t_consumer (bytes, assuming 32 bytes per frame including header and timestamp)

If a project polls 4 000 tags at 500 ms, Q_in = 8000 frames/s. A consumer that takes 12 ms to drain a frame, multiplied by 32 bytes per frame, gives Q_size ≈ 3.07 MiB - well above the 1 MiB high water mark. The conclusion is independent of the alarm sample: the project is over-budget and the update rate must come down.

6. Resolution - Reducing the Inflow Rate

Work in the order: tag count, update time, then acquisition strategy. Each step delivers a measurable reduction in Q_in without changing the queue ceiling.

1. Audit the tag count. Open WinCC Explorer > Tag Management, right-click the root, choose Properties > Statistics, and export the count per channel. Tag counts above 12 000 process tags on a single-station V7.0 SP3 are a high risk factor; split large projects into a WinCC Server / WinCC Client topology before further tuning.
2. Stretch the update time. In Tag Management > Driver connection > Properties > Connection, set the Update Time to the largest value the process can tolerate (typically 1 s for trending, 2-5 s for status-only). Combine multiple slow tags into a single poll cycle by grouping them in the same channel; the SIMATIC S7 MPI/TCP driver lets you share a single job across many tags.
3. Use Acquire-on-Demand for faceplates. In the Graphics Designer, change the Update property of every I/O field, bar, and text field bound to a slowly-changing tag from Cyclic (default 250 ms) to On Demand. The value is then refreshed only when the picture opens, the operator presses a key, or a script forces a refresh. Typical 40-60 % reduction in Q_in on overview screens.
4. De-couple the alarm and trend flood. In the alarm and tag logging editors, set the Acquisition Cycle identical to or slower than the Archiving Cycle. Acquisitions that are faster than the archive cycle simply queue up in Tag Logging and compete for the same DataManager subscriber.
5. Disable unused channels and partitions. A Channel Diagnosis screenshot in WinCC Explorer > Tools shows the per-channel status. Channels that are present in the project but unused (typical after a retrofit) still spawn a polling thread that contributes to Q_in.

7. Resolution - WinCC Configuration Tuning

After trimming the inflow, raise the throughput of the consumer processes:

• Tag Logging RT. In Tag Logging > Process Tags > Properties > Tag, set Archiving / Acquisition ratio to 1:1 or 2:1. Move the archive database to a dedicated local SSD; never share the SQL Server volume with the pagefile or the Windows swap file. Add a maintenance plan that rebuilds the index of CC_TLG_<n>_<YYYYMMDD>.mdf weekly - fragmented indexes are a documented cause of slow archive flushes that cascade into the DataManager queue.
• Alarm Logging. Configure Message Configuration > Acknowledgement > Automatic for the noisy message classes so that Graphics Runtime is not busy redrawing acknowledgement dialogs. Lower Message Configuration > Display > Maximum Number of simultaneously visible rows in the alarm control to 500 - the default 1000 rows can stall the runtime on lower-spec panels.
• Graphics Runtime. Open the affected picture in the Graphics Designer, run Tools > Cross Reference, and locate any tag bound with a hidden, zero-size I/O field - the field still drives a poll. Reduce the picture count, prefer screen-in-screen navigation, and avoid dynamic SVGs that retesselate per cycle.
• Global Script. Search the project for C or VB actions scheduled On Time with periods below 1 s. A 100 ms action that touches 50 tags generates 500 frames / s of artificial load. Move periodic logic to a redundant PLC scan and let the WinCC side stay passive.
• OPC DA / OPC UA server. If a third-party OPC client is connecting to the WinCC OPC DA server, verify that the client's subscription Update Rate is at least 1 s. An aggressive client at 100 ms can saturate the queue just like a runaway screen.

8. Resolution - System-Level Optimization

These settings live on the Windows host and are easy to miss.

1. Antivirus exclusion. Add the following paths to the AV whitelist (or to Windows Defender > Settings > Exclusions > Add an exclusion):

   C:\Program Files (x86)\Siemens\Automation\WinCC\**
   C:\WinCCProject\<YourProjectName>\**
   %ProgramData%\Siemens\Automation\WinCC\**

   Real-time scanning of the .mdf archive files is the single most common outside cause of the alarm.
2. Power plan. On operator consoles, force High Performance in powercfg.cpl and disable USB selective suspend. A WinCC Server is not a laptop and must not be allowed to enter any low-power state.
3. Pagefile. Set a fixed pagefile of 4-8 GB on the same volume as the project. A dynamically shrinking pagefile is a known cause of the Graphics Runtime being stalled waiting for virtual memory, which in turn stalls the DataManager consumer.
4. Network adapter. On WinCC Servers, disable Energy-Efficient Ethernet, Large Send Offload v2 (LSO), and TCP/UDP Checksum Offload (IPv4 and IPv6) on the LAN adapter. The 32-bit WinCC V7.0 SP3 stack is not built to interact with all of these offload paths, and the retransmits they sometimes introduce look like a slow consumer to the DataManager.
5. Time synchronization. Disable the Windows Time service's special poll interval on the WinCC Server. The DataManager stamps every frame with the system time, and a 50 ms time jump will momentarily freeze consumer threads while WinCC rebuilds the index. Prefer a single NTP source feeding the whole plant.
6. SQL Server. If the project uses the WinCC option Connectivity Pack or IndustrialDataBridge, move the SQL Server instance to a dedicated machine. The CC_OLEDBProvider runs inside the WinCC process and is sensitive to SQL lock waits; a slow SELECT on the same SQL instance that hosts the archive database is enough to trip the alarm.

9. Applying WinCC V7.0 SP3 Update 2

Update 2 is the cumulative hotfix rollup that supersedes Update 1 and contains the patches Siemens shipped to address the early V7.0 SP3 DataManager defects, including the 1000200 alarm frequency. Download the package from the official entry at Siemens Industry Online Support - Update 2 for WinCC V7.0 SP3 / V7.0 SP3 ASIA (ID 60984587). The file is several hundred megabytes; download it to a local folder, not to a network share, to avoid partial extraction.

Install procedure:

1. Run the executable as a domain user that is a member of the local SIMATIC HMI group.
2. Accept the license terms and the readme - the readme lists any prerequisites that have changed since Update 1.
3. Allow the installer to restart the CCMsg and SQL Server (WINCC) services.
4. After the install, re-apply the project license via WinCC License Analysis; Update 2 does not reissue a license but does reset the activation flag if the host name changed.

10. Verification

After every change, reproduce the alarm scenario and confirm that the 1000200 message no longer appears for at least 24 hours of normal operation.

1. Live trace. With the DataManager trace at Error + Warning, open the offending screen, drive the operator workload that previously caused the spike, and confirm that the Diagnose folder shows no queue overflow lines.
2. Alarm log. Run Control Panel > Administrative Tools > Event Viewer > Siemens Automation > WinCC, filter on Event ID 1000200, and confirm the count is zero in the last 24 h.
3. Resource counters. Capture 30 minutes of Perfmon data and verify LogicalDisk(\*)\% Idle Time stays above 20 % and Memory\Available MBytes stays above 25 % of installed RAM.
4. Application behavior. Confirm trend curves in the Tag Logging control do not contain horizontal flat stretches (the visual artifact of a missing sample), and that alarm counts match the operator's observation.
5. Update 2 footprint. In WinCC Explorer > Help > About, the splash screen must read WinCC V7.0 SP3 + Upd. 2. A non-Upd. 2 build indicates the install did not complete.

11. Cross-References and Standards

The 1000200 alarm is not a documented SIL-classified error; it is a diagnostic message. The recommendations in this article are aligned with the WinCC V7.0 SP3 system manual and the V7 Diagnostics Guide:

• WinCC V7.0 SP3 system manual, section "Diagnostics - Messages of the WinCC System" - contains the full list of 10002xx message numbers and their consumer mapping.
• WinCC V7.0 SP3 Communication Manual, section "DataManager - Update and Request Concept" - the architectural description used in section 3 above.
• Siemens Industry Online Support entry 60984587 - Update 2 for WinCC V7.0 SP3 / V7.0 SP3 ASIA - the canonical download for the patch referenced in section 9.

12. Field-Proven Quick Checklist

For engineers on a tight schedule, run this 10-minute checklist before opening a support ticket:

1. Apply Update 2 for WinCC V7.0 SP3 if the build is still RTM.
2. Set the tag acquisition / archiving cycle ratio to 1:1 or slower in Tag Logging RT.
3. Switch I/O fields bound to slowly-changing tags from Cyclic 250 ms to On Demand.
4. Move the archive database to a local SSD and whitelist the WinCC paths in the AV product.
5. Confirm Memory\Available MBytes > 200 and archive disk % Idle Time > 20 % in Perfmon.
6. Open ..\Siemens\WinCC\Diagnose, grep for 1000200 and the consumer name, and act on the consumer that is referenced most often.

If the alarm still appears after all six steps, the next escalation is to move the project to WinCC V7.4 or later, where the DataManager exposes both the high water mark and the low water mark as registry values and the buffer ceiling can be raised without modifying the application.