Resolving WinCC 7.4 Project Duplicator Files Disappearing After Transfer

The SIMATIC WinCC Project Duplicator is the recommended tool for copying a WinCC V7 project from one computer to another, and for setting up a redundant WinCC server pair. In WinCC 7.4 SP1 Update 8, several field reports describe a specific failure mode: the Duplicator's progress bar advances to 100%, the target folder visibly populates with the entire project (often 1 GB or more), and then every file is silently removed the instant the Duplicator closes. The problem is reproducible against any target on the network, which rules out target hardware and points at the Duplicator's post-copy cleanup path. This article documents the root cause, the prerequisite checks Siemens documents, and a deterministic remediation procedure.

1. Problem Statement and Symptoms

Environment in the reported case:

• WinCC V7.4 SP1 Update 8 (build 7.4.0.8) on every node.
• Target computers running Windows 7 Professional and Windows 7 Ultimate, both 32-bit and 64-bit editions.
• Network: single subnet, basic router, 5 engineering stations plus one PLC. No domain controller, only a workgroup.
• Project size: approximately 1.3 GB including graphics, archives, and the project database.

Observed behaviour when launching SIMATIC > WinCC > Tools > Project Duplicator:

1. The Project Duplicator dialog accepts the source project path and the destination UNC path (for example \\TARGETPC\WinCC_Projects\MyProject).
2. The transfer progress window opens, file lists stream, and a file watcher on the target computer shows the project being written byte-for-byte to disk.
3. The progress bar reaches 100% and the Duplicator displays a success state.
4. Within the same second the Duplicator closes, every file in the destination folder vanishes. A recursive search of the target drive finds nothing. Recycle Bin is also empty. No event log entry is created by the Duplicator itself.

Manual copy (drag-and-drop, robocopy, or Windows Explorer) of the same project folder to the same destination works without any file loss. WinCC runtime, alarms, and the integrated graphic picture fetch from networked stations all continue to function. The fault is isolated to the Project Duplicator's last phase.

2. How the Project Duplicator Actually Works

Per the Siemens operating manual How to Copy a Project - WinCC V7.3, the Duplicator performs the following sequence:

1. Reads the project list from the source WinCC installation and lets the operator select the project to duplicate.
2. Establishes an SMB session to the target UNC path and validates write access.
3. Reconciles the project path on the target computer against the WinCCProjects.cfg file in the WinCC installation directory of the target.
4. Streams the project tree (graphics, scripts, archives, alarm logging, tag logging, user administration, project database files such as *.LDF and *.MDF) to the target.
5. Adjusts computer-specific entries in the duplicated project, including the computer name, the package list, the redundancy configuration, and the user list when the Duplicator is run in duplicate-as-redundant mode.
6. Cleans up temporary staging files and closes the SMB handle.

The "disappearing files" symptom is consistent with the Duplicator's post-transfer cleanup step removing a staging directory it created, but removing the wrong directory because the project path it has on record does not match the UNC path the operator typed. In workgroup environments without matching local user accounts, the Duplicator may also fall back to a hidden share, then delete that share's contents when it tears the connection down. The mechanism is identical for both standard copies and for the redundant server project duplication path.

3. Root Cause Analysis

Siemens documents the operating requirements for WinCC in a Windows network in entry FAQ 868014 - "What are the requirements for operating SIMATIC WinCC in a Windows network?". The relevant constraints that produce this exact symptom are:

3.1 Mismatched Local User Accounts on Source and Target

In a Windows workgroup (no Active Directory domain), every network share is authenticated using the local SAM database of the target computer. If the operator is logged in on the source as LabEng with password P@ss1234 and the target computer has no user LabEng defined locally, the SMB session falls back to a Guest connection. The Project Duplicator sees a successful write, but the path it stores for cleanup is the Guest-mapped path, not the path it used to write. When it issues its post-transfer deletion, the files it just wrote are removed. The operator sees the Duplicator "succeed" and then watches the files vanish.

3.2 Inconsistent Username/Password Pair Between Source and Target

Even if both accounts exist, a different password on the target causes the same Guest fallback because the SMB digest fails. The Duplicator's UI does not surface a credential prompt in WinCC 7.4 SP1, so the failure is silent.

3.3 Missing File and Folder Permissions

The Duplicator needs Full Control on the destination share, and Modify on every file inside the existing project directory if it pre-exists. The WinCC 7.4 installer typically grants SIMATIC HMI group rights on C:\WinCC_Projects; if the operator changes the destination to a non-default path, the group ACE is missing.

3.4 User Account Control (UAC) on Windows 7

On Windows 7 with UAC enabled, a process started from a non-elevated Explorer session cannot access the administrative hidden share \\TARGETPC\C$ even when the credentials are correct. The Duplicator returns a "successful" status because it tested write on a path it interpreted as the user's home folder, not the actual share. The cleanup deletes that misidentified folder.

3.5 Firewall Reverting Hidden Shares

Disabling Windows Firewall on Windows 7 does not by itself re-enable the hidden ADMIN$ share. The share must be enabled in the registry under HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters with AutoShareServer set to 1 and AutoShareWks set to 1 on workstations. The Duplicator sometimes uses these shares for staging; if they are missing, the staging path it records and later deletes does not exist, but the staging files it wrote to the visible share are removed as orphans.

3.6 Antivirus Self-Defense Locks

Several antivirus products (Symantec Endpoint Protection, McAfee VirusScan Enterprise 8.8) hold an exclusive handle on files inside the WinCC project for up to 30 seconds after write. If the Duplicator's cleanup runs during this window, the deletion appears to complete but is rolled back by the AV filter driver. The opposite can also occur: the AV quarantines the project files, then the Duplicator's cleanup deletes the empty quarantine stub. The user sees files that were there one second, then gone the next.

4. Prerequisites Before Re-running the Duplicator

Verify the following items on every node involved in the duplicate operation. None of them is optional in a workgroup environment.

5. Step-by-Step Remediation

5.1 Align User Accounts

1. On the source computer, open Control Panel > User Accounts and note the exact logon name and the computer name.
2. On the target computer, open compmgmt.msc, expand System Tools > Local Users and Groups > Users.
3. Create a user with the same logon name if missing. Set the same password, with the same case, and uncheck User must change password at next logon.
4. Add the user to the local groups Administrators and SIMATIC HMI. WinCC 7.4 SP1 creates the SIMATIC HMI group during install; if it is missing, repair the WinCC installation or add the group manually and grant it Full Control on the WinCC installation tree.
5. Log out of the target, then log in with the aligned account. Verify that net use \\[computername]\C$ from a command prompt succeeds without prompting for credentials.

5.2 Configure the Destination Path Properly

1. Create the destination folder, e.g. D:\WinCC_Projects\MyProject, before launching the Duplicator.
2. Share it as WinCC_Projects$ (hidden, dollar suffix) or as WinCC_Projects (visible). Hidden shares are recommended for production to avoid accidental access.
3. Grant the aligned user Full Control on the share and Modify on the NTFS side. Verify that an empty test file written from the source remains in the folder for at least 60 seconds; this rules out AV self-defense.

5.3 Launch the Duplicator with Correct Credentials

1. On the source computer, log in with the aligned account.
2. Open Start > All Programs > SIMATIC > WinCC > Tools > Project Duplicator. Right-click and choose "Run as administrator" even if the current user is an administrator. This avoids the UAC filtered-token problem on Windows 7.
3. Select the source project, then enter the destination UNC path exactly as \\TARGETPC\WinCC_Projects$\MyProject (or WinCC_Projects\MyProject for a visible share). Do not enter a mapped drive letter; the Duplicator resolves the UNC, but the cleanup phase uses the path it cached at session start, and mapped drives can become invalid mid-transfer.
4. Confirm the duplicate. The progress bar should run to completion; the files should now remain in the destination after the Duplicator closes.

5.4 If the Symptom Persists, Disable AV Briefly

1. Stop the antivirus real-time protection service on both source and target (e.g. net stop McShield for McAfee, net stop smc -> net stop snac -> net stop SRSVC for older Symantec).
2. Re-run the Duplicator. The expectation is a clean copy that survives the cleanup phase.
3. Re-enable AV and perform a manual scan of the destination. If the AV quarantines the project, exclude the path in the AV policy and document the exclusion.

5.5 Switch to Manual Copy as a Last Resort

If the Duplicator continues to misbehave in a specific environment, the supported alternative is:

1. Copy the entire project folder from C:\WinCC_Projects\MyProject on the source to the equivalent path on the target using robocopy /MIR /Z /MT:4 \\SOURCE\WinCC_Projects$\MyProject D:\WinCC_Projects\MyProject.
2. Open the WinCC Project Manager on the target. The project will not appear in the project list until you close and reopen the manager; this is expected behaviour for manually copied projects.
3. Use the Duplicator's Migrate option (if available in your service pack) to import the manually copied project into the project list. In WinCC 7.4 SP1 Update 8 the migration wizard is invoked by selecting the project and confirming the destination path; it will validate and re-register the project.

6. Verification

Confirm a successful duplicate with the following checks:

1. Open Windows Explorer on the target and confirm the project folder still exists, with the same size as the source (within a few MB for log file differences).
2. Launch the WinCC Project Manager on the target. The duplicated project must appear in the project list and open without any "project not found" or "invalid path" prompt.
3. If the duplicate was made for a redundant server, open the project on the target, navigate to Server Data > Redundancy, and verify that the partner server name resolves and the package list is populated. The Duplicator's redundant server duplication option adjusts these fields automatically when the run completes without cleanup errors.
4. Activate the project in simulation mode for 60 seconds and verify that the alarm and tag logging databases (under MyProject\ArchiveManager) initialize.
5. Check the Windows Event Viewer on the target under Application and Services Log > WinCC. There should be no entries with Event ID 10100 (project path not found) or 10150 (redundancy partner not reachable) immediately after the duplicate.

7. Duplicator-Specific Parameters and Limits

8. Common Failure Variants and Their Meanings

9. Field-Proven Edge Cases

9.1 Project Duplicator across Subnets

The Duplicator uses NetBIOS for computer name resolution. Across subnets, add a WINS entry or a LMHOSTS line for the target on the source, or enter the destination as an IP-based UNC path (\\10.0.0.42\WinCC_Projects$\MyProject). Without resolution, the Duplicator falls back to a default hidden share path that does not exist on the target, the write fails, and the cleanup deletes whatever partial folder the staging layer created.

9.2 Windows 7 32-bit Source to 64-bit Target

The Duplicator does not care about the source/target bitness; it copies the project tree as files. The 32-bit DLLs in the project's bin folder remain valid on the 64-bit target. The only risk is the SQL Server Express instance version: WinCC 7.4 SP1 installs SQL Server 2008 R2 Express, and the bitness must match the target's installation. The Duplicator does not change SQL instance configuration, so re-running the WinCC setup on the target with the matching SQL bitness is required before opening the duplicated project.

9.3 Duplicator and Encrypted User Administration

If the source project has the WinCC User Administrator configured with an encrypted user list (default in WinCC 7.4 SP1), the Duplicator copies the encryption key to the target. After duplication, the operator must run WinCC User Administrator on the target once to re-bind the key to the target's local user list, otherwise tag logging writes may fail with Event ID 10060 "authorisation failure" on the first archive close.

9.4 Duplicator and Path Length

Windows 7 imposes a 260-character MAX_PATH limit. Projects with deeply nested picture hierarchies can exceed this after duplication when the Duplicator prepends the UNC prefix. Symptom: write succeeds, but a path-resolution failure causes the cleanup to delete the parent folder. The fix is to shorten the destination share name (WinCC$ instead of WinCC_Projects$) or to move the project closer to the drive root.

10. Diagnostic Commands

Run these from an elevated command prompt on the source before each duplicate attempt:

net use \\[TARGET]\C$ /delete
net use \\[TARGET]\WinCC_Projects$ \\[TARGET]\WinCC_Projects$ /user:[TARGET]\[user] [password]
dir \\[TARGET]\WinCC_Projects$ /s /a | findstr "MyProject"
set PDLOG=2
"C:\Program Files (x86)\Siemens\Automation\WinCC\bin\WinCCProjectDuplicator.exe"

The set PDLOG=2 line enables the verbose log under %ProgramData%\Siemens\Automation\WinCC\ProjectDuplicator.log. Attach this log when opening a Siemens support request; it records the exact UNC the Duplicator cached and the path it removed during cleanup. Comparing these two paths identifies the misidentification that causes the disappearance symptom.

11. When to Open a Siemens Support Request

If all twelve prerequisites in section 4 are confirmed and the symptom persists across two different target computers and two different source projects, the issue may be a Duplicator defect specific to WinCC 7.4 SP1 Update 8. In that case:

1. Collect the ProjectDuplicator.log with PDLOG=2 set.
2. Collect msinfo32 reports from both source and target.
3. Open a service request at the Siemens Industry Online Support portal referencing entry 868014 and your WinCC installation version (7.4.0.8).
4. Mention the workaround: manual copy followed by WinCC Project Manager re-open, documented in the operating manual at entry 102754925.

12. Summary Checklist

• Identical local user account and password on source and target, member of Administrators and SIMATIC HMI.
• UAC handled - launch the Duplicator as administrator from an elevated command prompt.
• Hidden admin shares enabled in the registry (AutoShareServer=1, AutoShareWks=1) and reachable on port 445/TCP.
• Destination share has Full Control; NTFS permissions on the target folder grant Modify.
• AV real-time protection disabled or the project path excluded for the duration of the duplicate.
• Destination is a UNC path, not a mapped drive.
• Project Duplicator is launched with PDLOG=2 for traceability.
• After the duplicate, verify the project in WinCC Project Manager on the target and in the event log.