Resolving WinCC V7.4 SP1 Upd3 Project Duplicator Save As Failure

Problem Description

The SIMATIC WinCC V7.4 SP1 Update 3 Project Duplicator utility fails to produce a usable project copy. The operator selects a source project, chooses a destination path, and the procedure appears to run normally. The first progress bar advances from 0% to 100% while archive files, database fragments, graphics, scripts, and configuration files are written into the destination folder. Immediately afterwards, a second progress bar advances from 0% to 100% and the utility deletes everything it just wrote. The destination folder is left empty. No error dialog, no warning pop-up, no log entry, and no Windows event is raised. From the operator's perspective, the operation is silent and the project is lost.

This behavior has been reproduced on multiple Windows 10 engineering stations running WinCC V7.4 SP1 Upd3 and is independent of the project's size, number of pictures, archive count, or activated optional packages. The same source project duplicated successfully on an older installation with WinCC V7.4 SP1 Upd1, confirming that the regression is introduced by the Upd3 patch level rather than by the project content itself.

Affected Versions and Environment

Always verify the installed update level on the engineering station. From Start > SIMATIC > WinCC > WinCC Explorer > Help > About, confirm that the version string ends in SP1 Update 3 (or higher sub-build derived from Upd3) before applying the procedure below.

Root Cause Analysis

Internal handling of the ODBC data source name (DSN) in the Project Duplicator wizard changed after Upd1. In Upd1 and earlier, the wizard would prompt for, or auto-create, the destination project's DSN during the Save As step. In Upd3, the wizard expects the operator to have already selected a valid DSN file (the .dsn file that defines the connection to the destination SQL archive) before pressing the Save As button. When no valid DSN is pre-selected, the duplicator falls back to a non-prompting failure path: it copies the files using a temporary template, then unconditionally deletes the copy on completion, because the binding between the destination folder and a DSN entry is treated as unresolved. The deletion phase produces no warning because, from the application's point of view, the operation did not complete its DSN-binding contract and is being rolled back.

Two contributing factors increase the probability of triggering the failure:

1. Multiple active network adapters. If the engineering station has more than one enabled NIC (wired + Wi-Fi, VPN, Hyper-V virtual switch, VMware/Workstation bridge, WSL, etc.), the SQL native client can resolve the local DSN host name to a non-primary address and the DSN lookup returns a transient error. The duplicator treats that error as a DSN-binding failure and proceeds to delete.
2. SIMATIC Net version drift. A SIMATIC Net version older than the WinCC V7.4 SP1 recommended baseline can cause the same DSN resolution behavior, because parts of the WinCC DSN path are implemented through SIMATIC Net COM/DCOM interfaces.

Symptom Matrix

Solution: Pre-Bind the DSN File Before Save As

The workaround that resolves the regression is to associate the destination folder with a valid ODBC DSN before pressing the Save As button. The Duplicator will then accept the destination and complete the copy without the silent delete phase.

Step 1 - Close all WinCC processes

1. Exit WinCC Explorer and any active WinCC Runtime instance.
2. Open Task Manager > Details and confirm that CCExplorer.exe, CCRT.exe, PDuplicator.exe, and SQLAGENT.EXE are not running.
3. If a previous failed duplication left orphan processes, end them. They hold the source project file lock and will block the copy.

Step 2 - Disable all but the primary network adapter

1. Open Control Panel > Network and Sharing Center > Change adapter settings.
2. Right-click every adapter except the one used to reach the project server, the engineering network, and the SQL Server, and choose Disable.
3. Disable VPN clients, Hyper-V virtual switches, VMware/Workstation bridged networks, and WSL vEthernet adapters in particular - they have been observed to interfere with the DSN name resolution.
4. Open cmd and run ipconfig /flushdns to clear the resolver cache.

Step 3 - Create or verify the destination DSN

1. Open ODBC Data Sources (32-bit). WinCC V7.4 SP1 is a 32-bit application, so always use the 32-bit ODBC administrator: C:\Windows\SysWOW64\odbcad32.exe.
2. Select the System DSN tab.
3. If a DSN for the destination project does not exist, click Add and select SQL Server (or SQL Server Native Client 11.0). Configure it to point to the local SQL Server instance, with Windows authentication, and a default database matching the destination project.
4. Test the connection. A successful test confirms that the SQL Native Client can resolve the local hostname over the surviving network adapter.

Step 4 - Locate the .dsn file

1. Open File Explorer and navigate to the destination project folder you intend to use (for example D:\Projects\PlantA_Copy). The folder can be empty - the Duplicator will populate it.
2. The DSN file expected by the Upd3 wizard is a small text file with extension .dsn that references the ODBC entry. In a default WinCC installation, sample DSN files are stored under C:\Program Files (x86)\Siemens\Automation\WinCC\bin and under each existing project's root folder.
3. Copy an existing project's .dsn file into the destination folder, rename it to match the destination project name, and edit it with Notepad to point to the DSN created in Step 3. The DSN is a plain INI-style file with a [ODBC] section and a DSN=<name> entry.

Step 5 - Run the Project Duplicator with the pre-bound DSN

1. Launch Start > SIMATIC > WinCC > Project Duplicator as administrator.
2. Step 1: select the source project. Click Next.
3. Step 2: select the destination. Before pressing the Save As button, browse to the destination folder where the .dsn file from Step 4 is located. If the wizard exposes a file picker that filters on .dsn, select the file you just placed. If the wizard only shows a folder picker, leave the folder selected; the presence of a valid .dsn in the folder is what the Upd3 build checks.
4. Click Save As. The duplicator should now perform the copy phase and stop, leaving the destination folder populated. No second deletion progress bar should appear.

Supplementary Checks

SIMATIC Net compatibility

Verify the installed SIMATIC Net version against the WinCC V7.4 SP1 compatibility list in the SIMATIC WinCC V7.4 SP1 readme. As a general rule, install the latest SIMATIC Net version that is paired with the WinCC version. Mixing a WinCC V7.4 SP1 Upd3 installation with a SIMATIC Net from an older TIA generation (V13/V14) is a frequent cause of intermittent DSN lookups.

Antivirus exclusions

Add the source and destination project folders, the WinCC working directory C:\Program Files (x86)\Siemens\Automation\WinCC, and the SQL Server data directories to the real-time scan exclusion list of the installed antivirus product. Real-time scanning of the temporary archive MDF/LDF files during the copy phase can cause the second-phase delete to trigger as a transactional rollback.

User account and DCOM

Run the Project Duplicator as a member of the local SIMATIC HMI group with full control on the project folders. If the destination is on a UNC path, the same user must have write access and SeImpersonatePrivilege on the target machine. DCOM access must be enabled for the WinCC components - the default WinCC install configures this automatically, but locked-down corporate images sometimes reset the DCOMCNFG permissions.

Update level consistency

If the engineering station hosts multiple WinCC versions (for example a V7.3 project for legacy support and a V7.4 SP1 project for current work), confirm that the active project is the V7.4 SP1 Upd3 installation. Mixing project versions on the same station has been observed to misroute the Duplicator to the older DSN handling code path.

Alternative Project Duplication Methods

If the Project Duplicator continues to fail after applying the workaround, use one of the following manual procedures to copy the project. These are slower but bypass the affected wizard code path.

Method A - File-level copy with WinCC Explorer

1. In the source project's WinCC Explorer, select File > Copy Project. This produces a single self-contained .pck archive.
2. On the destination machine or folder, open WinCC Explorer and select File > Retrieve. Choose the .pck file and supply a new project name. WinCC rebuilds the SQL archive and DSN automatically.
3. This method is the most reliable when the destination is a different physical machine or a different SQL Server instance.

Method B - AS-OS transfer (PLC ↔ HMI)

1. If the project is associated with a STEP 7 / TIA Portal AS, use PLC > Download to Target Device or AS-OS Engineering > Transfer to push the WinCC configuration to the destination HMI station.
2. This bypasses the Project Duplicator entirely and uses the runtime-side loader.

Method C - Manual folder + DSN rebuild

1. Copy the entire source project folder (including hidden and system files) to the destination path using robocopy /MIR or xcopy /E /H /K.
2. Create a new DSN in the 32-bit ODBC administrator pointing to a new SQL database with the same logical name as the destination project.
3. Open the duplicated project in WinCC Explorer on the destination machine. The project migrator detects the missing SQL binding and re-attaches the database, prompting for the new DSN.
4. This method requires that the destination SQL Server instance is reachable and that the user has dbcreator rights.

Verification Procedure

1. Open the duplicated project in WinCC Explorer. Confirm the project name, computer name, and the list of pictures, archives, and tags match the source.
2. Start WinCC Runtime in simulation mode. The runtime should reach the configured start picture without raising system errors 1000000 to 1000999 (general project integrity range).
3. Open Tag Management and confirm the configured connections are green.
4. Open the Alarm Logging editor and confirm the message configuration loaded without "missing DLL" or "cannot open database" warnings.
5. Check the destination folder size: Get-ChildItem -Recurse | Measure-Object -Property Length -Sum in PowerShell, or right-click → Properties. The total should be within 5% of the source folder size for projects with similar archive retention.
6. Re-enable the network adapters disabled in Step 2 of the workaround, one at a time, and re-test the Duplicator on a non-production project to verify that the issue is fully resolved and that you can run with the normal multi-NIC configuration.

Troubleshooting Matrix

Best Practices to Avoid the Issue

• Always run the Project Duplicator on an engineering station that has only one active network adapter.
• Keep WinCC V7.4 SP1, SIMATIC Net, and the Automation License Manager on the same patch family.
• Always close WinCC Runtime, WinCC Explorer, and any 3rd-party OPC clients before starting the Duplicator.
• Document the destination DSN name in your project naming convention so that operators always know which .dsn file to place in the destination folder before pressing Save As.
• Use the File > Copy Project / Retrieve method for cross-station transfers; use Project Duplicator only for in-station copies where the source and destination share the same SQL Server.
• Maintain a backup of every project as a .pck archive on a separate drive. The .pck format is independent of the Project Duplicator and is the most resilient exchange format for WinCC V7.4 SP1 projects.

FAQ