Resolving WinCC 7.2 AutostartRT SQL Error 18456 State 38

Problem Overview

WinCC 7.2 AutostartRT fails to bring a runtime project online after a host reboot on Windows Server 2008 R2. After 15-20 minutes of stalled loading, the runtime dialog reports:

Error while opening the project \\SRV-SCADA-EN\<project> ... Autostart not possible.

The same project opens successfully when launched manually (via WinCC Explorer or a desktop shortcut), reaching the runtime surface in roughly two minutes. The automated path never recovers without a manual restart of the runtime.

Concurrent Windows Application and SQL Server logs show an authentication failure against the WinCC project database at the moment AutostartRT tries to attach it:

01/20/2015 13:31:13, Logon, Unknown, Login failed for user 'SRV-SCADA-EN\Administrator'.
Reason: Failed to open the explicitly specified database. [CLIENT: <local machine>]
01/20/2015 13:31:13, Logon, Unknown, Error: 18456, Severity: 14, State: 38.

This combination is a classic SQL Server "login OK, database not yet reachable" failure during service-startup sequencing.

Environment Snapshot

Root Cause Analysis

SQL Server error 18456 is the generic "Login Failed" class. The state code is the only reliable indicator of the underlying problem.

State 38 with the message "Failed to open the explicitly specified database" indicates that the SQL login authenticates successfully but the database WinCC asked it to use is not yet in a state that allows a connection. During server boot the WinCC runtime service attempts to open the WinCC project database before the SQL Server service has completed recovery of that database, or before the WinCC-specific login has been mapped to a database user with the db_owner / public rights it requires.

The reason Autostart hangs for 15-20 minutes (the SQL Server default connection timeout plus retry behavior in the WinCC startup path) while manual launch completes in 2 minutes is sequencing: the human starts WinCC Explorer long after SQL Server is fully recovered, so the same login succeeds immediately. Autostart fires within seconds of the OS login session, while SQL Server is still finalizing recovery on slow disks or under antivirus interference.

Pre-Diagnostic Checklist

1. Open SQL Server Management Studio on the WinCC server and confirm the SQL Server service state is "Running (Recovery)" vs. "Running (Online)". The recovery state during boot is the trigger.
2. Run the query below and note the state_desc and user_access_desc of each WinCC database:

   SELECT name, state_desc, user_access_desc, is_read_only, is_in_standby
   FROM sys.databases
   WHERE name LIKE 'CC%' OR name LIKE 'WinCC%' OR name = 'master';

3. Confirm the SQL login used by the WinCC runtime exists and is enabled:

   SELECT name, type_desc, is_disabled, default_database_name
   FROM sys.server_principals
   WHERE name = 'SRV-SCADA-EN\Administrator';

4. Verify the database user mapping for every WinCC database:

   SELECT dp.name AS db_user, dp.type_desc, dp.authentication_type_desc,
          r.name AS role_name
   FROM sys.database_principals dp
   LEFT JOIN sys.database_role_members rm ON dp.principal_id = rm.member_principal_id
   LEFT JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id
   WHERE dp.name = 'SRV-SCADA-EN\Administrator' OR dp.sid = SUSER_SID('SRV-SCADA-EN\Administrator');

5. Check Windows Event Viewer -> Application for SQLSERVER and WinCC event IDs 18456, 17204, 17207, 9001, 9002 (recovery and I/O related).
6. Inspect the WinCC project directory <ProjectPath>\<ComputerName>\<ProjectName>.mdf file lock state using Process Explorer or handle.exe.
7. Confirm no antivirus, backup agent, or disk-snapshot tool is locking the MDF/LDF files during the early boot window.

Resolution Path A - Repair SQL Login and Database Mapping

The fastest, deterministic fix is to make sure the account AutostartRT uses has a valid, online mapping to every WinCC database at the moment WinCC requests it.

1. Open SQL Server Management Studio as a member of sysadmin.
2. For the WinCC service login, re-create the database user in every WinCC database and assign db_owner:

   USE [CC_Project_xxx];
   CREATE USER [SRV-SCADA-EN\Administrator] FOR LOGIN [SRV-SCADA-EN\Administrator];
   ALTER ROLE db_owner ADD MEMBER [SRV-SCADA-EN\Administrator];
   -- Repeat for CC_Alarms, CC_Logging, CC_UserArchives, CC_RTDatabase, etc.

3. Set the default database explicitly to the WinCC project database to avoid "default database unavailable" state 38:ALTER LOGIN [SRV-SCADA-EN\Administrator] WITH DEFAULT_DATABASE = [CC_Project_xxx];
4. Confirm the WinCC SQL login (machine-scoped) CCAdmin$<PC> and the dedicated runtime users exist and own the runtime database. Refer to the WinCC V7.2 Installation Notes / Configuration Manual for the exact list of logins the installer creates.
5. Restart the SQL Server (MSSQLSERVER) service and verify state_desc = ONLINE for all WinCC databases before reattempting Autostart.

Resolution Path B - Service Dependency and Boot Sequencing

If the database mapping is correct but SQL Server simply is not online when Autostart fires, force the WinCC runtime to start strictly after SQL Server has finished recovery.

1. Open services.msc.
2. Locate SIMATIC WinCC Explorer / CCAgentStartup / WinCC Runtime depending on the deployed configuration.
3. Open Properties -> Dependencies tab and add:
   • SQL Server (MSSQLSERVER)
   • SQL Server Agent (MSSQLSERVER) if used
   • Server (the Workstation/Server service - WinCC uses it for UNC and license paths)
4. Set the service Startup type to Automatic (Delayed Start) with a 60-120 s delay. The "Manual start works because the operator waits" observation is exactly what a delayed start reproduces legitimately.
5. If the WinCC runtime is launched via AutostartRT from WinCCExplorer.exe /Activate, replace it with a script dependency on the SQL Server service (see Resolution Path C).

Resolution Path C - Configure AutostartRT With SQL Wait Logic

Siemens documents two canonical methods for AutostartRT on WinCC V7.x: the WinCC_Batch.bat plus wait.exe helper, and the explicit configuration of AutostartRT in WinCC Explorer for server / client / redundant scenarios.

1. In WinCC Explorer open Computer properties -> Autostart tab. Enable AutostartRT and define the startup list explicitly rather than relying on the project default.
2. Create a launcher batch file that polls SQL Server before starting the runtime:

@echo off
REM === WinCC_AutostartRT_Dependency.bat ===
set SQL_INSTANCE=.\WINCC
set TARGET_DB=CC_Project_xxx

:WAIT_SQL
sqlcmd -S %SQL_INSTANCE% -Q "SELECT 1" -h -1 -W >nul 2>&1
if errorlevel 1 (
  echo [%date% %time%] SQL Server not ready, retrying...
  timeout /t 10 /nobreak >nul
  goto WAIT_SQL
)

:WAIT_DB
for /f "usebackq tokens=*" %%a in (`sqlcmd -S %SQL_INSTANCE% -h -1 -Q "SET NOCOUNT ON; SELECT COUNT(*) FROM sys.databases WHERE name='%TARGET_DB%' AND state_desc='ONLINE'"`) do set DB_OK=%%a
if "%DB_OK%" NEQ "1" (
  echo [%date% %time%] Database %TARGET_DB% not ONLINE yet, retrying...
  timeout /t 10 /nobreak >nul
  goto WAIT_DB
)

echo [%date% %time%] SQL and DB ready. Launching WinCC Runtime...
"C:\Program Files (x86)\Siemens\WinCC\bin\WinCCExplorer.exe" "C:\Program Files (x86)\Siemens\WinCC\WinCCProjects\<Project>\<Computer>.pck" /Activate

3. Disable the built-in AutostartRT checkbox in WinCC Explorer to prevent the original 15-20 min failure path from running in parallel.
4. Drop the script into %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup\ or schedule it as a Windows Task with the trigger "At system startup" and the condition "Start only if the computer is on AC power".
5. Keep wait.exe from the Siemens FAQ referenced in Manual Workaround below if a simpler fixed-delay approach is acceptable.

Manual Workaround - WinCC_Batch With wait.exe

This is the documented "good enough" approach when timing fixes are not allowed. The wait.exe utility is delivered with WinCC V7.x and lets the batch hold the runtime launch for a fixed duration after SQL Server starts.

1. Copy wait.exe from the WinCC installation media to C:\Program Files (x86)\Siemens\WinCC\bin\.
2. Create WinCC_Batch.bat:

@echo off
REM Wait 180 seconds so SQL Server has finished recovery
"C:\Program Files (x86)\Siemens\WinCC\bin\wait.exe" 180
"C:\Program Files (x86)\Siemens\WinCC\bin\WinCCExplorer.exe" /Activate

3. Disable AutostartRT in WinCC Explorer to prevent the failing path.
4. Place the batch in the user Startup folder for the account that logs on at boot, or convert it to a Windows Task scheduled to run as SYSTEM with delay.

Related WinCC V7.2 Configuration Items

Verification

1. Reboot the server and let it boot unattended - do not log in early.
2. Wait for the WinCC runtime surface to appear or confirm via the CCAgentCtrl.exe / WinCCExplorer.exe process that the runtime process is running with the correct project context.
3. Inspect SQL Server logs for the same boot window. The line Login failed ... State 38 must be absent.
4. Open WinCC Alarm Logging and Tag Logging runtime databases in SQL Management Studio and confirm they accept queries immediately after boot.
5. Force a SQL Server service restart and confirm the launcher script retries automatically until the database is online, then brings WinCC up.
6. Validate licensing: the WinCC license plug-in must be present before SQL Server recovery reaches a state where the runtime will query it; otherwise a related but different failure appears.

Troubleshooting Matrix

Preventive Hardening

• Move WinCC runtime databases to a dedicated local volume and exclude the volume from any real-time AV scan.
• Make SQL Server Automatic (Delayed Start) so it never races with disk initialization.
• Use a dedicated service account for SQL Server instead of LocalSystem when the WinCC project path is on a UNC share.
• Keep WinCC V7.2 at the latest update level (V7.2 SP1 / V7.2 ASIA Update releases) - Siemens patched several AutostartRT startup race conditions over the lifetime of V7.2.
• Document the dependency chain: SQL Server -> CCAgent -> WinCC Runtime. Without this, every Windows update reintroduces the race.
• Centralize the SQL audit log review so future 18456 events trip a monitoring rule immediately rather than being discovered weeks later.

FAQ