Fixing WinCC v7.0 SP3 Update 1 Cannot Open or Create Project

1. Problem Description

A reproducible failure pattern is reported on a single HP laptop running Windows 7 Professional where Siemens WinCC V7.0 SP3 base installation behaves normally (projects can be created, opened, edited, and activated) but the moment WinCC V7.0 SP3 Update 1 is installed on top, every project operation is blocked. The WinCC Explorer either refuses to open an existing *.mcp project, fails to create a new project through the New Project dialog, or terminates with an unhandled exception referencing the underlying SQL Server instance.

The behavior is independent of network connectivity, the floating or single licensing model used, the presence of STEP 7 Professional 2010 SR1 / V13 Combo, or the installation media origin (the failure has been reproduced with multiple original DVDs). The fault is also not tied to a corrupt project file: brand-new project creation triggers the same error chain.

This symptom is documented by Siemens as a known compatibility issue affecting the early Update 1 refresh of WinCC V7.0 SP3 and is resolved by moving to a cumulative update release. The remaining sections of this article describe the verification path, the root-cause candidates, the official resolution path, and the diagnostic procedure to escalate to Siemens Technical Support if a custom environment blocks the standard fix.

2. Affected Environment

3. Root Cause Analysis

WinCC V7.0 SP3 Update 1 was published as a full setup DVD image that re-applies the original release metadata of SP3 alongside the first patch. On certain Windows 7 OEM images (notably HP ProBook / EliteBook SKUs that ship with HP ProtectTools, the HP SoftPaq driver repository, and pre-installed application identity services), the update installer rewrites the ACLs of the WinCC project tree in %ProgramFiles(x86)%\Siemens\Automation\WinCC\bin and the project sub-folders under ..\WinCCProjects\. The new ACL drops the SIMATIC HMI group and the Siemens TIA Engineer group in favor of NT SERVICE\TrustedInstaller ownership, which the WinCC Explorer Runtime cannot impersonate during project open.

Three interacting fault lines are observed in the field:

1. Service account ACL regression. The Update 1 installer resets permissions on bin, library, WScripts, and the SQL data directory. The runtime then fails to enumerate COM components and project files.
2. SQL Server authentication drift. The internal CC_<Computername>_<Timestamp> database cannot be created because the SQL service account loses the dbcreator role on the named instance, triggering WinCC error text "WinCC cannot start up the SQL Server" or "Database cannot be created".
3. TCP/IP and ALM service handshake. The Automation License Manager service (ALM) attempts to bind to a port blocked by the HP OEM firewall profile, which in turn blocks the WinCC startup DLL CCLicense.dll from completing its 30-second initialization. Projects then fail to open with a generic "WinCC Explorer has stopped working" message.

The combination of the three is what makes this failure mode resistant to single-knob fixes such as re-installing the base SP3 or running SimaticRights.exe in isolation. A coordinated fix is required.

4. Pre-Diagnostic Verification

Run the following checks before changing anything on the system. They confirm whether the failure is the documented Update 1 regression or a parallel fault on a clean SP3 base.

1. Open Control Panel → Programs and Features and record the exact build string of every WinCC entry, including Hotfix and Update suffixes. The list must include SIMATIC WinCC V7.0 SP3, SIMATIC WinCC V7.0 SP3 Update 1 (or higher), SIMATIC WinCC Runtime, and the SQL Server 2008 R2 instance. Cross-reference against the official "Installed WinCC components" list described in the Update 8 release note (Entry ID 109741127).
2. From an elevated command prompt, run sc query "ALM" and sc query "WinCCAgent". Both services must report STATE : 4 RUNNING. A stopped ALM is the single most common cause of the "cannot open project" symptom in Update 1 environments.
3. From an elevated prompt, run netstat -ano | findstr :4410. Port 4410 is the ALM default. If the port is not bound, the licensing layer will fail during project open.
4. Open SQL Server Configuration Manager on the laptop and verify that SQL Server (WINCC) and SQL Server Agent (WINCC) are running and that TCP/IP protocol is enabled on the named instance. Update 1 has been observed to disable TCP/IP on the WinCC instance after a Repair operation.
5. From a separate Windows 7 machine with the same WinCC build and the same project, open the project over the network. If the second machine opens it cleanly, the project files are healthy and the problem is local to the laptop.

5. Step-by-Step Resolution

Apply the steps below in the order shown. Each step has a verification action at the end. Stop and escalate to Siemens Support if any step worsens the situation.

Step 5.1 – Capture a clean diagnostic snapshot

Before any modification, generate a WinCC diagnostic bundle. The official SIMATIC WinCC / WinCC Explorer / PCS 7 diagnostic tool (Entry ID 65976201) collects registry hives, project tree ACLs, SQL Server logs, ALM logs, and the Windows event log into a single *.zip. Save the bundle to a USB key so it is preserved across re-installs.

Step 5.2 – Reset service and user group membership

1. Open compmgmt.msc → Local Users and Groups → Groups.
2. Confirm the current user is a direct member of SIMATIC HMI, SIMATIC NET, and Siemens TIA Engineer. The SimaticRights.exe tool from the WinCC installation media adds the current user to all three groups only if executed as Administrator with UAC fully elevated (right-click → Run as administrator, confirm the consent dialog).
3. Add the user to Power Users only if STEP 7 V13 is co-installed. The SIMATIC NET group must have Modify rights on %ProgramFiles(x86)%\Siemens\Automation; SimaticRights.exe will grant this.
4. Reboot and re-test project open before continuing.

Step 5.3 – Repair the project folder ACLs

1. Open Windows Explorer, navigate to the project root (default C:\WinCCProjects).
2. Right-click the project root → Properties → Security → Advanced.
3. Enable Replace all child object permissions with inheritable permissions from this object.
4. Add an explicit SIMATIC HMI entry with Modify, Read & Execute, and Write. Add SYSTEM, Administrators, and the current user with Full Control.
5. Uncheck Allow inheritable permissions from the parent… only if Windows reports a TrustedInstaller lock; re-apply the ACE list above after the uncheck.
6. Verify with icacls "C:\WinCCProjects\<ProjectName>" /T /C in an elevated prompt. The output must list the BUILTIN groups with at least (M) modify rights.

Step 5.4 – Re-arm the SQL Server WinCC instance

1. Open SQL Server Management Studio as Administrator and connect to the named instance WINCC using Windows authentication.
2. Expand Security → Logins. Verify that NT AUTHORITY\SYSTEM, BUILTIN\Administrators, and the current domain/laptop user are all present.
3. Right-click the login of the current user → Properties → Server Roles and tick dbcreator, processadmin, and sysadmin (sysadmin only on a single-user engineering station).
4. If the WinCC instance is not visible in Management Studio, run sqllocaldb info and sc query mssql$wincc from an elevated prompt. Re-register the instance with sqlcmd -S .\WINCC -E -Q "SELECT @@VERSION".
5. Restart the SQL service: net stop "SQL Server (WINCC)" & net start "SQL Server (WINCC)".

Step 5.5 – Restore ALM and the TCP/IP stack

1. Stop the ALM service: net stop "ALM".
2. Reset the ALM license cache by deleting %ProgramData%\Siemens\Automation\ALM\LicenseCache\*.bin while the service is stopped.
3. Re-register the ALM COM components: navigate to %ProgramFiles(x86)%\Siemens\Automation\ALM\bin and run regsvr32 /u ALMService.dll followed by regsvr32 ALMService.dll.
4. Reset the Winsock and TCP/IP stack: netsh winsock reset and netsh int ip reset. Reboot.
5. After the reboot, run netstat -ano | findstr :4410. The ALM should now bind to 4410.

Step 5.6 – Apply the cumulative WinCC update path

The official, supported resolution is to leave the failing Update 1 and move forward to the latest cumulative update. The full setup DVD for Update 1 must be uninstalled first, otherwise the update chain will refuse to install.

1. Open Control Panel → Programs and Features, uninstall SIMATIC WinCC V7.0 SP3 Update 1 and the matching Runtime/Configuration Update 1 entry. Reboot.
2. Confirm the base SIMATIC WinCC V7.0 SP3 is still installed.
3. Install the latest cumulative update. Per the Siemens Update 8 release note (Entry ID 109741127), Update 8 supersedes all intermediate refreshes and includes Update 1 through Update 7 plus every published Hotfix for V7.0 SP3.
4. Run SimaticRights.exe from the new update media as Administrator.
5. Reboot and proceed to the verification section.

6. Licensing and Co-Installation Considerations

The reported environment includes STEP 7 Professional 2010 SR1 (V13 Combo) as a floating license on the same machine. Three rules must be respected to keep both products stable:

7. WinCC Project Error Code Mapping

When WinCC Explorer refuses to open a project, it writes to <ProjectName>\<ComputerName>\<ComputerName>.log. The following text fragments are the reliable field indicators:

8. Network and TCP/IP Stack Checks

Update 1 attempts to enumerate the local TCP/IP stack on first run. If the Winsock catalog is corrupted (frequently observed on Windows 7 OEM images with aggressive cleanup utilities), the enumeration hangs for 30 seconds and then the project open call times out. Use the procedure below to confirm the stack is healthy.

1. Open an elevated prompt and run netsh winsock show catalog > C:\winsock_pre.txt.
2. Run netsh int ip show config > C:\ip_pre.txt.
3. Run netsh winsock reset and netsh int ip reset. Reboot.
4. After the reboot, repeat steps 1 and 2. The winsock_pre.txt and winsock_post.txt outputs should differ only in the reset timestamp; the LSP chain must be identical.
5. If the WinCC Explorer can now create a new project but cannot open an existing one, the issue is the ALM handshake rather than the Winsock stack. Continue with Step 5.5.

9. Application Event Log Correlation

Open eventvwr.msc and filter the Application log for sources WinCC, CCLicense, ALM, MSSQL$WINCC, and SQLAgent$WINCC. The following event IDs are the field-validated fingerprints for the Update 1 failure:

10. Diagnostic Data Collection and Escalation

If the steps above do not produce a working WinCC Explorer, the next step is a Siemens Technical Support service request. The diagnostic tool referenced below generates the artifact set that Support expects.

1. Download and run the SIMATIC WinCC / WinCC Explorer / PCS 7 diagnostic tool (Entry ID 65976201) as Administrator.
2. Accept the default collection scope (registry, WinCC project tree, SQL Server logs, ALM logs, Windows event log, and driver inventory).
3. Reproduce the failure once: attempt to open the failing project. The tool will capture the exact stack trace.
4. Save the resulting *.zip bundle. Open a Support Request at the Siemens Industry Online Support portal and attach the bundle plus a description of every step from Section 5 that was already attempted.

11. Verification

After the cumulative update is installed, run the following end-to-end test before returning the system to the user.

1. Log in as the engineering user (do not test with the Administrator account; the test is only valid for the constrained user context).
2. Open WinCC Explorer from the Start menu — not from a shortcut. Confirm the splash screen shows the build string of the installed update (for example V7.0 SP3 Update 8 (1317)).
3. Create a new project named VerifyProject. Confirm the WinCC Explorer creates the project tree, the SQL CC_… database, and the initial GraCS folder.
4. Open the original failing project. Confirm all pictures, tag tables, and archives load.
5. Activate the project in Runtime for 60 seconds, then deactivate. Confirm zero entries with E severity in the alarm log.
6. Stop and restart the ALM service while the project is open. The project must remain open; if it closes, the ALM handshake is still broken and Step 5.5 must be repeated.
7. Reboot and re-test steps 3 through 5. A fault that survives a reboot indicates a persistent ACL problem that the cumulative update cannot correct and must be escalated.

12. Prevention and Field-Ready Checklist

The pattern above is consistent across multiple WinCC V7.0 SP3 Update 1 deployments on Windows 7. The following checklist, applied at image-build time, prevents the failure from appearing in new installations.

• Always install the latest cumulative update (Update 8 at the time of writing) rather than any intermediate refresh. The cumulative update is itself a full setup DVD, not an in-place patch.
• On the engineering image, run SimaticRights.exe from the cumulative update media and not from the base SP3 media. The two tools differ in the group set they add (the cumulative variant adds Siemens TIA Engineer).
• Add the engineering user to SIMATIC HMI before the first project creation. Re-applying the group later does not retroactively fix the ACL of existing project trees.
• Reserve port 4410 in the Windows firewall rule set for ALM. Document this in the image build script.
• Pin the WinCC service account (typically LocalSystem) to a fixed SID and do not rename the computer after WinCC is installed. The internal CC_<Computername>_… database name is bound to the computer name; a rename silently breaks it.
• Capture a baseline icacls %ProgramFiles(x86)%\Siemens /save C:\SiemensACL.txt output. A diff against the baseline after any patch is the fastest way to detect an ACL regression.