Resolving CCProjectMgr.exe Crash on Siemens WinCC Engineering Station After Domain Controller Promotion

A CCProjectMgr.exe application fault that surfaces immediately after a Siemens Engineering Station (ES) is promoted to a Windows Active Directory domain controller is one of the most common breakages seen in PCS 7 / WinCC environments. The fault is rooted in a Microsoft support policy that explicitly excludes WinCC Runtime and WinCC Configuration from running on a Domain Controller role. This reference walks through identification, root cause, recovery, and verification procedures to restore WinCC Project Manager functionality without losing the underlying PCS 7 project.

1. Problem Description

Symptom: immediately after promoting a Siemens ES to a primary domain controller (PDC) and rebooting, the operator receives a Windows Application Error pop-up with the message "an internal error has occurred and the computer must be restarted". The faulting application is CCProjectMgr.exe, the WinCC Project Manager. The same error reappears whenever the WinCC component of PCS 7 is started or when an OS (Operator Station) is compiled.

The Windows Application event log records the following details:

The version string 700.2101.111.2 corresponds to WinCC V7.0 SP3 (the 700 family), Update 11. The MSVCR90.dll 9.0.30729.6161 build is the Microsoft Visual C++ 2008 SP1 Redistributable, which is required by every WinCC V7 binary.

2. Environment and Version Identification

Before any repair is attempted, gather the following facts. They are essential both for Siemens support and for matching the right fix to the right binary set.

2.1 ES Operating System

• Windows 7 32-bit / 64-bit (most common for PCS 7 V7.0 SP3)
• Windows Server 2008 R2 (sustained engineering use cases)
• Windows 10 Enterprise LTSC 2019 (where PCS 7 V9.0 SP2 or later has been qualified)

2.2 WinCC / PCS 7 Software Stack

Verify the installed WinCC version through Help > About > Installed SIMATIC software inside the WinCC Explorer, or with the CCProjectMgr.exe file properties dialog (Details tab > Product version). For broader TIA Portal / WinCC component context, see the official overview at Overview of processes and services of TIA Portal components (Siemens documentation portal, TIA V21). The same article clarifies that CCProjectMgr is the WinCC Project Manager responsible for handling the WinCC project on the ES.

3. Root Cause Analysis

The error is not a virus, malware, or random project corruption. It is the deterministic result of a single architectural decision: the ES was promoted to a domain controller role while still hosting WinCC binaries.

3.1 WinCC is Not Supported on a Domain Controller

Siemens clearly states in the WinCC / PCS 7 installation guides and readme files that the WinCC Server, WinCC Client, and WinCC Configuration (i.e. the ES) must not be installed on a computer that holds the Active Directory Domain Controller role. The reason is twofold:

1. WinCC uses local Windows accounts (CCAdmin, CCOperator, CCDiagnostic, CCExplorer, CCRunUser, CCStartSvc, CCWriteTrace) and assigns them specific user rights via the local SAM. On a domain controller, the local SAM is replaced by the Active Directory database, and the WinCC post-install permission script cannot complete.
2. Several WinCC services (CCAgent, CCEServer, CCProjectMgr, CCRuntime) expect to start under a non-DC service account with the Log on as a service right and the Deny logon locally policy. On a DC, group policy inheritance blocks these rights and the service host crashes during early initialization, which is exactly what is observed in CCProjectMgr.exe at exception code 0x40000015 (a managed/unmanaged transition fault inside the CRT startup path).

3.2 Why the Fault Surfaces in MSVCR90.dll

The faulting module is MSVCR90.dll, the C runtime. WinCC V7 SP3 was compiled with Visual Studio 2008 and statically links against the 9.0.30729.6161 CRT build. The SxS side-by-side assembly x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57 is the manifest-bound CRT that ships with VC++ 2008 SP1. When CCProjectMgr initializes, it calls into the CRT to construct C++ objects that wrap ADsSecurity and ADSI interfaces used to enumerate local groups. On a DC, those APIs return a different schema, and the wrapper code dereferences a null pointer, producing a structured exception that is delivered back to the CRT's exception filter and logged with code 0x40000015.

3.3 Why the Fault Also Appears on a Freshly Archived Copy

When the user copied the archive to a second ES and observed the same crash, it confirmed that the project database is intact. The .mdf / .ldf files, the *.pnl graphics, the alarm logs, and the S7 program are all clean. The fault is environmental: the binary cannot start on a host that has been promoted to DC. The most likely follow-on failure mode is that the OS compile still works (because STEP 7 does not require the WinCC local group stack) but the OS server start will fail, leaving the operator with a non-functional runtime.

4. Pre-Checks Before Any Repair

1. Confirm the DC role. Open Server Manager > Roles > Active Directory Domain Services. If installed, the host is a DC.
2. Confirm WinCC services. Run sc query CCProjectMgr, sc query CCAgent, sc query CCEServer, sc query CCRuntime in an elevated command prompt. Note any service that returns STOPPED with exit code 1067 (process terminated unexpectedly).
3. Confirm the local WinCC groups exist. Run net localgroup and look for CC_ADM, CC_OP, CC_DIAG, CC_USERS. On a DC these groups are usually missing because the post-install permission step silently failed.
4. Capture a Process Monitor trace. Filter on CCProjectMgr.exe and look for BUFFER OVERFLOW or NAME NOT FOUND on registry keys under HKLM\SOFTWARE\Siemens\WinCC. This is the smoking gun for a failed post-install on a DC.
5. Verify disk space, RAM, and the page file on C:\. WinCC V7 requires a minimum 1.5x of installed RAM for the page file.

5. Step-by-Step Recovery Procedure

The objective is to remove the conflict between the DC role and the WinCC installation. There are three viable paths; pick the one that matches the operational constraint.

5.1 Path A — Demote the ES from Domain Controller (Recommended)

This is the only procedure that fully restores WinCC without re-installation. It requires a second DC in the forest or a willingness to operate the engineering domain without a DC at the ES site.

1. Back up the entire ES image with a sector-based tool (e.g. wbadmin start backup or a third-party disk image).
2. Open Server Manager > AD DS > More > Remove Role. The wizard will run dcpromo /demote.
3. Reboot when prompted. The host will come back as a member server of the existing domain.
4. Re-apply the WinCC local group policy. From the WinCC installation media, run Setup\WinCC\Support\Tools\S7WinCC\CCPerm.exe (WinCC V7) or the equivalent WinCC User Admin console in newer versions. Verify all CC_* groups are recreated.
5. Re-register the WinCC services: sc config CCProjectMgr start= auto obj= "NT AUTHORITY\SYSTEM" for system-driven services and sc config CCAgent start= auto obj= "NT AUTHORITY\LOCAL SERVICE" for the agent.
6. Reboot and verify CCProjectMgr.exe starts cleanly.

5.2 Path B — Demote but Keep the Host Out of the Domain

If the project is a stand-alone engineering environment, demote the DC and remove the host from the domain entirely. WinCC does not require domain membership for the ES; it only requires a stable Computer Browser and a working local security database.

1. Run dcpromo /unattend /RemoveApplicationPartitions:{GUID} for any application partitions.
2. Reset the computer account: netdom remove %COMPUTERNAME% /domain:%USERDNSDOMAIN%.
3. Re-apply WinCC permissions as in step 4 of Path A.

5.3 Path C — Keep the DC Role and Rebuild the WinCC ES on a Separate Host

This is the conservative path for plants that must keep the DC at that location. Provision a new hardware node or a VM, install the same Windows edition, the same WinCC version, and restore the project archive.

1. Build a member server joined to the same domain as the DC.
2. Install the matching PCS 7 / WinCC version exactly as listed in 2.2.
3. Install the matching VC++ 2008 SP1 redistributable (x86, version 9.0.30729.6161). It can be redistributed from the WinCC installation media under Support\VC2005x86 or Support\VC2008x86.
4. Install the matching .NET Framework 3.5 SP1 and 4.x.
5. Open the WinCC project archive from the original ES.
6. Recompile the OS and run the OS server in simulation mode to verify round-trip behavior.

6. Project-Level Recovery: Save As with Reorganization

Once the host is no longer a DC, the project itself may still carry stale references from the DC install attempt. The following cleanup is part of the canonical Siemens recovery procedure for a project that has been opened on an unsupported host.

6.1 Save As with Reorganization in WinCC Explorer

1. Close all WinCC components on the ES.
2. Open WinCC Explorer.
3. Select the project, then File > Save As.
4. Enable the Reorganize checkbox. The reorganization step rebuilds the master database (Master.MDF) and removes orphaned records left by the failed CCProjectMgr runs.
5. Choose a new project name and path on a local NTFS volume (do not use a UNC path for the project root).
6. Click OK. The reorganization may take from minutes to several hours depending on project size.

6.2 Recompile the OS

1. Open the PCS 7 project in STEP 7.
2. Right-click the OS > Compile OS > Complete compilation.
3. Monitor the Compile OS log under <Project>\Logs\ for any WARNING or ERROR rows.
4. If the compile completes with zero errors, start the WinCC Runtime in simulation mode (the green play button in WinCC Explorer). It must come up without any pop-up.

6.3 Project Wizard Smoke Test

1. From the WinCC start menu, launch Project Wizard.
2. Create a brand-new, empty WinCC project on the local drive.
3. Compile the OS of that empty project.
4. Start the Runtime. If the empty project also fails with the same CCProjectMgr error, the host is still broken. If it succeeds, the original project is the cause and a Save As with Reorganization should be repeated.

7. Repairing the WinCC Installation

If the local groups are missing or the SxS CRT assembly is corrupted, a repair install over the existing installation is preferred over a full uninstall.

7.1 Repair the Visual C++ 2008 SP1 Redistributable

1. Download the standalone VC++ 2008 SP1 x86 redistributable from Microsoft (build 9.0.30729.6161).
2. Run vc_redist.x86.exe /repair in an elevated command prompt.
3. Confirm MSVCR90.dll version is back to 9.0.30729.6161 in C:\Windows\WinSxS\x86_microsoft.vc90.crt_*.

7.2 Repair the WinCC Installation

1. Insert or mount the original WinCC installation media matching the version (e.g. PCS 7 V7.0 SP3 Update 11).
2. Run Setup.exe and choose Modify / Repair.
3. Accept all components and let the installer re-run the post-install permission script and the SxS manifest binding.
4. Reboot and re-test CCProjectMgr.exe.

7.3 Re-register the CCProjectMgr COM Service

CCProjectMgr is implemented as a COM local server. After a repair, force a fresh registration:

cd "C:\Program Files (x86)\Siemens\WinCC\bin"
regsvr32 /u CCProjectMgr.dll
regsvr32 /i CCProjectMgr.dll
sc delete CCProjectMgr
sc create CCProjectMgr binPath= "C:\Program Files (x86)\Siemens\WinCC\bin\CCProjectMgr.exe" start= auto depend= "RPCSS\EventSystem\MSSQL$WINCC"
sc description CCProjectMgr "Siemens WinCC Project Manager"

The sc create line reinstates the service under LocalSystem and binds it to the SQL Server instance that hosts the WinCC project database. The exact instance name can be verified with sc queryex type= service | findstr MSSQL.

8. Verification

9. Troubleshooting Matrix

10. Preventive Controls for Future Deployments

• Architectural separation. Document that WinCC ES, OS, and Servers must not be co-located with the AD DS role. The WinCC and PCS 7 installation guides list this restriction in the section "Supported operating modes."
• Pre-flight check. Add a Group Policy logon script that fails if (Get-WindowsFeature AD-Domain-Services).Installed -eq $true and the host is also a known WinCC node.
• Image hardening. Build the ES from a clean image every time. Do not promote a WinCC host to DC, demote it, and continue using it as an ES without a re-image; the local SAM state is contaminated.
• Backup cadence. Run wbadmin start systemstatebackup and a full WinCC project archive on a weekly cadence. The combination is the only way to recover both the project and the OS state after a major role change.
• Service account hygiene. Create a dedicated svc-wincc domain user, grant Log on as a service and Deny interactive logon, and switch all WinCC services to that account. This isolates WinCC from any future DC promotion event.

11. When to Escalate to Siemens Support

Escalate if any of the following is true after Path A or C has been completed:

• The pop-up persists with the same 0x40000015 exception code.
• The WinCC project database refuses to attach to a fresh SQL Server instance.
• The OS compile still produces errors that are not listed in the project-specific PCS 7 readme.
• Multiple ES hosts on the same image show the same fault; the root cause is the master image.

When escalating, attach the CCProjectMgr.exe version, the WinCC readme, the oslog.txt, the last 5 MB of the Windows Application event log, and the System Information (msinfo32) report. Reference the Siemens TIA Portal processes and services reference so the support engineer can map the process to the correct component.

12. FAQ