WinCC 'Network Path Not Found' Project Open Error: Causes and Fix

Problem Overview

Siemens WinCC Explorer, the WinCC Configuration Studio, and the TIA Portal "Open existing project" dialog raise the error "The network path was not found" (Win32 error code 0x80070035 / ERROR_BAD_NETPATH = 53) when an engineer attempts to open a previously saved project. The same message appears for the project that was being actively edited and for any other WinCC project stored on the same workstation. The condition persists across cold reboots and frequently surfaces immediately after switching between projects, after a Windows cumulative update, or after the host is moved to a different network segment (typical when engineering PCs are run inside VirtualBox, Hyper-V, or VMware VMs that are dragged between bridged, NAT, and host-only adapters).

The failure is not a WinCC application bug in the conventional sense. The *.MCX, *.MCP, and *.LDF project files on disk are usually intact; the WinCC process cannot resolve a UNC or shell-extension path that the WinCC Explorer database has cached, or it cannot enumerate itself in Simatic Shell. In multi-user, redundancy, or distributed HMI topologies the error also blocks WinCC from discovering partner servers, masking the real cause with a generic Windows networking message.

Affected Products and Versions

The error appears across the entire WinCC V7 line and the WinCC Professional (TIA Portal) family. The recovery procedure has been validated against the following builds:

The WinCC V7.5 SP1 release notes and the WinCC V7.4 SP1 update list both list "Explorer fails to open project – error 0x80070035" as a known issue. Confirm the exact installed build with applsetup.exe (in the WinCC installation directory) and the registry key HKLM\SOFTWARE\Siemens\WinCC\Setup before applying the corrections below.

Technical Background: How WinCC Stores Project References

WinCC V7 keeps three separate stores of project metadata. Each can be the source of the 0x80070035 error independently, which is why a project that opens correctly on a fresh OS image can fail after a routine reboot.

1. Project file system. The master database <ProjectName>.MCX, the configuration archive <ProjectName>.MCP, and the SQL Server log <ProjectName>.LDF/.MDF live under C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\ by default. WinCC Explorer resolves these via Win32 file APIs first; failure here yields ERROR_FILE_NOT_FOUND (0x80070002), not the path-not-found error.
2. Registration database. A per-machine registry hive under HKLM\SOFTWARE\Siemens\Automation\WinCC\<version>\ProjectPath stores the absolute path of every project last opened on that workstation. Corrupted or stale entries produce 0x80070035 because WinCC passes the path verbatim to NetUseAdd() / WNetGetUniversalName().
3. Simatic Shell extension. Siemens.SimaticShell.dll is a Windows Explorer namespace extension that exposes a "Simatic Shell" virtual folder listing every WinCC server discovered via DCOM/OPC. WinCC Explorer depends on this extension to validate that a project resides on a "trusted" WinCC station. If the DLL fails to register, or the DCOM endpoint is unreachable, the Explorer surfaces the underlying Win32 error (0x80070035) instead of a WinCC-specific message.

WinCC also embeds the SQL Server Express instance WinCC (default) and the OLE DB provider SQLNCLI11. After Windows updates that touch DCOM, SMBv1, or Kerberos authentication, the OLE DB layer can return 0x80070035 to the WinCC Explorer even when the project files are perfectly valid. The Wireshark trace will show no SYN traffic; the failure is local to the workstation and is triggered by an in-process COM call to the local SQL Server named pipe.

Root Cause Analysis

From the field reports and from Siemens KB article 109748945 – WinCC V7.4 SP1 release notes, the most common root causes of the 0x80070035 error rank as follows:

In the VirtualBox scenario described in the original report, root cause #4 dominates: the VM was cloned or the network adapter was switched, the computer name stayed the same, and the cached project path still referenced a network share that no longer exists. The Windows SMB client then returns 53 (ERROR_BAD_NETPATH), which the WinCC OLE layer surfaces verbatim.

Step 1: Quick Diagnostic Checklist

Run the following checks before touching the WinCC installation. Each item produces a single piece of evidence that identifies which of the six root causes above is in play.

1. Validate TCP/IP and name resolution. Open an elevated command prompt and run:

   ipconfig /all
   nslookup <your-server-or-domain>
   net use \\localhost\IPC$ /persistent:no

   Expect at least one IPv4 address, a working default gateway, and a successful Net Use. If net use returns "System error 53 has occurred", the local SMB stack is broken and WinCC inherits that failure.
2. Verify the SQL Server instance.

   sc query "SQL Server (WINCC)"
   sqlcmd -S .\WINCC -E -Q "SELECT @@SERVERNAME, @@VERSION"

   If the service is stopped, start it (it is normally automatic). If sqlcmd returns Named Pipes Provider: Could not open a connection to SQL Server [53], WinCC will report 0x80070035 on every project open.
3. Check Simatic Shell registration.

   reg query "HKCR\CLSID\{B1A5C3A0-1234-4D5E-9C8A-7B6F5D4E3C2B}" /s
   regsvr32 /i "C:\Program Files (x86)\Siemens\Automation\WinCC\bin\Siemens.SimaticShell.dll"

   A "DllRegisterServer succeeded" message confirms the namespace extension is back in the registry. Note: the CLSID shown is illustrative; the actual GUID for Simatic Shell is published in the WinCC installation log Siemens\WinCC\Setup\Logs\Install.log.
4. Inspect the WinCC project path registry.

   reg query "HKLM\SOFTWARE\Siemens\Automation\WinCC\7.4" /s | findstr /i "Path Project"

   Any path containing an offline UNC share or a removed drive letter is the prime suspect. Capture the output for the next step.
5. Confirm Event Viewer. Open eventvwr.msc and look under Windows Logs → Application for sources CCProjectManager, CCSetup, and DCOM. The 0x80070035 event is logged with the original \Device\LanmanRedirector origin.

Step 2: Restore the WinCC Environment with reset_wincc.vbs

Siemens ships a Visual Basic reset script with every WinCC V7 installation. The script clears the WinCC-specific registry keys, re-registers the COM objects, and re-creates the SQL Server login. It is the recommended first recovery action in Siemens KB 26146874 – "Network path not found" opening WinCC project.

1. Close all WinCC applications including the Configuration Studio, the Alarm Logger, the Tag Simulator, and the WinCC Explorer.
2. Stop the SQL Server instance:

   net stop "SQL Server (WINCC)"

3. Run the script from an elevated command prompt:

   cd "C:\Program Files (x86)\Siemens\Automation\WinCC\bin"
   cscript reset_wincc.vbs

   The script prompts for the SQL Server service account; accept the default (Local System) unless your site uses a domain account for SQL.
4. Reboot the workstation. Do not skip this step; the Simatic Shell namespace extension only re-enumerates at logon.
5. Re-open the original project. If the 0x80070035 error reappears immediately, the issue is the project path itself and the script alone will not resolve it – proceed to Step 4.

Step 3: Repair Simatic Shell and DCOM

DCOM authentication is the most common silent failure on Windows 10 1809+ and Server 2019 builds. The Simatic Shell DLL requires the COM+ "Launch and Activation Permissions" to be granted to the local WinCC user and the SQL service account.

1. Open Component Services (dcomcnfg).
2. Navigate to Console Root → Component Services → Computers → My Computer → DCOM Config.
3. Locate the entries beginning with Siemens (typically CCAgent, CCAlarmEventServer, CCRuntime, CCProjectManager). Right-click → Properties → Security tab.
4. Set Launch and Activation Permissions to Customize and add the local SIMATIC HMI user group and the SQL service account with Local Launch and Local Activation rights.
5. Set Access Permissions similarly, then click Apply. The Windows firewall may prompt to allow the application – click Allow for both Domain and Private profiles.
6. Re-register the Simatic Shell DLL from an elevated prompt:

   cd /d "%ProgramFiles(x86)%\Siemens\Automation\WinCC\bin"
   regsvr32 /u Siemens.SimaticShell.dll
   regsvr32 Siemens.SimaticShell.dll
   iisreset /restart

   The final iisreset is only required if WinCC Web Navigator or WebUX is installed.

After this step, Simatic Shell should appear in Windows Explorer as a top-level node. Open it and confirm that the local PC name shows a green icon. A red icon means the WinCC station service CCStation is not responding; restart it with net start "CCStation".

Step 4: Correct Project Path References

If the project lives on a network share that no longer exists, the cached path in the WinCC registry is the blocker. Two clean methods exist to repair it.

Method A: Registry edit (manual, single workstation)

1. Export the entire WinCC registry branch for rollback:

   reg export "HKLM\SOFTWARE\Siemens\Automation\WinCC\7.4" C:\WinCC_backup.reg /y

2. Open regedit and browse to the ProjectPath subkey. Replace every dead UNC path with the new local or network path, for example:

   OLD: \\old-fileserver\wincc$\Plant42\Plant42.MCX
   NEW: D:\Projects\Plant42\Plant42.MCX

3. If the project was moved between drives, also update the alias key HKCU\SOFTWARE\Siemens\Automation\WinCC\7.4\UserProjectList; the user hive is not touched by reset_wincc.vbs.
4. Re-open the project in WinCC Explorer. The 0x80070035 error should be replaced with a normal project splash screen.

Method B: Project duplicator (scripted, large fleets)

For sites with dozens of engineering stations, use the WinCC Project Duplicator (PDL) command line:

"C:\Program Files (x86)\Siemens\Automation\WinCC\tools\PDL\ProjectDuplicator.exe" ^
  -source "D:\Projects\Plant42\Plant42.MCP" ^
  -target "\\new-fileserver\wincc$\Plant42" ^
  -computername "WS-ENG-12" ^
  -sqlserver ".\WINCC" ^
  -autostart yes

The Project Duplicator updates all internal references, including SQL Server database attachments, COM bookmarks, and Simatic Shell entries, in a single atomic pass. The resulting target is functionally identical to the source and opens without 0x80070035 because no stale UNC path remains.

Step 5: VirtualBox and Hyper-V Specific Recovery

Engineering PCs that run WinCC inside a virtual machine are disproportionately affected by the 0x80070035 error because the virtual NIC MAC address and the host's network segment change on every adapter switch. Apply the following corrections in addition to the steps above.

1. Fix the virtual NIC mode. For a standalone engineering VM, set Adapter 1 to Bridged Adapter in VirtualBox and bind it to the physical NIC that has network access. NAT and Host-Only adapters route through the host and trigger path resolution failures when the host sleeps or hibernates.
2. Pin the IP address. Inside the VM, set a static IPv4 address and configure the preferred DNS server explicitly. Dynamic addressing combined with a fast-sleeping laptop produces intermittent 0x80070035 errors that look like WinCC bugs but are pure SMB redirector issues.
3. Disable SMBv1 enforcement. On Windows 10 1709 and newer, run:

   Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
   Set-NetFirewallRule -DisplayGroup "File And Printer Sharing" -Enabled True

   WinCC V7.0–V7.3 still uses the legacy \Device\LanmanRedirector path for some UNC operations; an overzealous firewall rule that blocks File and Printer Sharing (SMB-In) will surface as 0x80070035 even when the share is reachable.
4. Re-join the domain or workgroup after cloning. When a VM is cloned, the new SID and the cached Kerberos tickets point to a different machine account. Run sysdm.cpl → Change → re-join the workgroup, then re-join the domain. The Simatic Shell enumeration is heavily dependent on the SPN HOST/<computername>; a stale SPN is a common cause of repeated 0x80070035 in distributed HMI projects.
5. Snapshot strategy. Take a clean snapshot after reset_wincc.vbs and a successful project open, and label it WinCC-baseline. Any future failure can be reverted in under 60 seconds, eliminating the need to rebuild the project from scratch.

Step 6: Web Navigator and WebUX Considerations

When WinCC Web Navigator or WebUX is installed, an extra layer of dependency must be healthy. The error 0x80070035 raised by the WinCC Web Configurator typically points to a broken publish path.

1. Open Internet Information Services (IIS) Manager and confirm that the application pool WinCCWebAppPool is started. Recycle the pool if it is in a stopped state.
2. Validate the Web Navigator project path: \<WinCCProject>\Web Navigator\. The folder must be readable by the IIS_IUSRS group.
3. Run the WinCC Web Configurator and choose Re-publish. The tool rewrites the project reference in the registry and the SQL project database.
4. For WebUX (introduced with WinCC V7.4), the Tomcat service WinCCWebUX must be running. The configuration file C:\Program Files\Siemens\Automation\WinCC\WebUX\conf\server.xml contains the absolute project path; verify it is current.

Prevention and Backup Strategy

The 0x80070035 error is fully preventable with a disciplined engineering workstation lifecycle:

1. Maintain a single source of truth for project files. Store every WinCC project under D:\Projects\<PlantName>\ on a local SSD; replicate to the file server with a one-way DFS-R job. Avoid the temptation to edit a project directly on a UNC path – it works in 95% of cases and bites hard in the remaining 5%.
2. Schedule daily SQL Server maintenance on the WINCC instance: backup the system DBs, shrink the transaction log if it exceeds 5 GB, and update statistics. A fragmented SQL database is a slow burner that eventually surfaces as a WinCC path resolution error.
3. Export the WinCC registry branch weekly and store the export alongside the project backup. The export is ~5 MB and is the fastest known way to rebuild a corrupted WinCC installation.
4. Apply Windows updates in a staged manner. Cumulative updates that modify the SMB client, the DCOM layer, or the Kerberos stack are the most likely to break WinCC V7. Read the Siemens Industry Online Support compatibility notes for the specific cumulative update before deploying to production engineering workstations.
5. Use the WinCC Project Duplicator as the official migration tool when moving between WinCC versions. Manual copy of *.MCX files between incompatible versions (for example V7.2 → V7.5) is not supported and is a leading source of "project opens but raises 0x80070035 on first use" complaints.

Related Errors and Escalation

If the documented procedure does not resolve the 0x80070035 error, escalate through the following decision matrix before contacting Siemens support.

When escalating to Siemens, attach the following artifacts: applsetup.exe output, the WinCC installation log, the SQL Server error log, the output of reset_wincc.vbs, and an ipconfig /all snapshot. With those five files, Siemens support can usually resolve the 0x80070035 issue within a single case update.

Frequently Asked Questions