Resolving WinCC V6 SP3 User Archive C0000005 Access Violation

A Siemens WinCC V6 SP3 runtime in production is logging C0000005 ACCESS_VIOLATION faults from the script engine, ExecuteError events in configured actions, and a parallel Failed to switch archive (Type:1) message from ArchiveManager that targets the long-term tag archive file PETRON_SERVER_PETRON#HMI#22_ALG_200707221601. The visible result is a User Archive editor window that shows zero rows even though the database file is present on disk and the configured validation logic depends on that table to make plant objects visible. The combination of these three symptom classes points to a corrupted or detached User Archive database, almost always caused by a crash of the script engine that has left the WinCC ODBC connection pool in an invalid state and corrupted the in-memory OLE-DB cursor that feeds the User Archive table view. The remedy is a structured recovery that combines a script fault review under APDIAG, a manual reset of the archive swap, and a forced re-link of the User Archive data source to its underlying Microsoft SQL Server database.

Problem Summary

Before opening any tool, classify the symptoms. The reported project (computer name PETRON_SERVER, server prefix PETRON, HMI tag prefix HMI) presents four distinct, correlated symptoms. They are listed in the order in which they should be cleared; failure to clear the lower layers first causes the higher layers to fail again on the next runtime start.

Interpreting the C0000005 ACCESS_VIOLATION

The Windows NT status code 0xC0000005 (decimal -1073741819) is the standard STATUS_ACCESS_VIOLATION raised by the memory manager when a thread attempts to read from, write to, or execute an address for which the process has no valid page-table entry. The log fragment taken from the WinCC diagnose folder is:

// WinCC reported exception with code: C0000005 ACCESS_VIOLATION
// Date: 19.07.2007 - Time: 05:31:48
// Caused at logical address 00429ADA 01:00028ADA

Decoding the addresses:

• 00429ADA is the absolute virtual address inside the WinCC process. The leading 00400000 range is the typical load address for the script runtime DLL shipped with WinCC V6 SP3, which means the faulting instruction is inside script.dll or pdlrtapi.dll, not inside a third-party OCX.
• 01:00028ADA is the module/offset pair. 01 is the module ordinal of the executable image that contained the faulting instruction, and 00028ADA is the byte offset into that module's code section. In practice the second number is the address you hand to WinCC support when opening a ticket.

Causes that match this exact pattern in WinCC V6 SP3, in descending order of frequency:

1. A C action dereferences a pointer obtained from a GetTag* call after the tag has been deleted from the data manager or has not yet been created. The dispatcher's ExecuteError is raised, the pointer is freed, and a later access into the same address by the cleanup code raises the access violation.
2. A VBS action evaluates a non-array variable as an array, e.g. UBound(EmptyValue) or Split(NULL), which causes the VBScript engine to fault inside the VBScript5.dll address range.
3. A User Archive script calls uaQueryOpen / uaQueryClose in the wrong order, leaking handles until the OLE-DB cursor pool is exhausted and a subsequent call returns an invalid pointer.
4. SQL Server connectivity is broken. The User Archive connection string points to a server that has been moved, renamed, or whose service account has been changed. WinCC V6 SP3 falls back to a stub client that returns zero rows and surfaces ACCESS_VIOLATION the first time the script touches the cursor.
5. A hot-fix or service pack was applied on top of SP3 without re-installing the matching WinCC_SQL_Server.mdf schema migration. The UA table exists but the expected columns are missing.

Interpreting the ArchiveManager "Failed to switch archive (Type:1)"

The ArchiveManager message

255,22.07.2007,23:55:01:984,0,4,,PETRON_SERVER,ArchiveManager,Failed to switch archive(Type:1):PETRON_SERVER_PETRON#HMI#22_ALG_200707221601 !

breaks down as follows:

WinCC archives are numbered by type:

The failure almost always means the underlying SQL Server database is detached, full, or its transaction log is exhausted. WinCC's archive swap operation is a single transaction inside SQL Server: if the transaction cannot commit, the long-term file is not created, the active segment is not closed, and the dispatcher records DM_ERROR_FILE_CREATE (4). The next swap attempt runs into the same condition and the in-memory segment overflows within hours, which is why the User Archive list goes empty: the data source cursor is no longer valid.

Diagnostic Procedure with APDIAG

APDIAG (WinCC Advanced Diagnostics) is the OEM tool that turns on continuous script tracing and crash dump generation. It is installed automatically on every WinCC V6 SP3 server but the service is disabled by default. Enable it from the Windows service control panel:

1. Open services.msc and locate CCAlgChnService, CCArchiveManager, and CCUAChnService. Set each to Automatic and start them.
2. Start WinCC Explorer and open Tools > APDIAG. If the menu entry is missing, run APDIAG.EXE from %ProgramFiles%\Siemens\WinCC\bin.
3. Switch to the Traces tab and enable the ScriptEngine, ArchiveManager, and UserArchive channels. Set the trace level to Maximum and the file size to 50 MB per channel.
4. Reprocess the failing action. APDIAG writes a binary dump of the script process to ...\WinCC\diagnose\APDIAG every time the dispatcher logs an ExecuteError. The dump file has the same module/offset pair as the ACCESS_VIOLATION log entry, so the two can be correlated by timestamp.

Logfile Location and Analysis

All WinCC V6 SP3 log files are stored in the project diagnose folder. The default path is:

C:\Program Files\Siemens\WinCC\WinCCProjects\<ProjectName>\diagnose\
C:\Program Files\Siemens\WinCC\diagnose\
C:\Program Files\Siemens\WinCC\bin\..\..\diagnose\

The files relevant to this failure are:

When analysing the logs for the symptom set above, use the following filter sequence in WinCC Diagnosis:

1. Filter on C0000005. Every entry is an unhandled exception; record the address and the timestamp.
2. Filter on ExecuteError. Every entry is an action that was disabled by the dispatcher; record the action index.
3. Filter on Failed to switch archive. Every entry corresponds to a long-term file that was not created; record the file mask and the SQL Server error number (last field of the line).
4. Filter on uaQuery / uaArchive. This isolates the User Archive activity and confirms whether the OLE-DB cursor was open at the moment the script crashed.

SQL Server and User Archive Database Verification

WinCC V6 SP3 stores its runtime data in a Microsoft SQL Server 2000 instance named WinCC. The instance is created during installation and hosts three databases that are critical to User Archive operation:

Verify each database from the command line of the server:

1. Open a command prompt and run osql -E -S PETRON_SERVER\WinCC to connect with the trusted administrator context.
2. At the 1> prompt, run SELECT name, state_desc, recovery_model_desc FROM sys.databases WHERE name LIKE 'CC%';. The state_desc column must read ONLINE for every database. A state of RECOVERING, RESTORING, or SUSPECT indicates the cause of the failed archive swap.
3. Run DBCC CHECKDB('CC_UA_<Timestamp>') WITH NO_INFOMSGS; on the User Archive database. A consistency error result confirms that the UA table is corrupt and the empty User Archive editor is a direct consequence.
4. Run EXEC sp_spaceused; on the tag-archive database. If data is within 5 percent of database_size and unallocated space is zero, the transaction log has filled the file. The next archive swap will raise DM_ERROR_FILE_CREATE.
5. Exit with quit and review the SQLAGENT.OUT and ERRORLOG files in C:\MSSQL7\LOG for any failure messages that pre-date the WinCC diagnose entries.

User Archive Re-link Procedure

If DBCC CHECKDB reports consistency errors on the User Archive database, the data source must be re-linked. The procedure does not require a project rebuild and preserves the table contents.

1. Stop the WinCC runtime: net stop "CCArchiveManager", net stop "CCUAChnService", net stop "CCAlgChnService".
2. Back up the User Archive database: BACKUP DATABASE [CC_UA_070322_165831] TO DISK = N'D:\Backup\CC_UA_pre_repair.bak' WITH INIT;
3. Run the in-place repair: DBCC CHECKDB('CC_UA_070322_165831', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
4. Re-index the User Archive table: DBCC DBREINDEX('UA', '', 90);
5. Update the WinCC statistics: UPDATE STATISTICS UA WITH FULLSCAN;
6. Start the services in reverse order: net start "CCAlgChnService", net start "CCUAChnService", net start "CCArchiveManager".
7. Re-start the WinCC runtime and open the User Archive editor. The list should now display the expected rows.

Script Engine Repair

The script-engine ACCESS_VIOLATION is a downstream effect. After the User Archive database is repaired, the offending action must be hardened so that the same fault is not raised on the next trigger.

Common patterns and the corresponding fixes for WinCC V6 SP3 C and VBS actions:

For the failing action index 3, the typical configuration is a periodic action triggered every 5 seconds that polls the User Archive for validation rows. Re-implement it as a self-guarded action that only reads when the archive connection reports DB_OK:

' Action 3 - guarded User Archive poll
Dim hArchive, bOk, lCount
bOk = uaQueryOpen(1, hArchive)
If Not bOk Then
    ' connection failed; disable action to stop the dispatch loop
    SetOperationMode 0
    Exit Sub
End If
lCount = uaQueryGetFieldValueCount(hArchive)
If lCount > 0 Then
    ' bind to the picture and set visibility
    SetVisible "HMI/Object_42", True
End If
uaQueryClose hArchive

Archive Configuration Reset

The Failed to switch archive message leaves the active segment of the tag archive in a half-closed state. Closing it manually restores the swap mechanism without losing data.

1. Open WinCC Explorer > Tag Logging and select the archive that owns HMI#22.
2. Right-click the archive and choose Properties > Archive Configuration. Verify the segment size (default 1 day) and the swap action (default Automatic).
3. Switch the swap action to Manual and click Apply. WinCC closes the current segment and opens a new one.
4. Switch the swap action back to Automatic and click OK.
5. Inspect the ArchiveManager tab in WinCC Diagnosis. The Failed to switch archive line should be replaced by a Switched archive entry with the new timestamp.

Step-by-Step Resolution Procedure

The full recovery sequence combines the four procedures above into a single controlled change window.

1. Capture state. Export the WinCC project, the diagnose logs, and the CC_PT2K and CC_UA databases. Keep the export in D:\Backup\pre_repair_<date>\.
2. Stop the runtime. Stop all WinCC services and the runtime. The dispatcher will not log ExecuteError while the runtime is down, so the APDIAG log will be clean from this point forward.
3. Run APDIAG. Enable the ScriptEngine, ArchiveManager, and UserArchive trace channels. Set the buffer to 50 MB and start the runtime in Diagnosis mode.
4. Verify SQL Server. Run the four osql queries from SQL Server and User Archive Database Verification. Record the state_desc of each database and the result of DBCC CHECKDB on CC_UA.
5. Repair the User Archive database. Run the re-link procedure from User Archive Re-link Procedure. Use REPAIR_ALLOW_DATA_LOSS only after the database backup is verified.
6. Close the half-open tag archive segment. Follow the Archive Configuration Reset steps to trigger a manual swap and verify the new Switched archive entry in the diagnose log.
7. Harden the offending action. Replace Action 3 with the guarded pattern from Script Engine Repair. Re-compile the project and check the Script.log for clean compile.
8. Restart the runtime. Bring the services back up in the reverse order. Open the User Archive editor and confirm the row count matches the expected value.
9. Run a soak test. Leave APDIAG running for 24 hours and check that the C0000005 counter is zero, the ExecuteError counter is zero, and the Failed to switch archive counter is zero.
10. Remove APDIAG. Once the soak test is clean, switch the trace channels back to Off and stop the APDIAG service.

Verification Tests

After the resolution procedure, run the following checks to confirm the system is healthy. A test that fails indicates a residual problem and must be cleared before the runtime is returned to production.

Prevention and Hardening

The conditions that produce the symptom set above are all preventable. The following controls should be in place on every WinCC V6 SP3 server before commissioning.

1. Pin the SQL Server recovery model. Use the Simple model for the CC_PT2K and CC_UA databases unless point-in-time restore is a contractual requirement. Simple model truncates the transaction log on every checkpoint, removing the most common cause of DM_ERROR_FILE_CREATE.
2. Cap tag-archive retention. Limit each tag archive to 30 days online. Long-term storage is the job of the _ALG files, which can be exported to NAS for offline browsing.
3. Guard every User Archive read. Wrap uaQueryOpen in a quality check. If the connection returns FALSE, the script must Exit Sub rather than touch the cursor.
4. Compile actions with Strict On. VBS actions compiled with Option Explicit and Strict mode do not silently allow the empty-Variant-to-array cast that triggers the VBScript5 fault.
5. Schedule a daily SQL Server consistency check. A SQL Server Agent job that runs DBCC CHECKDB('CC_UA_<TS>') at 02:00 and writes the result to the Windows Application event log surfaces corruption before the next archive swap.
6. Run APDIAG for one week after every change. A change to the project, the database, the SQL Server, or the OS must be followed by seven days of ScriptEngine and ArchiveManager traces. The trace logs are the only artefact that correlates a script-engine crash with the archive swap that followed it.
7. Lock the WinCC project. In WinCC Explorer > Project > Properties > Options, enable Disable project changes on the server. This prevents a stray editor from renaming a tag while the runtime is in operation.

Component Cross-Reference

The following table maps each symptom in this article to the WinCC V6 SP3 component that owns the file or registry key involved in the fix. The version numbers correspond to the build that was current on the date of the reported failure (SP3, build 070322, released 22 March 2007).

Frequently Asked Questions