SIMATIC PCS 7 V7.1 WinCC Archive Not Writing Alarms and Trends

David Krause17 min read
SCADA ConfigurationSiemensTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Problem Overview

On a SIMATIC PCS 7 V7.1 redundant server pair running under Windows Server 2003 with Cemat V7.1, one of the two redundant OS Servers stops writing both message (alarm) archives and process value (trend) archives. The partner server continues to archive normally, but with a reduced segment retention window. The Engineering Station runs Windows XP and four OS Clients connect to the server pair. Archiving had worked correctly before an OS-level operation was performed on the failing server: the system partition (C:) was restored from a disk image of a healthy reference server. After the partition restore, both Tag Logging and Alarm Logging stopped writing to disk on that single server.

WinCC Explorer, WinCC Archive Configuration editor, and the Tag-/Alarm-Logging runtime databases all appear correctly configured. The archive configuration tabs, segment size, and storage paths match the partner server exactly. The WinCC-Archive folder on the failing server remains empty, while the partner server continues to fill its archive segments. The fault is silent: no WinCC error dialog is raised and the OS Server runtime reports green status.

Affected System Architecture

Component Specification
Process Control System SIMATIC PCS 7 V7.1 (Cemat V7.1 library set)
OS Server pair 2 × WinCC OS Server, redundant (Master/Standby switchover)
OS Server OS Windows Server 2003 (32-bit)
Engineering Station Windows XP SP3, SIMATIC PCS 7 ES V7.1
OS Clients 4 × WinCC OS Client
Archive component WinCC Tag Logging + Alarm Logging (SQL-based)
Archive storage Local path C:\[Project]\WinCC-Archive (or configured archive directory)

The redundant pair is a standard PCS 7 V7.1 OS Server redundancy: both servers hold identical project copies; the Master archives process values and messages while the Standby is hot. On switchover, the previous Standby takes over the runtime role and its own local archive path is used. For this reason, both servers must be independently write-capable to the local archive directory.

Symptoms and Observations

  • OS Server 1 stops writing new entries to both message and process-value archives.
  • The WinCC-Archive folder on Server 1 remains empty (no new *.LDF/*.MDF segments, no *.RTL swap files, no *.CSV exports).
  • OS Server 2 continues to write, but is configured to a 07-day window only.
  • WinCC runtime on Server 1 shows no alarm in the diagnostic file (initially); the OS Server remains in Run state.
  • Archive Configuration editor in WinCC Explorer shows the same tag/segment parameters as Server 2.
  • The Engineering Station can browse Server 1's archive online, but no new time slices are appended.

Root Cause: Windows Folder Read-Only and Hidden Attributes

The trigger event was an OS-level operation: the user copied the disk image of partition C: from a healthy reference server onto the production server. The image restore was performed as a sector copy, not a file-level restore. After the restore, the user noticed that the WinCC OS Server could no longer write to its archive directory.

The direct root cause is the Windows NTFS view of the WinCC-Archive folder. When a folder is created, copied, or imaged under a different user context, Windows can apply two attribute bits that block silent file modification:

  1. Read-only (FILE_ATTRIBUTE_READONLY) – propagated by some imaging tools as a "frozen" marker; applies to all files within the folder and prevents modification.
  2. Hidden (FILE_ATTRIBUTE_HIDDEN) – prevents the WinCC runtime backup/archiving service from enumerating the folder for write access in some default security contexts.

In Windows Explorer, the read-only bit on a folder is shown in the folder Properties > General tab. Because the bit is shown as a partially-checked checkbox (square rather than a tick), users routinely believe the folder is not read-only. The square is exactly the bit that blocks Tag Logging and Alarm Logging from creating new segment files. This is the "two boxes of modification and total controls" referenced in the resolution: the Read-only and Hidden checkboxes in the folder's Properties dialog.

Why does this affect only one server of a redundant pair? Each OS Server in a PCS 7 V7.1 redundancy writes to its own local archive path. The image-restore operation modified only the OS image of Server 1, leaving Server 2's attributes untouched. The redundancy mechanism synchronises process values and messages in memory, not the on-disk archive directory of the partner, so the failure remained isolated to Server 1.

Important. The folder-level read-only bit in NTFS is a marker, not an enforced ACL. WinCC runtime, however, calls the Windows API to create, open, and write segment files. The API path honours the bit and returns ERROR_ACCESS_DENIED on file creation, which WinCC logs as a non-fatal warning. Runtime continues, but no segment is written.

Why the Server Pair Looks Correct but Server 1 Is Silent

PCS 7 V7.1 OS Server redundancy is a project-level redundancy. Both servers receive the same configuration from the Engineering Station, both have the same archive path string, and both register the same archive segments in the project database. The redundancy does not, however, replicate the Windows file system of the partner. Each server is responsible for:

  • Opening the configured archive directory at runtime start.
  • Creating a new segment file when the configured time or size threshold is reached.
  • Switching the active segment and closing the previous one.
  • Deleting the oldest segment when the configured retention count is reached.

Any failure in step 1, 2, or 3 manifests as a silent stop. WinCC Tag Logging uses an internal database writer that retries on access errors but does not page the operator. Alarm Logging uses the same code path for AlarmDLG history persistence. The WinCC Diagnose file (C:\Program Files\Siemens\WinCC\Bin\Diagnose\WinCC_Sys_.log) contains the ERROR_ACCESS_DENIED entries for failed segment creation, but only at debug verbosity by default.

Diagnostic Procedure

Before applying the fix, capture the following information from the failing server so the fix can be verified and the failure mode recorded.

  1. Capture the archive configuration. In WinCC Explorer on the Engineering Station, right-click Tag Logging and Alarm Logging, select Configuration, and export screenshots of every tab (Archive Configuration, Segment settings, Storage location). Repeat for both servers; diff with WinMerge or fc.exe.
  2. Capture the WinCC Diagnose file. On the failing server, open C:\Program Files\Siemens\WinCC\Bin\Diagnose\ and copy the latest *.log. Search for the strings ERROR, archive, access denied, segment, and 0x5 (hex code for ERROR_ACCESS_DENIED).
  3. Capture the installed software list. Export the Installed Software control panel (or run msinfo32 /report C:\installreport.nfo on Windows Server 2003) and archive. The relevant packages are SIMATIC PCS 7 V7.1 + SPx, WinCC V7.1, Cemat V7.1, and SQL Server 2005.
  4. Capture the folder attributes. Open a cmd.exe on the failing server and run attrib "C:\<project>\WinCC-Archive". Note the letters shown: H = Hidden, R = Read-only, A = Archive, S = System. A HR prefix on the directory line confirms the failure mode.
  5. Capture the NTFS ACL. Run cacls "C:\<project>\WinCC-Archive" /T and verify that the SIMATIC HMI user group has Full Control and that the SYSTEM and local Administrators have inherited rights.

If attrib shows H R C:\<project>\WinCC-Archive, the root cause is confirmed. The remaining steps (Read-only and Hidden checkboxes in the folder's Properties > General dialog) are the GUI equivalent of the same bits.

Step-by-Step Resolution

Perform the following procedure on the affected OS Server. The partner server is not affected; do not touch its configuration.

  1. Stop the WinCC runtime. Open WinCC Explorer and select File > Stop Runtime. Alternatively, stop the SIMATIC WinCC Explorer and CCAlgRt services from services.msc. Wait for all CCArchiveManager and CCArchiveConn processes to exit.
  2. Open the folder properties. In Windows Explorer, navigate to the archive directory (for example C:\<ProjectName>\WinCC-Archive). Right-click and select Properties.
  3. Clear the Read-only checkbox. In the General tab, the Read-only attribute appears as a square (partially checked), not a tick. Uncheck the box and click Apply. If prompted with "You have chosen to make changes to the attribute settings", select "Apply changes to this folder, subfolders and files" and click OK.
  4. Clear the Hidden checkbox. In the same General tab, uncheck the Hidden attribute and click Apply. Confirm "Apply changes to this folder, subfolders and files".
  5. Verify from the command line. Open cmd.exe as Administrator and run attrib -R -H "C:\<project>\WinCC-Archive" /S /D. This clears Read-only and Hidden on the folder, all subfolders, and all files recursively. The /D switch is required so the command also processes directories.
  6. Verify the NTFS ACL. Run cacls "C:\<project>\WinCC-Archive" /T > C:\acl_before.txt and compare to the partner server. Re-apply inheritance from the Security tab (Advanced > Change Permissions > Enable inheritance) if any entry is missing. The SIMATIC HMI group must have Modify, the SYSTEM account must have Full Control.
  7. Confirm segment storage path. In WinCC Explorer, right-click Tag Logging and choose Archive Configuration. On the Storage location tab, confirm the path matches the cleared directory exactly. If the configured path does not exist on disk, recreate it before starting the runtime.
  8. Start the WinCC runtime. In WinCC Explorer, select File > Start Runtime. The OS Server transitions to Run. Watch the archive directory: a new segment file (typically <archive>_<segment>.LDF for Tag Logging and <archive>_<segment>.MDF for Alarm Logging) is created within the configured segment period (default 1 day for daily segments).
Caution. Do not perform steps 3 and 4 on a folder whose contents are still in use by a running WinCC instance. The OS locks the active segment file, and clearing the read-only bit on a locked file is blocked. Always stop the runtime first.

Verification

Confirm the fix is effective by checking all of the following:

  1. Directory timestamp updates. Open the archive folder in Windows Explorer; the Date Modified column must show a recent timestamp after one segment period. A folder whose Date Modified remains at the original creation time is still blocked.
  2. New segment file appears. After one segment period (default 24 hours for daily, 1 hour for hourly), a new file appears in the archive directory. The file size starts at the configured initial size and grows up to the configured maximum segment size.
  3. WinCC Diagnose is clean. Open the latest WinCC_Sys_*.log and confirm there are no new ERROR_ACCESS_DENIED, 0x5, or "cannot create segment" lines after the runtime restart.
  4. OS Client archive view updates. Open the WinCC Online Trend Control and Alarm Control on a client. The current time cursor must move and new values/messages must appear after the segment period elapses.
  5. Segment switchover works. Force a segment switch (right-click Tag Logging > Archive > Switch Segment in the Tag Logging toolbar). A new file is created and the previous file is closed and listed in the Segments tab of the Online Trend Control.
  6. Redundancy switchover is clean. On the OS Server pair, perform a manual redundancy switchover (right-click the server in WinCC Explorer and choose Master -> Standby). The new Master continues to write into its own archive directory. If the directory attributes of the other server are still in the failed state, the redundancy will not heal it; that server must be fixed independently.

Segment Sizing and Retention Best Practices

The reference installation used a 6-month segment for a full archive window, which is too aggressive for a Windows Server 2003 OS Server with limited RAM and disk. PCS 7 V7.1 WinCC Tag Logging and Alarm Logging store segments as SQL Server database files; the active segment is memory-mapped and the closed segment is on disk. Long segment periods combined with many tags cause the writer to keep large memory buffers and a slow start-up, which in turn hides the silent failure described in this article (the OS Server appears to start, but never creates a new segment because the active segment is in the wrong state).

Parameter Recommended value (PCS 7 V7.1) Effect
Segment period (Tag Logging) 1 day to 1 month Smaller segment = faster switch, faster disk I/O, lower memory
Segment period (Alarm Logging) 1 day Alarm history is read frequently; keep segments small
Number of segments in primary path 1 to 3 months (30 to 90 segments) Longer archive lives are handled by Storage Plus / Process Historian
Tag count per archive ≤ 1 000 (compressed) or ≤ 500 (uncompressed) Limits the size of any single segment
Compressed storage Yes for trend archives > 1 week Reduces disk footprint by 5× to 10×
Storage path Local SSD or dedicated RAID 1 volume Network drives are unsupported for the active segment

For long-term retention, use the SIMATIC PCS 7 Storage Plus option (PCS 7 V7.1 supports the central archive server on a separate machine) or migrate to Process Historian / Information Server as available in later PCS 7 releases. The on-disk WinCC archive path is the runtime hot path and must remain compact.

Related Archive Errors and Their Meanings

Error string in WinCC Diagnose Typical cause Resolution
ERROR_ACCESS_DENIED (0x5) on segment create Folder Read-only / Hidden attribute set Clear attributes per the procedure above
ERROR_DISK_FULL (0x70) on segment write Volume full; segment switch fails Increase volume size, shorten retention, move older segments to Process Historian
ERROR_SHARING_VIOLATION (0x20) Another process has the segment file open (anti-virus, backup) Exclude the archive directory from real-time AV; reschedule backups
SQL Server does not exist or access denied SQL Server 2005 service not running on the OS Server Start MSSQL$WINCC; check CCArchiveConn logon
Archive segment older than configured max time WinCC clock skew > 60 s between AS and OS Synchronise time via SIMATIC Time-of-Day synchronisation or NTP
Cannot open archive configuration database CCArchiveManager cannot read project database Reinstall project from ES; check that SIMATIC HMI has read access to <project>\WSOL

Preventive Measures

  • Image the OS, not the project path. When restoring a server, restore the system partition and the project partition separately. The project partition can be wiped and reloaded from the Engineering Station via OS Project Editor > Download.
  • Standardise attribute policy. Add a startup script on every OS Server that runs attrib -R -H "C:\<project>\WinCC-Archive" /S /D before the CCArchiveManager service starts. This protects against accidental imaging operations.
  • Exclude from anti-virus. Configure real-time AV to exclude the project directory, the SQL data directory, and the Windows pagefile. The PCS 7 V7.1 manual explicitly lists the recommended exclusions.
  • Monitor the archive directory. Use a simple scheduled task that calls dir /S "C:\<project>\WinCC-Archive" | find "File(s)" and writes the count to a tag. Alarm when the count is zero for more than one segment period.
  • Document the disk image procedure. If you must image a PCS 7 OS Server, perform the image on a powered-off server, then run sysprep (where supported) or change the SID before joining the redundant pair. The PCS 7 V7.1 readme explicitly warns against cloning live OS Servers into a redundancy without SID change.
  • Match the two servers' parameters. After any change, run the OS Project Editor on the Engineering Station with Check Consistency enabled to detect any configuration drift between the redundant pair.

Redundancy Configuration Notes

PCS 7 V7.1 OS Server redundancy uses the Redundancy control in WinCC Explorer. Each server is configured with the partner's name; the master/standby state is exchanged over the redundancy network. The runtime archive is always local to the active server. The following are the relevant attributes on the redundancy configuration page:

Attribute Value / meaning
Server type OS Server (master-capable)
Redundancy partner Name of the partner OS Server (must resolve via WINS or DNS)
Preferred master Identifies which server becomes Master on simultaneous start
Synchronisation mode Project must be identical; the redundancy cannot heal a mis-configured archive directory
Switchover behaviour On Master failure, Standby promotes and starts writing to its own archive directory

The redundancy network must be a dedicated subnet, ideally gigabit, with low jitter. Time-of-day synchronisation must be enabled on both servers; skew above 60 s is a documented cause of segment errors that can mask the read-only attribute issue.

Migration Path to PCS 7 V8 or Later

Windows Server 2003 and PCS 7 V7.1 are out of mainstream support. If the system must continue to run, plan a migration to a current PCS 7 release. The migration affects the archive subsystem as follows:

  • PCS 7 V8.0 and later use Process Historian as the long-term store; WinCC archive directory becomes a short-term cache.
  • The folder-attribute behaviour described in this article is unchanged on Windows Server 2008 R2 / 2012 R2; the same attrib and Properties procedure applies.
  • SQL Server is upgraded from 2005 to 2008 R2 or 2012; the segment file extension stays .LDF / .MDF.
  • SIMATIC Time-of-Day synchronisation is replaced by NTP with a domain controller.

For sites that cannot migrate, the on-disk archive directory fix described above remains valid and is the supported workaround for the attribute-induced silent failure.

When to Restore the OS Image Instead of Fixing Attributes

If the directory ACL is corrupted beyond repair, if the read-only bit is set by a system policy that re-applies on reboot, or if other components are broken (e.g. the SQL Server 2005 instance will not start, the WinCC project database is missing tables), the supported recovery path is:

  1. Take a disk image of the current (broken) server for forensic analysis.
  2. Restore the original disk image of the partition C: from a known-good backup. The slow start-up observed in the reference case is a separate issue: the OS image contains large drivers and an oversized registry hive that slow boot. The fix is to update the storage controller driver and to remove unused device drivers, not to re-image repeatedly.
  3. Re-install the SIMATIC PCS 7 V7.1 OS Server software on top of the image (no full re-install required if the image already contains PCS 7).
  4. Download the OS project from the Engineering Station: in WinCC Explorer, select File > Download Server and confirm redundancy parameters.
  5. Clear the archive directory attributes per the procedure in this article and start the runtime.

This path is more time-consuming (the reference case reported 2 hours of start-up time on the original image) but produces a clean, audit-able state. The choice between the two paths depends on whether the operator needs the system back online in minutes (attribute fix) or in hours (image restore) and on whether the underlying disk image is known to be clean.

Field Checklist

  1. Stop WinCC runtime on the failing server.
  2. Open Properties on the WinCC-Archive folder.
  3. Uncheck Read-only; apply to folder, subfolders, files.
  4. Uncheck Hidden; apply to folder, subfolders, files.
  5. Verify with attrib "C:\<project>\WinCC-Archive" – no R or H.
  6. Verify NTFS ACL: SIMATIC HMI = Modify, SYSTEM = Full Control.
  7. Confirm the configured archive path in WinCC Explorer matches the cleared directory.
  8. Start WinCC runtime; watch for a new segment file within one period.
  9. Re-check the OS Client Trend and Alarm controls for new data.
  10. Inspect the WinCC Diagnose log for any new 0x5 entries.
  11. Repeat steps 1–10 on the partner server only if the same imaging operation touched it.

Why does the OS Server runtime show "Run" while no archive is being written?

WinCC Tag Logging and Alarm Logging report runtime status at the OS Server process level, not at the storage level. A failed segment creation is logged as a non-fatal warning in the WinCC Diagnose file and the runtime continues in green state. The archive simply does not grow. The only reliable detection is to check the archive directory's Date Modified timestamp or to monitor the segment count via a tag.

Why does clearing the Read-only checkbox show a square and not a tick?

Windows Explorer shows a square (partially checked) when the Read-only attribute is set on the folder but not on every file inside it. The square is the same as a tick in effect: it indicates that the folder itself is marked read-only and that the bit must be cleared. Clicking the square once removes the bit, but Windows then prompts you to apply the change to the folder only, or to the folder plus contents. Always select "Apply changes to this folder, subfolders and files".

Can the PCS 7 V7.1 OS Server redundancy heal this fault automatically?

No. Redundancy synchronises the WinCC process data and alarm buffers in memory and keeps the project configuration in step, but it does not modify the Windows file system of the partner. Each server is responsible for its own local archive directory. If both servers were imaged from the same source, both will fail in the same way and must be fixed independently.

Will this fix survive a Windows restart?

Yes, once the attributes are cleared and the NTFS ACL is correct, the changes persist across reboots. The only ways the bit can return are: another image restore, a Group Policy that re-applies the read-only flag, or a backup product that marks files read-only before backup. Exclude the archive directory from any policy that re-applies read-only.

Is this issue present in PCS 7 V8, V9, or later?

The folder-attribute mechanism is a Windows NTFS behaviour, not a WinCC behaviour, and is present in every PCS 7 release that runs on a Windows server. The same attrib -R -H and Properties procedure applies. The PCS 7 V7.1 reference is used here because the original fault was reported on that release; the diagnosis and fix are valid on V8, V9, and current releases with the same imaging-restore pattern.

Back to blog