Resolving WinCC Error 1012301: SQL Server Access Failure on MSARCLONG Inserts

WinCC runtime error 1012301 is a database-layer fault that appears when the Alarm Logging subsystem cannot commit a row to the Microsoft SQL Server backend that hosts the WinCC archive databases. The accompanying message text "CA: <servername> No access to SQL server (loss of data possible)" indicates that data integrity is at risk, and a new message is generated roughly every second while the condition persists. The companion alarm 1012302 ("WinCC Process Archiving has stopped for TagId=<n>") typically follows within seconds, halting process-value archiving on the affected archive segment.

This reference consolidates the diagnostic path, root-cause catalog, and verified remediation steps for WinCC V7.2 Update 4 through WinCC V7.5 SP2 Update 19 deployments on Windows Server 2008 R2, 2012 R2, 2016, 2019, and 2022, including the canonical Siemens support entries that confirm each causal category.

1. Problem Description and Observable Symptoms

The error first manifests in the WinCC message system and is mirrored in the diagnostic log file WinCC_Sys_<xx>.log under the project root. A typical pair of lines looks like the following when reproduced on a WinCC V7.5 SP2 Update 19 server with Windows Server 2019 (Datacenter, build 1809):

2303,24.02.2025,13:07:09:315,1012301,4,,SRVCARL3,CCWriteArchiveServer,[(null),225]failed to insert into MSARCLONG with 0x80040E21(#705,'2025-02-24 12:07:08.590'),MSG_STATE_COME
2303,24.02.2025,13:07:52:128,1012302,4,,SRVCARL3,CCWriteArchiveServer,WinCC Process Archiving has stopped for TagId= 9860. More details in the documentation chapter 'Archiving Process Values > Basics of Process Values Archiving > Consistency of time stamps' in the WinCC Information System,MSG_STATE_COME

Observable operator-side symptoms include:

• No new entries are written to the alarm database while the message loop continues; on a heavily loaded plant this can lose thousands of events per hour.
• Tag Logging (process value archives) and Alarm Logging diverge. On some installations Tag Logging remains functional while Alarm Logging stalls; on others both subsystems stop, depending on which SQL blocking chain has formed.
• Tag gaps appear in the trend view and an "Archiving stopped" overlay is drawn on affected tags. The TagId referenced in 1012302 identifies the archive segment that failed last.
• Re-arming by running CCArchivemanager.exe -resetall does not clear the condition when the underlying SQL lock is still held.
• The frequency of the 1012301 entries is governed by the Alarm Logging retry timer; it is typically emitted at one-second intervals until the row insert succeeds or the archive segment is closed.

2. Affected Products, Versions, and Platforms

The MSARCLONG table is the long-text column store used by the WinCC Alarm Logging schema. It carries the Message Text field together with associated fields (e.g., Point of error, Info Text) for messages whose content exceeds the inline limit of the MSARC row, or whose text contains the Unicode characters that WinCC routes to MSARCLONG by design.

The native SQL error codes reported in the WinCC log are OLE DB / OLE Automation HRESULT values that are translated by CCWriteArchiveServer.exe from the underlying ODBC/SQL Server error:

Reference: Siemens Support Entry ID 109818900 — "How do you recognize and remove blocked database connections in the SQL Server for WinCC?" This entry is the canonical diagnostic article for the blocking-chain variant of 1012301.

3. Error Code Anatomy

The string emitted in WinCC_Sys_<xx>.log for 1012301 follows a stable structure:

[(server,sequence)]failed to insert into MSARCLONG with <HRESULT>(#<sqlstate>,'<timestamp>')

Field-by-field interpretation:

• (server, sequence) — The server is the configured logical archive server name (e.g., (null) when writing to the local default archive, or a named CAS partner). The sequence is the monotonically increasing call number from CCWriteArchiveServer.exe.
• MSARCLONG — The target table. Any switch to a different table (e.g., MSARC, MSARCHIVE) indicates a different sub-system of Alarm Logging; the table name itself is a strong hint at which archive channel is failing.
• HRESULT — The OLE DB return code from the SQL Server Native Client / OLE DB provider. Map back to SQL state with the table above.
• #<sqlstate> — The native sys.messages message_id from SQL Server (e.g., #705 is "RESTORE statement is incorrect" in some contexts, but more commonly the number in this position is the WinCC-side internal error counter; cross-check with SELECT message_id, text FROM sys.messages WHERE language_id = 1033 AND message_id = <n> on the host SQL instance).
• 'timestamp' — UTC timestamp at the WinCC Archive Manager when the insert was attempted. Use this to correlate with SQL Server Profiler or Extended Events traces captured during the same window.

The companion error 1012302 carries the TagId of the affected process-value archive. Resolve 1012301 first; in nearly every deployment the 1012302 self-clears once Alarm Logging can commit pending rows and the archive manager re-acquires its locks.

4. Root Cause Catalog

The five causal categories below are listed in descending order of frequency observed in the field, with the diagnostic signature for each.

4.1 SQL Server Blocking Chain on MSARCLONG / MSARC

The most common trigger. A long-running query (typically an ad-hoc SELECT from the Alarm Logging history view, an external reporting tool, a WinCC add-in, or a backup/AV scan that opened the .mdf files with a VSS snapshot) holds a schema or row lock that prevents CCWriteArchiveServer.exe from acquiring an exclusive lock for the new row. The (null,197 or (null,225 sequence number rises, the HRESULT becomes 0x80040E21 with SQL state 1222 (lock timeout) or 1205 (deadlock victim), and 1012301 floods the log.

Diagnostic signature: in sys.dm_exec_requests, find a wait_type of LCK_M_SCH_M, LCK_M_X, or LCK_M_U on object MSARCLONG; the blocking session has status = 'running' and a command of SELECT or BACKUP DATABASE.

4.2 SQL Server Service Stopped, Restarting, or Network-Path Failure

If the SQL Server (WINCC) service is stopped, the WinCC Archive Manager emits 0x80004005 with the generic "No access to SQL server" text. The 1012301 entries continue at one-second intervals even when the server is fully offline because the connection is retried indefinitely.

Diagnostic signature: netstat -ano | findstr 1433 from the WinCC server returns no listener; sqlcmd -S WINCC -E -Q "SELECT @@SERVERNAME" returns a network or pipe error. Cross-check the Windows event log for MSSQLSERVER errors 17179, 17182, or service-control-manager event 7036.

4.3 Authentication / Login Drift

WinCC V7 stores SQL login credentials for the Alarm Logging / Tag Logging connections in the Windows registry under HKLM\SOFTWARE\Wow6432Node\Siemens\WinCC\SQL and the project database. If the SQL login password was rotated, the local group SQLServer2005SQLBrowserUser$WinCC membership was changed, or a Group Policy applied a password expiry, the next insert returns 0x80004005 with SQL state 18456 (login failed) or 15151 (login does not exist).

Diagnostic signature: SQL Server error log shows "Login failed for user 'CC_<project>_<role>'" with state 5 (invalid user id) or state 8 (password mismatch).

4.4 Disk Pressure, Quota, or File-System Stall

The WinCC archive databases CC_Alg_<date>_<time>.mdf, CC_Tlg_<date>_<time>.mdf grow on a configurable schedule. If the target volume runs out of space, the VSS snapshot cannot complete, or anti-virus scans the .mdf file in real time, the SQL transaction log fills and inserts start failing with HRESULT 0x80004005 and SQL state 9002 (transaction log full) or 1105 (could not allocate space).

Diagnostic signature: DBCC SQLPERF(LOGSPACE) on the WINCC instance shows Log Space Used (%) > 95 and Status = 0; sys.database_files shows is_percent_growth = 1 with growth = 0 on a full disk.

4.5 Memory or Worker-Thread Exhaustion on the Host OS

Siemens Support Entry ID 109760739 notes that internal WinCC errors of this class can also be raised when the operating system is overloaded: the SQL Server host process is being paged, the WinCC Archive Manager cannot allocate a connection from the pool, and the resulting timeout presents as 1012301 even though the SQL Server itself is healthy. Antivirus suites, RDP sessions, or third-party backup agents that consume large working sets trigger this category.

Diagnostic signature: Performance Monitor counter \Memory\Available MBytes < 512; \SQLServer:General Statistics\Processes blocked > 0 with all blocked processes waiting on memory grant; dbcc memorystatus shows Memory Grants Pending > 0.

5. Pre-Diagnostic Checklist

Before changing any configuration, capture the following artifacts. They form the evidence chain that any Siemens support engineer will request.

1. Open WinCC Explorer > Tools > WinCC System Information and export the full system dump. Note the exact build string of CCWriteArchiveServer.exe from the running process (Task Manager > Details > right-click column > choose "Image path name").
2. Copy <ProjectPath>\WinCC_Sys_<xx>.log and <ProjectPath>\Diagnostics\WinCC_Sql_<xx>.log for the affected day. Both files roll over at midnight UTC by default.
3. Run SELECT @@version, SERVERPROPERTY('ProductLevel'), SERVERPROPERTY('ProductUpdateLevel') on the WINCC SQL instance and save the result.
4. Capture DBCC OPENTRAN on the CC_Alg_<current> and CC_Tlg_<current> databases; this is the fastest way to see the blocking session ID.
5. Note the current WinCC archive configuration: in WinCC Explorer > Alarm Logging > right-click > Properties > Time Segments, and in Tag Logging > Archives > Properties > Tag Supply. These tell you the segment size, retention, and swap policy in effect when the error first appeared.

6. Resolution Procedures

6.1 Resolve a Blocking Chain (Category 4.1)

1. On the WinCC server, open SQL Server Management Studio and connect to the WINCC instance as sa or a member of sysadmin.
2. Run:

   SELECT
       r.session_id AS blocked_session,
       r.blocking_session_id AS blocking_session,
       r.wait_type,
       r.wait_time,
       r.command,
       t.text AS sql_text,
       OBJECT_NAME(p.objectid) AS object_name
   FROM sys.dm_exec_requests r
   CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
   OUTER APPLY sys.dm_exec_plan_attributes(r.plan_handle) p
   WHERE r.wait_type LIKE 'LCK_%'
     AND r.database_id = DB_ID('CC_Alg_<current_archive>');

3. Identify the head of the blocking chain. Confirm with the application team whether the blocking SELECT is a planned query (e.g., shift-end report) or an orphaned session.
4. Two safe actions are available:
   • Ask the application owner to commit or roll back the transaction.
   • If the session is confirmed stale, execute KILL <blocking_session_id> with WITH STATUSONLY first to confirm it is not rolling back a large transaction.
5. After the head blocker is released, watch CCWriteArchiveServer log entries. The 1012301 messages should stop within the next archive-manager retry interval (default 1 s). A single final entry is normal.
6. Long-term fix: add a covered index on MSARCLONG.MsgID, MSARCLONG.MsgNr for the reports that take the lock; review the auto-growth and lock-escalation thresholds on the archive database.

6.2 Restore the SQL Server Service (Category 4.2)

1. Open services.msc on the WinCC / SQL host. Confirm that SQL Server (WINCC) and SQL Server Agent (WINCC) are in state Running.
2. If the service is stopped, attempt to start it. Capture the Windows application event log entries with Event Viewer > Windows Logs > Application > Source = MSSQLSERVER.
3. If the service fails to start with error 9001 ("The log for database 'master' is not available") or 945 ("Database 'CC_Alg_...' cannot be opened due to inaccessible files"), recover the database following the Siemens blocking-connections note and the standard SQL Server recovery procedure.
4. Verify network name resolution: ping <sql-host-fqdn> and nslookup <sql-host-fqdn> from the WinCC server. WinCC stores the SQL host name in the project configuration; renaming the host without updating it is a common silent failure.
5. Once SQL is reachable, allow up to 60 seconds for the Archive Manager to re-establish its connection pool. The 1012301 cycle should self-clear.

6.3 Repair Authentication Drift (Category 4.3)

1. Identify the SQL login in use. On the SQL instance:

   SELECT name, type_desc, is_disabled, default_database_name
   FROM sys.server_principals
   WHERE name LIKE 'CC_%' OR name LIKE 'WinCC%';

2. Reset the password for that login to the value stored in the WinCC project: WinCC Explorer > Computer > Properties > Startup reveals the SQL configuration; the credential is also mirrored in HKLM\SOFTWARE\Wow6432Node\Siemens\WinCC\SQL under the value Password.
3. Re-enter the password in WinCC Explorer: open the Computer properties, navigate to the SQL Server tab, and click Update. The dialog writes the new value back to the registry and to the project configuration database.
4. If the password was rotated by Group Policy, set a Group Policy preference for the WinCC service account so future rotations do not desynchronize the registry value.
5. Restart the WinCC Archive Manager service: net stop "S7WinCCxRtManager" && net start "S7WinCCxRtManager" (replace x with the project number), or restart the computer if a full WinCC bounce is allowed.

6.4 Free Disk / Quota (Category 4.4)

1. Identify the disk hosting the archive MDF/LDF files. The default path is C:\Program Files (x86)\Microsoft SQL Server\MSSQL<instance>\MSSQL\DATA; projects may be redirected to a separate volume.
2. Extend the volume, move the archive databases, or set the archive segment size in WinCC to a smaller value to reduce the per-cycle footprint. In WinCC Explorer > Alarm Logging > Archive Configuration > Time Segments, the segment size and maximum segment count together bound disk consumption.
3. If the transaction log is full, run BACKUP LOG [CC_Alg_<current>] TO DISK = N'<path>' WITH INIT, COMPRESSION (only if the database is in Full recovery), then DBCC SHRINKFILE (CC_Alg_<current>_log, 1024) to reclaim space.
4. Add the WinCC archive directory and the SQL data directory to the anti-virus exclusion list, following the vendor's recommended exclusions for SQL Server.
5. After cleanup, verify with:

   DBCC SQLPERF(LOGSPACE);
   SELECT name, size * 8 / 1024 AS size_mb, physical_name FROM sys.master_files WHERE database_id = DB_ID();

6.5 Address OS / Memory Pressure (Category 4.5)

1. Open Resource Monitor and identify the top memory consumer. Stop non-essential services and applications.
2. Configure the SQL Server maximum memory: sp_configure 'max server memory', <bytes>; RECONFIGURE; Reserve at least 4 GB for the WinCC server process and Windows.
3. Disable or correctly configure the third-party backup, screen-sharing, or remote-management tools that scan the WinCC folders in real time.
4. Refer to Siemens Support Entry ID 109760739 for the official guidance on memory-related internal errors in WinCC V7.5.
5. After reducing pressure, allow the Archive Manager to recover. If the recovery does not occur within five minutes, restart the WinCC CCWriteArchiveServer process: taskkill /im CCWriteArchiveServer.exe /f (the WinCC project restarts it automatically).

7. Step-by-Step Diagnostic Procedure (Single Decision Tree)

Use this condensed decision tree when the cause is not known up front.

1. Capture the last 100 lines of WinCC_Sys_<xx>.log. If the table name is anything other than MSARCLONG, follow the matching Siemens note for that table; if it is MSARCLONG, continue.
2. Run DBCC OPENTRAN on CC_Alg_<current>. If a session ID is returned, jump to 6.1.
3. If DBCC OPENTRAN is empty, run SELECT state_desc FROM sys.databases WHERE name = 'CC_Alg_<current>';. If the state is not ONLINE, jump to 6.2.
4. Check the SQL Server error log: xp_readerrorlog 0, 1, N'Login failed'. If any rows are returned, jump to 6.3.
5. Check disk: DBCC SQLPERF(LOGSPACE). If Log Space Used (%) > 95 or Status = 2, jump to 6.4.
6. Check memory: SELECT * FROM sys.dm_os_performance_counters WHERE counter_name IN ('Available MBytes','Memory Grants Pending'). If Available MBytes < 512 or Memory Grants Pending > 0, jump to 6.5.
7. If all of the above are clean, capture an Extended Events trace on the WINCC instance filtered to sqlserver.error_reported and reproduce the alarm. The trace will capture the native error message that WinCC's HRESULT masked.

8. Verification Steps

After applying the corrective action, validate recovery with the following checks:

1. Log watch. Tail WinCC_Sys_<xx>.log and confirm no new 1012301 or 1012302 entries appear for at least 30 minutes. Existing entries remain in the log and are part of the audit trail; do not delete them.
2. Alarm insert probe. Trigger a known tag change that produces a configured alarm in Alarm Logging and confirm a new row appears in SELECT TOP 10 * FROM CC_Alg_<current>.dbo.MSARC ORDER BY MsgID DESC; within 5 seconds. Confirm the corresponding MSARCLONG row exists with the expected text payload.
3. Tag Logging recovery. If 1012302 had been raised, the Archiving stopped overlay should clear within one archive cycle (default 1 s) of the Alarm Logging insert succeeding. A forced rearm via CCArchivemanager.exe -rearm <TagId> can be used as a verification action; it should not be required once the underlying fault is fixed.
4. Database health. Run DBCC CHECKDB('CC_Alg_<current>') WITH NO_INFOMSGS; to confirm no schema or allocation corruption was introduced by the event.
5. Operator view. Confirm the operator HMI shows fresh alarm entries and that the alarm list filter does not return a stale view. On multi-user systems, repeat the check from at least one client to verify the server-to-client data path.

9. Prevention and Hardening

Siemens also publishes the official entry ID 109818900 on blocking-database-connection diagnostics in SQL Server for WinCC, and the related memory-overload note ID 109760739 for V7.5. Both are recommended as the primary manufacturer references to attach to the change record when remediating 1012301.

10. Field-Notes: Edge Cases and Common Pitfalls

• CCArchivemanager.exe -resetall does not help. The flag clears the in-memory archive cache and the time-stamp continuity check that 1012302 references, but it does not release the SQL lock held by another session. Siemens Support 109818900 is the canonical note for why a reset does not resolve a blocking-chain variant.
• Anti-virus in real-time mode. Many enterprise anti-virus products default to scanning .mdf and .ldf files as they are written. This can present as a slow block (state 1222) or a complete failure (state 9002) depending on whether the AV intercepts the write or the read. Add the SQL data directories to the AV exclusion list and confirm with the AV vendor's published SQL exclusion guidance.
• Remote-management / screen-sharing agents. Tools such as TeamViewer, AnyDesk, and enterprise RMM agents that open the SQL data directory in a file-list view will hold a handle that the SQL writer must wait for. The agent must be configured to exclude WinCC and SQL data folders.
• Time-stamp consistency on multi-server CAS. When the redundant Central Archive Server (CAS) configuration is in use, time-skew between the two servers can produce a sequence of 1012302 errors that look like 1012301 precursors. Verify NTP discipline and the server clock against a known good source before deeper diagnosis.
• WinCC V8 on a non-supported SQL version. WinCC V8 has a documented SQL Server version matrix. Running it against a SQL Server version that is not in the matrix can produce 1012301 with a generic OLE DB error. Always confirm the SQL Server version against the WinCC installation manual for the project.
• OEM service accounts. If a third-party SCADA add-in uses a different SQL login and that login was changed, WinCC's own login may continue to work but the add-in's queries will hold locks. Audit all SELECT sessions on CC_Alg_<current> with sys.dm_exec_sessions to find the culprit.

11. Frequently Asked Questions