Step 7 SIMATIC Manager Cannot Open Projects Offline

David Krause12 min read
SiemensTIA PortalTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Problem Description

When a service engineer or commissioning specialist disconnects a Windows 7 (or Windows 10/11) workstation from the office network, the SIMATIC Manager (part of the legacy STEP 7 V5.x toolchain) refuses to open any project, even when the project files are stored on the local hard disk. The SIMATIC Manager window stays empty after the user selects a project, clicks OK, and the status bar reads 0/0. Reconnecting the laptop to the LAN restores the open functionality within seconds. Once a project is opened while connected, it can subsequently be opened while disconnected — until the next reboot.

This symptom has been reproduced on STEP 7 V5.5 SP3 Hotfix 11 and STEP 7 V5.6 + SP1 (internal revision K5.6.0.1) running on Windows 7 Professional SP1 64-bit. The same pattern is reported on Windows 10 LTSC installations that have been upgraded from Windows 7 images without a clean SIMATIC Manager reinstall.

Engineering impact: A service engineer who travels to a customer site without a working VPN cannot run an online or offline project, edit an existing S7-300/S7-400 program, or back up the offline blocks. This is a hard blocker for on-site work and should be resolved before travelling.

Affected Software and Versions

Component Tested Version Status
SIMATIC Manager (STEP 7) V5.5 + SP3 + HF11 Affected
SIMATIC Manager (STEP 7) V5.6 + SP1 (K5.6.0.1) Affected
S7-PCT / S7 Distributed Safety Various Often co-installed, can inherit the issue
Windows 7 Professional SP1 64-bit — Primary reproducer
Windows 10 LTSC 2019 In-place upgrade from Win7 Secondary reproducer
Windows 11 22H2 Fresh install with STEP 7 V5.7 Generally not affected

The S7-1200/S7-1500 toolchain (TIA Portal V13/V15/V16/V17/V18) is not affected by this class of fault. The issue is specific to the legacy STEP 7 V5.x installer family, which still ships a Windows NT 4.0–era service and shell extension layer.

Root Cause Analysis

STEP 7 V5.x is a 32-bit application (WOW6432 node) that has hard-wired dependencies on three Windows-side resources that all degrade or fail when the workstation is offline:

  1. The S7ELEA and S7DOS services are installed as "manual start" in a default install. Their startup path uses the %ProgramFiles%\Siemens\Automation\Simatic Manager\s7elea.exe binary and registers itself as an event-log consumer. On machines where the Workstation service has not finished initializing because the network adapter is in a "no connection" state, S7ELEA enters a half-started state. SIMATIC Manager then refuses to enumerate offline projects because its COM object model relies on the event subscription.
  2. The temporary file resolver for the project's .s7p and .s7f files uses a path that is computed at first open and cached in %LOCALAPPDATA%\Siemens\Automation\Temp. If the Setup wizard was launched the first time over a UNC path (e.g. \\fileserver\install\STEP7) the cached prefix can include a dead UNC reference. The repair function in Add/Remove Programs cannot rewrite this prefix because the installer requires the original MSI source, which the IT department may have already cleaned up — exactly the situation described in the field case ("Repair does not work because Temporary files are cleaned").
  3. The s7hcomp.dll / s7eepa.dll COM server uses the Windows CryptoAPI certificate chain. Offline machines have no CRL reachable. The chain build fails after a default 5 s timeout. SIMATIC Manager treats the failed chain validation as a license failure and aborts the project open with no error dialog, which is why the user sees a silent 0/0 status.

After the first successful open while online, COM caches the valid certificate chain in %LOCALAPPDATA%\Microsoft\Crypto\RSA and the project can subsequently be opened offline until the cache is invalidated (e.g. reboot that clears PendingFileRenameOperations, or a Windows update that resets the CryptoAPI state).

Pre-Diagnostic Checklist

Before changing any registry, confirm the following:

  1. The project really is on the local disk. Right-click the .s7p file in Explorer → Properties → verify the Location tab shows a C:\ or D:\ path, not a \\server\share\... UNC path.
  2. Open Command Prompt → set TEMP and set TMP. Both must resolve to a local path. If either is mapped to a network share, fix this first.
  3. Open Control Panel → Network and Sharing Center → Advanced sharing settings and confirm Turn on network discovery is enabled, even when offline, otherwise the offline file cache resolution layer reports "not found" to COM. Refer to the Microsoft article on shared folder access from File Explorer for the exact control path.
  4. Verify the user has the Power User or Administrator group membership. Standard users on Windows 7 cannot write to the STEP 7 program data folder and the open silently fails.

Diagnostic Procedure

Run the following checks in order. Record the output of each before changing state.

  1. Check service state: Run services.msc, locate S7ELEA and S7DOS. Both must be Running (or at minimum S7ELEA must be Started). Note the Log On As column — it should be Local System or a dedicated S7Service account, not the interactive user.
  2. Check the binary: In %ProgramFiles%\Siemens\Automation\Simatic Manager\, confirm s7elea.exe, s7eepa.dll, and s7hcomp.dll all exist and have a non-zero size. A zero-byte file indicates a broken install.
  3. Check the event log: Open eventvwr.msc → Windows Logs → Application. Filter for Source = S7ELEA and Source = S7DOS. Look for event ID 1001 entries with a description containing 0x80070002 (file not found) or 0x80004005 (unspecified error). These are the canonical fingerprints of the offline open failure.
  4. Check the CryptoAPI cache: dir /s %LOCALAPPDATA%\Microsoft\Crypto. If the directory contains only stub folders, the certificate chain was never cached and every offline open will fail.
  5. Check third-party software: Confirm presence of RSLogix 500/5000/Studio 5000. In the field case the customer is a service engineer with Studio 5000 Logix Designer, RSLinx, and RSNetWorx installed. Rockwell software registers its own ODBC data sources and a competing license manager (FlexNet Activation Service) that conflicts with S7ELEA on the same RPCSS endpoint. Disabling Rockwell software first will determine whether it is the trigger.

Step-by-Step Solution

The repair is structured in five layers. Apply them in the order shown; each layer is independent and the procedure can stop as soon as offline open succeeds.

Layer 1 — Re-prime the S7ELEA service

  1. Open services.msc as Administrator.
  2. Right-click S7ELEA → Properties → set Startup type to Automatic (Delayed Start).
  3. Set Log On As to Local System account and tick Allow service to interact with desktop.
  4. Click Start. If the start returns Error 1053: The service did not respond to the start or control request in a timely fashion, apply Layer 2 first.
  5. Repeat for S7DOS and S7NTFLOG if present.

Layer 2 — Repair the missing temp cache

  1. Close SIMATIC Manager.
  2. Create the folder C:\ProgramData\Siemens\Automation\Temp (Windows 7 path) or %PUBLIC%\Siemens\Automation\Temp (Windows 10+).
  3. Open Registry Editor as Administrator and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Siemens\Automation\STEP7\V5.0\Application.
  4. Confirm the value (Default) points to a local path. If it points to a UNC path (e.g. \\fileserver\install\...), replace it with C:\Program Files\Siemens\Automation\.
  5. Reboot.

Layer 3 — Re-create the certificate cache

  1. Connect to the network.
  2. Launch SIMATIC Manager and open the project once.
  3. Close SIMATIC Manager.
  4. Copy the populated folder %LOCALAPPDATA%\Microsoft\Crypto\RSA to a USB stick for backup.
  5. From this point on, the project will open offline until the next major Windows update that resets CryptoAPI.

Layer 4 — Eliminate the Rockwell conflict

  1. Open appwiz.cpl and uninstall the Rockwell packages in this order: RSLogix 500/5000/Studio 5000, RSLinx Classic, RSNetWorx, FactoryTalk Activation Service.
  2. Reboot.
  3. Open SIMATIC Manager and open a local project while offline.
  4. If successful, the workstation is dedicated to Siemens work only and Rockwell can be installed in a virtual machine (Hyper-V/VMware) for the rare cross-platform job.

Layer 5 — Clean reinstall (last resort)

  1. Uninstall STEP 7 via appwiz.cpl.
  2. Delete the folders C:\Program Files\Siemens\Automation, %ProgramData%\Siemens, and %LOCALAPPDATA%\Siemens.
  3. Remove the registry keys under HKLM\SOFTWARE\Wow6432Node\Siemens and HKCU\SOFTWARE\Siemens.
  4. Run msizap from the Windows SDK against any orphan MSI GUIDs: msizap.exe T {GUID}.
  5. Reboot and install STEP 7 from a verified local copy of the install media, never a UNC path.

Windows-Side Remediation

Several Windows configuration choices silently break SIMATIC Manager offline. The following items must be set as shown before the offline open test will succeed.

Windows Item Recommended Setting Reason
Network discovery On (private profile) Allows the offline file cache layer to resolve cached project paths
Offline Files feature Enabled, with the project folder pinned Provides a local mirror of any UNC-cached references inside the project XML
%TEMP% / %TMP% Local path only (C:\Users\<user>\AppData\Local\Temp) SIMATIC Manager writes its swap and lock files there
User Account Control Default (level 2) for admins, level 1 for service engineers UAC virtualization on legacy installers silently redirects file writes
Fast User Switching Disabled Conflicts with the S7ELEA desktop interaction bit
Windows Defender real-time scan Add exclusion for %ProgramFiles%\Siemens\Automation and project folders Real-time scan delays the COM open call past the internal timeout
Credential Manager Clear stale entries for the original file server Stale NTLM creds cause a 30 s SMB timeout that masks the actual open

SIMATIC Manager Configuration

Two settings inside SIMATIC Manager reduce the surface area of the offline failure.

  1. Disable the project archive check: Options → Customize → Open/Save → uncheck "Check archive bit on open". This stops SIMATIC Manager from re-stamping the archive bit, which requires a writable share and silently fails offline.
  2. Disable online partner lookup: Options → Set PG/PC Interface → select "S7ONLINE (STEP 7) -> TCP/IP" and on the Diagnostics tab uncheck Broadcast search. Broadcast does not work across VLANs and on a fully offline machine it stalls the partner enumeration for the full 30 s TCP timeout.

Third-Party Software Conflict (Field Case)

The original field report includes a very long list of co-installed software on a service laptop:

  • TIA Portal V13 — compatible, no conflict
  • Starter (SINAMICS commissioning) — compatible, but shares the S7DOS service on newer versions, do not run both at once
  • SEW Motion Studio — does not interfere, uses its own OPC server
  • ABB Robot Studio — does not interfere, uses a separate FlexNet port
  • Cognex In-Sight / Keyence / Sick scanner software — does not interfere, but each installs a virtual network adapter that confuses the offline detection; disable the virtual adapters when travelling
  • PROFINET IO Trace / IFM IO-Link container — does not interfere
  • RSLogix 5000 / Studio 5000 / RSLinx — primary culprit; Rockwell's FactoryTalk Activation Service takes exclusive ownership of the same TCP port range (6000–6004) that S7ELEA uses for its license beacon

Confirmed in the field case: once the Rockwell stack was uninstalled, the projects opened offline without a VPN, on a fresh reboot, on the first try.

Verification

Validate the fix using this sequence. Each step must succeed before the next is attempted.

  1. Disable the network adapter (do not just unplug the cable — that leaves the NIC in "acquiring" state).
  2. Reboot.
  3. Log in. Confirm ipconfig /all shows Media State = Media disconnected.
  4. Launch SIMATIC Manager. Open a project from C:\Projects\<name>.s7p.
  5. Confirm the status bar changes from 0/0 to 1/1 and the S7 program folder appears within 5 s.
  6. Open Blocks, double-click OB1, confirm the editor opens in LAD/FBD/STL.
  7. Edit a comment, save, close the block, close the project, close SIMATIC Manager.
  8. Re-launch SIMATIC Manager and re-open the same project offline — the save state must be intact.
  9. Re-enable the network adapter and confirm online open still works against a real S7-300/S7-400 CPU.

Long-Term Mitigation

For service engineers who travel frequently with a Siemens-only or mixed-vendor laptop, the following configuration prevents the offline open failure from re-occurring.

  • Maintain a dedicated Siemens boot image on a separate partition, restored to a known baseline before each trip. STEP 7 V5.x is not designed for in-place upgrades and accumulates orphan registry keys that re-introduce the failure.
  • Run Rockwell software inside a Hyper-V Gen 2 VM with a fixed virtual switch. The host keeps a clean S7ELEA environment; the VM provides isolated access to RSLinx/Studio 5000.
  • Use a USB-Ethernet adapter as the primary Siemens network. The internal Wi-Fi can then be disabled before the offline test, eliminating the "media disconnected vs. media acquiring" ambiguity.
  • Keep a snapshot of %LOCALAPPDATA%\Microsoft\Crypto\RSA after a successful online open, and a reg export of the HKLM\SOFTWARE\Wow6432Node\Siemens tree. Restore these in under two minutes if the CryptoAPI cache is ever wiped.
  • For new projects on S7-1200/S7-1500, migrate to TIA Portal V18 or later which is offline-clean by design and is not affected by the legacy COM/CryptoAPI dependency chain.

Safety and Operational Notes

Do not edit live PLC programs offline and load the result to a running machine without a documented change request. An offline project that is older than the CPU's online version will overwrite the live program on download — this is a documented cause of unintended machine motion in commissioning incident reports.
Do not disable the S7ELEA service to "speed up" the workstation. The service is required for licensing and for the archive bit synchronization that prevents silent data loss when archiving projects to a network share.

FAQ

Why does SIMATIC Manager open the project the first time online but fail after a reboot?

The first online open populates the CryptoAPI certificate chain cache under %LOCALAPPDATA%\Microsoft\Crypto\RSA. A reboot, a Windows update, or a disk cleanup can clear this cache; without it, the COM open call cannot validate the project signature and SIMATIC Manager returns silently with status 0/0.

Is this issue specific to STEP 7 V5.5 and V5.6?

Yes. The fault is tied to the V5.x installer family and its s7eepa.dll / s7hcomp.dll COM stack. STEP 7 V5.7 with the latest hotfix and TIA Portal V13/V15/V16/V17/V18 are not affected because they use a different licensing and signature path.

Can I keep both Rockwell RSLogix and SIMATIC Manager on the same laptop?

Technically yes, but the FactoryTalk Activation Service and the S7ELEA license beacon compete for the same port range and the same COM apartment. For a service laptop that must boot into a known state quickly, the cleanest answer is to run Rockwell in a Hyper-V VM and keep the host dedicated to Siemens software.

The "Repair" button in Add/Remove Programs does not fix the issue. Why?

The Windows Installer repair requires the original MSI source files in their original location. After a disk cleanup the temporary staging folder is gone, so the repair cannot recreate the missing S7ELEA service registration. The supported remedy is a clean uninstall followed by a fresh install from a verified local copy of the install media.

Will disabling network discovery stop the offline open from working?

Yes — it can. With network discovery off, the Windows offline file cache layer returns "not found" to the COM resolver, which manifests as the same 0/0 symptom. Enable it for the current network profile as shown in the Microsoft shared folder access guide, and the offline path is restored.

Back to blog