Resolving the Siemens WinCC "ASO Cannot Work Correct" Project Context Error

The "No or invalid Project Context, ASO cannot work correct" dialog reported by Siemens WinCC v7.0 and later (including WinCC V11 SP2 / TIA Portal / PCS 7 OS) is one of the most common — and most misdiagnosed — runtime startup faults. The error blocks the WinCC Explorer from loading the project, prevents the OS server from going into process mode, and leaves the engineering station unable to download. In every documented case the root cause is a desynchronization between the SQL Server database name expected by the project file and the actual SQL Server database that is attached to the local instance, combined with a failed login from the internal WinCCConnect account.

This reference walks through the diagnostic procedure, three field-proven repair methods, the PCS 7 OS/ES redundancy configuration that prevents recurrence, and the Data Execution Prevention (DEP) and SIMATIC Shell parameters that influence the issue.

1. Problem Statement and Observed Symptoms

When a WinCC v7.0 project is started from the WinCC Explorer on Windows XP SP2 (or WinCC V11 SP2 on Windows 7, or PCS 7 OS on Windows Server 2008), the following error message is presented immediately after database login:

"No or invalid Project Context, ASO cannot work correct"

Secondary symptoms observed in the field:

• WinCC Explorer closes automatically after acknowledging the dialog.
• The same dialog reappears on every subsequent launch, including after reboot.
• SQL Server logs show repeated Login Failed for User 'WinCCConnect' entries (event ID 18456, severity 14, state 16 or 38).
• The project folder still contains the expected .mcp file, but two databases exist in the local SQL instance — one with the correct name, one with the letter R appended to the end (e.g. MyProject_R vs. MyProject).
• The .mcp file still references the original database name, but the database in SQL is now an orphan from a partially completed rename or detach operation.

The error is recoverable in nearly all cases. The remainder of this document details the exact path from diagnosis to verified recovery.

2. Affected Versions and Platforms

For canonical version and platform information, see the Siemens support entry on WinCC V7.x system requirements.

3. Root Cause Analysis

WinCC uses a local Microsoft SQL Server (MSDE 2000, SQL Server 2005 Express, or SQL Server 2008/2012/2014/2016 depending on version) as its configuration and archive backend. The internal account WinCCConnect is created at installation time with a fixed password and is granted the db_owner role on every WinCC project database. The project's .mcp file contains an XML description that includes a line similar to the following:

<computer name>\\<project path>\<project name>.mdf<database name here>

When WinCC Explorer is launched it:

1. Parses the .mcp file and reads the expected <database name> string.
2. Opens an ODBC/OLE-DB connection as WinCCConnect.
3. Issues a USE <database name> to set the default database context for the session.

If the database named in step 3 does not exist (because a previous rename, detach, or copy operation only completed half the steps), the login attempt fails. SQL Server records the failure as event ID 18456 in the SQL log, with the reason being "Cannot open default database" rather than "Invalid password". WinCC treats the failed login as a missing project context and surfaces the ASO dialog.

This explains why:

• The WinCCConnect password is unchanged — the credentials are valid.
• A "phantom" _R database remains attached — that was the rename target from a partial operation.
• No amount of password reset or service restart resolves the issue — the project is asking for a database that no longer exists.

4. Diagnostic Procedure

Before any repair, confirm the root cause using the steps below.

1. Capture the SQL Server log. Open Microsoft SQL Server Management Studio (SSMS), connect to the local WinCC instance (typically \\.\WinCC for V7.x, or the named instance installed by the WinCC setup), expand Management > SQL Server Logs, and open the Current log. Filter for "WinCCConnect".
2. Note the failure reason. A typical entry is:

   Login failed for user 'WinCCConnect'. Reason: Failed to open the explicitly specified database 'MyProject'. [CLIENT: <local>]

3. Read the expected DB name from the project file. Open the .mcp file in the project root with Notepad and locate the Database= attribute (or the XML element carrying the MDF path).
4. List attached databases. In SSMS, expand Databases. Compare the names against the .mcp reference. The two-name pattern (MyProject and MyProject_R) is the diagnostic signature of a partial rename.
5. Check the Windows event log. Look for Application errors from CCWriteArchive, CCAlgRt, or PDLRT referencing the same project name, since the same database is reused by the runtime components.

5. Solution A — Repair via SQL Server Management Studio Reattach

This is the most direct method and is the preferred fix when both the MyProject and MyProject_R databases are present but the .mcp references one that is not attached.

1. Close WinCC Explorer and stop the SQL Server (WINCC) service from services.msc.
2. In SSMS, expand Databases, right-click the orphaned database (the one whose name does not match the .mcp reference), and choose Tasks > Detach. Tick Drop Connections and confirm.
3. Note the physical .mdf and .ldf paths shown in the detach dialog (typically C:\Program Files\Microsoft SQL Server\MSSQL$x.WINCC\MSSQL\DATA\<ProjectName>.mdf).
4. Right-click Databases and choose Attach…. Click Add, navigate to the .mdf file, and ensure the Attach As column contains the exact name expected by the .mcp file (case-sensitive on case-sensitive SQL collations).
5. Click OK to attach. Verify the database appears in the tree.
6. Restart the SQL Server (WINCC) service.
7. Launch WinCC Explorer and open the project. The ASO dialog should no longer appear.

If you prefer a less invasive operation, use sp_renamedb on the attached database to rename it to the name expected by the .mcp file:

USE master;
GO
ALTER DATABASE [MyProject_R] MODIFY NAME = [MyProject];
GO

This is functionally equivalent to the detach/attach method and avoids touching the physical files.

6. Solution B — Project Rename Procedure

When the on-disk .mdf is corrupt or has been deleted, perform a project rename. This is the technique Siemens support agents typically use on V7.0 cases where the database cannot be salvaged.

1. Stop the SQL Server (WINCC) service.
2. Copy the entire project folder to a new path (e.g. D:\WinCCProjects\MyProject_v2).
3. Rename the original folder to a temporary name (e.g. MyProject_old).
4. Start WinCC Explorer, browse to the new folder, and open the project. WinCC will detect the missing database in the .mcp and create a fresh SQL database with the new path's database name.
5. Deactivate the project, close WinCC Explorer.
6. Delete the renamed original folder. The new project is now self-consistent.

7. Solution C — Clean Folder Recreation (WinCC V11 SP2 and TIA Portal)

On TIA Portal based WinCC (V11 SP2 onward) the symptom presents as "Cannot find the .MCX file" after restart, even when the project runs correctly immediately after download. Field experience indicates a stray project shadow file is the cause.

1. Close TIA Portal completely.
2. Stop the SIMATIC WinCC Runtime service.
3. Delete the project folder entirely (e.g. C:\WinCCProjects\MyProject).
4. Delete the parent folder WinCCProjects (note the trailing s).
5. Recreate the parent as WinCCProject (singular, no trailing s).
6. Re-download the project from the engineering station.
7. Reboot the operator station and verify the .MCX is found on cold start.

The folder-name change is a documented workaround for a name-comparison bug in the TIA Portal runtime loader where the trailing s caused a mis-match on cold start.

8. PCS 7 OS / ES Specific Considerations

On PCS 7 the ASO error rarely appears in isolation. After successful project download from the Engineering Station (ES) to the Operator Station (OS) and its standby partner, a second error frequently surfaces:

"The user does not have the rights to perform this action! Please check the assignment of the current user of the user groups in Windows."

This appears even when the logged-on user is a local administrator and a member of SIMATIC HMI, SIMATIC NET, and WinCC Administrators. The root cause is mismatched service accounts across the redundant OS pair. Apply the configuration matrix below.

Additional guidance is available in the Siemens PCS 7 OS configuration FAQ and the SIMATIC Shell parameter reference.

9. Network, Authentication, and SQL Login Sizing

When the SQL Server is installed on a dedicated OS server and archives are written to a separate path, the following sizing rules apply to keep WinCCConnect logins fast enough that a slow login does not masquerade as a context error.

For a 1,000-tag archive with 1-second change rate, the database will grow approximately 8.6 GB per day. Verify the disk hosting MyProject.mdf has at least 30 days of free space: Free_GB >= 8.6 × 30 = 258 GB. For 5,000 tags, multiply by five.

10. Data Execution Prevention (DEP) and Service Hardening

DEP misconfiguration is the second most common contributor to the ASO error on 64-bit Windows. The WinCC runtime loads unsigned SQL stored procedures from the project database; if DEP is set to "Turn on DEP for all programs and services except those I select", WinCC terminates abnormally during project load, leaving the database in the half-attached state that triggers the ASO dialog on the next launch.

1. Open System Properties → Advanced → Performance Settings → Data Execution Prevention.
2. Select "Turn on DEP for essential Windows programs and services only".
3. Reboot.
4. Re-test the project load.

For Windows Server 2008 and later, the same setting is available through bcdedit /set nx OptIn followed by a reboot.

11. Verification Procedure

After applying any of the three repair methods, perform the following checks in order:

1. Launch WinCC Explorer. The ASO dialog must not appear.
2. Open the project. The status bar should display Project active.
3. Start Runtime. Confirm the process images load and tag values update.
4. In SSMS, confirm the database is attached and the dbo.PDE#TAGs table contains rows (query: SELECT COUNT(*) FROM [MyProject].dbo.PDE#TAGs).
5. Stop and restart the OS server. The project must cold-start without the ASO dialog.
6. Repeat the SQL log review. No new Login Failed for User 'WinCCConnect' entries should appear.

12. Preventive Best Practices

• Stop the WinCC SQL service before any project rename, copy, or backup-restore operation. The service is named SQL Server (WINCC) for V7.x and SQL Server (MSSQLSERVER) for V11+ if WinCC was installed as default instance.
• Always perform project duplication via WinCC Explorer's Project Duplicator rather than file copy. The duplicator handles MDF/LDF reattachment and the WinCCConnect mapping in one transaction.
• Document the project-database mapping in the project sub-folder using a README_DB.txt file containing the SQL database name, MDF path, and LDF path. This is invaluable when field service is dispatched without remote access to the engineering environment.
• Schedule daily database integrity checks with DBCC CHECKDB ('MyProject') WITH NO_INFOMSGS and log to a file. Catch corruption before it manifests as an ASO error.
• Apply the latest WinCC Service Pack for your version. SP3 and later contain fixes for the partial-rename race condition. See the WinCC V7.4 SP3 update notes for the full list.
• Maintain identical local administrator credentials on every ES, OS, and OS_standby station to avoid the secondary "user does not have rights" error documented in Section 8.

13. Troubleshooting Matrix