Resolving WinCC V7.3 'Restart of the Computer' Startup Error

Problem Summary

Siemens WinCC V7.3 with Update 4 (release identifier V07.03.20.04_01.05.00.01) running on Windows 7 SP1 fails to start a runtime project. When the operator selects the project's runtime (Play) in WinCC Explorer, or the OS auto-starts the project, the application appears to load for an extended period (often tens of seconds to several minutes) and then a Windows hard-error dialog appears with the message "An error has occurred that requires a restart of the computer. Close all applications if possible, and trigger a restart with the OK button." The error occurs reproducibly on every attempt to start the project. The PLC connection is otherwise functional, and the engineering station is able to open the project for configuration. The failure is typically isolated to the operator station (OS) in a WinCC V7.3 client/server or single-station topology.

This is not a WinCC application error in the usual sense. The dialog is raised by the Windows Error Reporting (WER) / Application Error subsystem when a user-mode component faults in a way that prevents the process from continuing and the process is configured to be terminated with a hard error. The actual fault originates in one of three subsystems: the WinCC runtime host (CCRT.exe / WinCC_RT.exe depending on version and configuration), the embedded Microsoft SQL Server instance, or a Windows system component (commonly MSVCR, the .NET CLR, or the Win32 subsystem itself).

Environment and Versions Affected

For current WinCC V7.3 lifecycle information refer to the Siemens Product Support portal for SIMATIC HMI / WinCC and the WinCC Information System installed with the software. Windows 7 SP1 reached mainstream support end in 2015 and extended support ended in January 2020; this is itself a contributing factor and is called out again in the preventive measures.

Root Cause Analysis

The Windows hard-error dialog indicates that a structured exception (often an access violation, 0xC0000005, or a stack overflow, 0xC00000FD) propagated out of the faulting process and could not be handled in-process. In a WinCC V7.3 OS station, the most common root causes observed in the field, in descending order of frequency, are:

1. Locked or corrupted SQL Server project database. The WinCC project database is mounted by the WINCC SQL instance at RT start. If the previous WinCC RT shutdown was not clean (power loss, kill of CCRT.exe, RDP session end), the CC_<ProjectName>_<TS>.mdf and _log.ldf files may be locked, marked suspect, or have an inconsistent transaction log.
2. Stale Remote Desktop session on a console-attached OS. WinCC RT must own the physical console (Session 0 / WinSta0) and a disconnected or lingering RDP session can block the runtime from acquiring the workstation, causing a fault inside the WinCC startup path.
3. Corrupted or partial Windows system component — typically MSVCR120.dll, MSVCR140.dll, .NET Framework 4.x, or a broken Visual C++ Redistributable. The WinCC RT loads the SQL Server Native Client and several C runtime DLLs at start; any of these failing to initialize can surface as the hard-error.
4. Damaged WinCC installation — missing or replaced files in %ProgramFiles(x86)%\Siemens\Automation\WinCC\bin or ...\WinCC\bin. Common after partial Windows updates or third-party "cleaner" tools.
5. Antivirus / endpoint protection quarantining of WinCC binaries or the CC_*.mdf database while WinCC is running. The next start then fails with a file-handle fault.
6. Insufficient user rights on the project folder or on the WINCC SQL Server instance. WinCC RT is not started as a service by default; it runs in the context of the logged-in user and that user must be a member of the local SIMATIC HMI group and have db_owner on the project database.

Items (1) and (2) together account for the majority of field cases. Items (3) and (4) become more likely as the OS ages past its support window.

Pre-Diagnostic: Information Gathering

Before changing any configuration on the OS, capture the following baseline. All logs and screenshots should be stored off the OS to avoid being overwritten by a forced restart.

1. Record the exact WinCC version and update level. In WinCC Explorer > Help > About, copy the build string. The expected string for the affected release is V07.03.20.04_01 05.00.01 (Update 4).
2. Record the operating system build. Open winver.exe from the start menu and capture the full version string. Confirm Windows 7 SP1 and note the installed hotfix level (systeminfo > OS Hotfix(s)).
3. Export the Windows Application and System event logs from the time of the most recent attempt. Open Event Viewer > Windows Logs > Application, right-click > Save All Events As.... Look for:
   • Event ID 1000 (Application Error) with Faulting application name = CCRT.exe, WinCC_RT.exe, or sqlservr.exe
   • Event ID 7034 / 7031 (Service Control Manager) for any of the WinCC or SQL services terminating unexpectedly
   • Event ID 9001 / 9002 (MSSQLSERVER) for transaction log issues
4. Check the SQL Server error log. The default path is C:\Program Files (x86)\Microsoft SQL Server\MSSQL12.WINCC\MSSQL\Log\ERRORLOG for SQL 2014, or ...\MSSQL10_50.WINCC\... for SQL 2008 R2. Open the most recent ERRORLOG.* and search for lines containing "Recovery is complete" and the line immediately above (the database name and state).
5. Confirm the project path. In WinCC Explorer on the ES, check Project Properties > Project Path on the matching OS, or look at the locally running project's Project.pck shortcut properties on the OS. The default location is C:\WinCC\Projects\<ProjectName>\.
6. Check for active or disconnected RDP sessions. From an elevated command prompt on the OS: qwinsta and look for any session in state Disc or owned by a user other than the currently logged-on console user. If the OS has ever been accessed by RDP, treat a stale session as a primary suspect until proven otherwise.

Diagnostic Procedure

Work the following checks in order. The diagnostic is structured so that the most likely cause is ruled out first, and the least invasive remedy is applied before any reinstall is attempted.

Step 1 — Confirm the OS vs ES scope

Open the same project on the engineering station (ES) and start the runtime there. If the ES also fails with the same hard-error, the fault is in the project file itself, the SQL database, or a shared system component — not in the OS station configuration. If the ES starts cleanly, isolate the failure to the OS using the rest of this procedure.

Step 2 — Rule out a stale RDP session

If qwinsta shows a disconnected session, the WinCC RT cannot acquire the desktop. Force the session off:

query session
logoff <ID> /server:localhost
reset session <ID> /server:localhost

After the session is removed, retry the project start. If the hard-error no longer occurs, the root cause was a stale RDP session and the OS should be configured to either disallow RDP entirely or use a dedicated service account that logs off at session end.

Step 3 — Check the SQL Server project database

Start SQL Server Management Studio (SSMS) and connect to the local instance .\WINCC using Windows authentication. Expand Databases and look for the project database, which has the form CC_<ProjectName>_<TS>. The database must be in the Normal state. If it is in Suspect, Recovery Pending, or Emergency, this is the source of the fault.

For a suspect database, run the following T-SQL from SSMS, substituting the actual database name:

USE master;
ALTER DATABASE [CC_<ProjectName>_<TS>] SET EMERGENCY;
DBCC CHECKDB ([CC_<ProjectName>_<TS>]) WITH NO_INFOMSGS;
ALTER DATABASE [CC_<ProjectName>_<TS>] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ([CC_<ProjectName>_<TS>], REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE [CC_<ProjectName>_<TS>] SET MULTI_USER;

If the database reports as suspect only intermittently, the underlying cause is a hard shutdown or a full transaction log. Verify disk space on the SQL data and log drive and ensure the SQL Server service account has full control on the project folder.

Step 4 — Test with a clean copy of the project

Copy the project folder to a fresh directory on the OS, for example C:\WinCC\Projects\Project_test\, and start it from that location. WinCC will re-create the local DataSourceName registration. If the copy starts cleanly, the original project folder is locked or has filesystem-level damage (permissions, ACL, or file-system filter driver issues). Re-image the OS or restore from a known-good backup of the project folder.

Step 5 — Validate the SQL Server instance independently

Create a brand new, empty WinCC project on the OS using WinCC Explorer > File > New and start it. If the new project also produces the hard-error, the fault is not project-specific; the SQL Server instance, the WinCC installation, or Windows itself is suspect. Continue to Step 6.

Step 6 — Inspect Windows system components

Run the following checks from an elevated command prompt:

Review the sfc log at C:\Windows\Logs\CBS\CBS.log for any unrepairable component store corruption. If SFC reports errors it cannot fix, run:

Then re-verify the Visual C++ Redistributable versions installed:

WinCC V7.3 expects the 2005, 2008, 2010, 2012, 2013, and 2015-2022 redistributables to be present. Any missing or "broken" entry (visible in Programs and Features as the install date being 1601 or as an error during launch) should be repaired from the redistributable installer or removed and reinstalled.

Recovery Procedure A — Corrupted Project Database

This is the most common field fix. Use when Step 3 above shows the project database is in a non-normal state.

1. Stop the WinCC runtime and the WinCC service group:

   net stop "WinCC Runtime"
   net stop "CCArchiveServer"
   net stop "CCDistManager"
   net stop "CCProjectManager"
   net stop "CCNSAlarmServer"
   net stop "CCEventMgr"
   net stop "CCLicenseServer"

   (exact service names vary by WinCC version and installed options; verify in services.msc.)
2. Stop the WINCC SQL instance: net stop "MSSQL$WINCC"
3. Move the existing database files out of the project folder:

   move "C:\WinCC\Projects\<Project>\CC_*.mdf"  "C:\WinCC\Projects\<Project>\backup\"
   move "C:\WinCC\Projects\<Project>\CC_*_log.ldf" "C:\WinCC\Projects\<Project>\backup\"

4. Start the SQL instance and run the T-SQL repair block from Step 3 of the diagnostic procedure.
5. Start the WinCC services in the order shown in Verification, then start the project.

If the repair block returns errors, the database is unrecoverable and the project must be restored from the most recent good backup. WinCC projects should be archived via WinCC Explorer > Project > Archiving; restoring the archive recreates the CC_*.mdf automatically when the project is first started.

Recovery Procedure B — SQL Server Instance Issue

Use when Step 5 shows that a brand new project also fails, indicating the SQL Server instance itself is unhealthy.

1. Open SQL Server Configuration Manager on the OS and confirm the WINCC instance is running. If it is stopped, attempt to start it and review the SQL error log.
2. Verify the WinCC user is mapped to the db_owner role. In SSMS:

   USE [CC_<ProjectName>_<TS>];
   SELECT dp.name, dp.type_desc, drm.role__desc
   FROM sys.database_principals dp
   JOIN sys.database_role_members drm ON dp.principal_id = drm.member_principal_id
   WHERE drm.role_principal_id = DATABASE_PRINCIPAL_ID('db_owner');

   The logged-in Windows user (or the service account) must appear. If not, add it:

   USE [CC_<ProjectName>_<TS>];
   CREATE USER [<DOMAIN\<USER>] FOR LOGIN [<DOMAIN\<USER>];
   ALTER ROLE db_owner ADD MEMBER [<DOMAIN\<USER>];

3. If the instance will not start, check the ERRORLOG for the line "Recovery of database 'CC_...' failed" followed by a stack trace. The most common cause at this point is a damaged master database; repair or reinstall the SQL Server instance using the WinCC V7.3 setup media in maintenance mode.

Recovery Procedure C — RDP Session Lock

Use when Step 2 of the diagnostic procedure identified a stale session.

1. Log off any active and disconnected RDP sessions.
2. Open Local Group Policy Editor (or the equivalent GPO) and navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits. Set Set time limit for disconnected sessions to a finite value (e.g., 1 minute) and Set time limit for active but idle sessions to a finite value.
3. Where possible, restrict RDP access to the OS station to a small list of named users and ensure those users always log off at session end.
4. Consider installing a KVM or using a console-only management tool. WinCC RT is fundamentally a console application and RDP is not a supported long-term access path on an OS station.

Recovery Procedure D — WinCC Installation Repair

Use when all of the above have been ruled out or when the fault occurs on a brand new project (Step 5).

1. Insert the WinCC V7.3 Update 4 installation media (or mount the ISO). The setup will detect the existing installation and offer Modify, Repair, or Uninstall.
2. Choose Repair. The repair operation re-registers COM components, restores bin\ DLLs, and rebuilds the SIMATIC HMI local group and DCOM launch permissions. This typically takes 10 to 30 minutes.
3. Reboot the OS after the repair.
4. Re-apply WinCC V7.3 Update 4 on top of the repaired installation. Cumulative updates must be re-applied after any repair.
5. If the fault persists, capture the full CCRT.exe crash dump (see Verification) and contact Siemens Technical Support with the WinCC build, the dump, and the SQL error log.

Verification

After applying any of the above recoveries, perform the following sequence in this order. Do not skip the service start order; WinCC RT depends on the SQL instance and the alarm/archive services being healthy before it attempts to mount the project database.

1. Confirm the SQL instance is running. From an elevated command prompt: sc query "MSSQL$WINCC" | findstr STATE The expected line is STATE : 4 RUNNING.
2. Confirm the WinCC services are running:

   sc query "WinCC Runtime" | findstr STATE
   sc query "CCArchiveServer" | findstr STATE
   sc query "CCDistManager" | findstr STATE

   All should report STATE : 4 RUNNING.
3. Open SQL Server Management Studio and confirm the project database is in the Normal state and db_owner is correctly mapped.
4. Open WinCC Explorer on the OS and start the project runtime. The progress indicator should complete in 5 to 20 seconds, not the tens of seconds to minutes seen during the fault. The runtime window should open with the configured start picture, alarm/audit status indicators should show green or amber (configured values), and the connection to the PLC should be established.
5. Force a tag update from the PLC side (write a value from the ES or from the PLC programming software) and confirm the value appears in the runtime within the configured update time. WinCC V7.3 default tag update is 1 second, 250 ms, or 500 ms depending on the channel unit configuration; consult the channel configuration for the exact value.
6. Check the Application event log for any new Event ID 1000 entries. A clean start should produce no new application errors.
7. Force a controlled shutdown (close the project in WinCC Explorer, do not kill CCRT.exe) and confirm the SQL database detaches cleanly (no "Recovery completed for database 'CC_...'" in the SQL error log on the next start).

For ongoing regression coverage, configure a startup script on the OS that runs the following after each reboot, and logs the result:

qwinsta
sc query "MSSQL$WINCC"
sc query "WinCC Runtime"

A clean return from this script before WinCC is started is the single most reliable indicator that the OS will not re-enter the hard-error state.

Preventive Measures

• Apply the latest WinCC V7.3 service pack and update on a planned outage. For V7.3, the last publicly released cumulative update stack ends with Update 4; later V7.4 / V7.5 should be evaluated for migration. Lifecycle information is published on the Siemens Product Support portal.
• Migrate the OS off Windows 7. Windows 7 reached end of extended support on 14 January 2020; running a production WinCC V7.3 OS station on an unsupported OS exposes the installation to security patches that break WinCC components and to missing fixes for the .NET CLR and C runtime that WinCC depends on.
• Disable or strictly scope antivirus on the WinCC project folder, the SQL data folder, and the %ProgramFiles(x86)%\Siemens\Automation\ tree. Exclusions are documented in the WinCC Information System — WinCC Installation Notes > Working with Antivirus Software.
• Never kill the WinCC RT process from Task Manager. Always close the project from inside WinCC Explorer or via the configured close picture button. The process model in WinCC V7.3 keeps the SQL transaction open until a controlled close is performed.
• Configure controlled UPS-backed shutdown on the OS station. An uncontrolled power loss is the single most common cause of a suspect project database.
• Do not use RDP for routine access to the OS. If remote access is required, use a console-redirection KVM (such as a hardware KVM over IP) or restrict RDP to a single named account and enforce session timeouts.
• Schedule a daily project archive via WinCC Explorer > Project > Archiving > Configure, with the archive copied off the OS to a file share. A 24-hour archive of the project allows recovery to the start of the previous day in the worst case.
• Monitor free disk space on the SQL data drive, the SQL log drive, and the OS system drive. The WinCC RT will not start cleanly if any of these fall below approximately 10% free.

When to Escalate to Siemens Support

Escalate when:

• The SQL database is in the Suspect state and DBCC CHECKDB ... REPAIR_ALLOW_DATA_LOSS cannot bring it back to Normal.
• A brand new, empty project on the OS produces the same hard-error, and the repair install (Recovery Procedure D) does not resolve it.
• Application event log repeatedly shows Event ID 1000 with Faulting module name = a WinCC binary other than CCRT.exe, indicating a deeper component fault.
• The error is intermittent (occurs on roughly 1 in 20 starts) and correlates with a Windows update or a network event.

For escalations, open a support request at the Siemens Product Support portal with the WinCC build, the Windows build, the captured event logs, the SQL error log, and the CCRT.exe crash dump. The portal also hosts the WinCC V7.3 Information System which contains the full system description, channel diagnostics, and error code reference.

Frequently Asked Questions