Resolving STEP 7 LAD/STL/FBD Editor Crashes During Block Save

Problem Description

The STEP 7 Professional 2010 LAD/STL/FBD Program Editor (the integrated block editor in SIMATIC Manager) terminates unexpectedly when the user attempts to save specific code blocks—most commonly OB1 (Organization Block, main cyclic program) and FC7 (Function, no instance DB) in the reported case. The crash is silent: no S7 exception, no Dr. Watson-style dump, no Windows error code, and no entry in the Application Event Log. The SIMATIC Manager window remains open, but the LAD/STL/FBD editor process has been killed and the in-memory block is lost. The "Save As → With Reorganization (slow)" command, which performs an internal defragmentation of the .s7p/.s7l project database, does not resolve the issue.

Environment & Affected Versions

The same symptom class has been observed on STEP 7 V5.4 SP5, V5.5, and V5.5 SP4. Because the editor is shared across these versions, the root cause is generally project-database (offline container) corruption rather than a STEP 7 binary defect.

Root Cause Analysis

A STEP 7 V5.x project is not a single file. It is a hierarchical folder tree of binary containers (Offline + Online view) with extension *.s7p at the root, *.s7l for libraries, and per-block *.awl (STL source) / *.inc (interface) pairs. The Symbols, HW Config, NetPro connection data, and the System Data (SDB) all live in their own subfolders. The Blocks folder, in particular, holds the compiled and source representations of OBs, FBs, FCs, DBs, SDBs, and SFB/SFC system blocks.

When the LAD/STL/FBD editor opens a block it reads three artefacts:

1. The compiled *.awl STL representation
2. The interface description (IN/OUT/IN_OUT/TEMP/STAT/RETURN)
3. The optional source file (if "with source" save was selected)

If any of these artefacts become inconsistent—for example, a torn write during a power loss, an antivirus quarantine of a single *.s7l subfile, a remote-share disconnect mid-flush, or an interrupted S7-PLCSIM import—the editor's internal consistency check can fail in an unrecoverable way. The save path calls SaveAs_Reorg() which writes a new block container; if the header CRC of the existing container is already bad, the reorg path also crashes. The result is a block that opens, appears valid in the working memory, but cannot be serialized back to disk.

Step-by-Step Recovery Procedure

The procedure below recovered the corrupted project in the reported case. It works by isolating the damaged container and re-creating a clean shell, then migrating the user content into it.

Prerequisites

• A working STEP 7 Professional 2010 installation with the same service pack level as the source PC
• Read/write access to the corrupted project folder (copy it to a local NTFS drive first; do not operate on a network share)
• Backups: take a zip copy of the entire *.s7p folder before any destructive step
• Optional: S7-PLCSIM for offline test of the rebuilt project

Procedure

1. Isolate the corruption. Create a new SIMATIC Manager project (File → New → Project) and a new SIMATIC 300 Station (or matching station type).
2. Build a clean hardware shell. Open HW Config and insert a rack matching the corrupted project's CPU slot, drag the same CPU (e.g. 6ES7 315-2EH14-0AB0 / CPU 315-2 PN/DP) and the same signal modules. The SDBs are regenerated automatically when HW Config is saved.
3. Copy the Blocks folder. In SIMATIC Manager, switch to the Offline view of the new project. Right-click the Blocks container → Copy. Navigate to the corrupted project's Blocks container, select all user blocks (OB1, OB100, FC1–FCn, FB1–FBn, DB1–DBn, UDTs), and Paste. System blocks (SDB, SFC, SFB) must NOT be copied; the new HW Config already produced fresh SDBs.
4. Open and re-save the suspect blocks. Double-click OB1, then File → Save. Repeat for FC7. If the new project's editor now saves the blocks cleanly, the original project's Blocks container was the corruption source.
5. Migrate HMI and Symbols. Copy the Symbols object (the global symbol table) and any WinCC flexible / HMI station objects from the corrupted project. Open OB1 once more and save to confirm the imported symbol table did not re-introduce the failure.
6. Migrate NetPro and connections. Open NetPro in the new project, re-create the configured S7 connections to match the corrupted project. Save and compile (Options → Compile and Check All).
7. Download to the controller (or PLCSIM). Use PLC → Download to test the rebuilt project end-to-end. Verify the OB1 cycle and FC7 logic execute as expected.
8. Archive the recovered project. Use File → Archive to produce a clean *.zip or *.arj backup. This forces a serial re-write of every block and is itself a "Save As Reorganization" against the whole project.

Alternative Recovery Methods

If the rebuild path is too expensive (large multi-station project, complex NetPro topology), try these in order before escalating to Siemens Support:

Network-by-Network Migration

For a single damaged block, open the block in both the corrupted and the new project side by side. In the corrupted block, right-click each network → Copy. In the new block, place the cursor at the end of the last network and Paste. Save the new block. If the new block saves, the corruption was isolated to one of the migrated networks—revert and re-paste individually to localize the bad network.

Pulling Live Content from the Controller

If the CPU is online with a working program, use PLC → Upload Station to PG on a fresh project. This rebuilds the offline tree from the controller's SDBs and blocks, bypassing the corrupt offline container entirely. Compare the uploaded project against the corrupted one with Options → Compare Blocks (Online vs. Offline, then Project vs. Project) to detect the corrupt area.

Project Reorganization Best Practices

• Always archive before debugging crashes. Use File → Archive (not the Windows ZIP shell) to produce a STEP 7-native archive. The native archiver walks the project in a defined order and skips locked/temp files; the shell ZIP can pick up half-written containers.
• Keep Sources in sync with Blocks. Generate STL source (File → Generate Source) for every block after each save. STL source is plain ASCII and far less susceptible to silent corruption than the binary compiled view. To recompile: open the source file, File → Compile.
• Avoid antivirus real-time scanning of *.s7p trees. Pattern-matching AV can quarantine or scrub *.awl files mid-write. Exclude the project root and any UNC path that hosts projects from real-time scanning. See the Siemens FAQ on antivirus compatibility for STEP 7 (entry ID 13173645) for the official exclusion list.
• Disable Windows Search Indexer on the project root. Indexer holds short-lived read handles that can collide with SIMATIC Manager's exclusive-write model.
• Use local NTFS for active editing. Network shares (SMB 1.0/2.0) introduce latency and torn-write risk. Edit locally, copy out to the share only when the project is closed in SIMATIC Manager.

Virtual Machine Considerations

Many STEP 7 V5.5 sites run inside VMware Workstation/ESXi or Hyper-V. VMs introduce three risks specific to the editor:

1. Disk-image write coalescing. VMware's *.vmem delta and snapshot consolidation can defer flushes; a host crash can leave the project's *.s7p in a torn state. Disable "Allow Windows to manage paging" inside the guest, and configure the virtual disk as Independent – Non-persistent only for disposable test rigs.
2. Time-sync skew. STEP 7 stamps block headers with the PG time-of-day. A VM that re-syncs the clock backward (e.g. after a suspend/resume) can produce negative time deltas that confuse the offline container's internal sequence counters. Configure VMware Tools with "Time synchronization between the virtual machine and the host operating system" only when the host is NTP-synchronized.
3. 3D/graphics driver mismatches. The LAD/FBD editor is a GDI-heavy application; a mismatched VMware SVGA driver can cause random editor closes that look identical to project corruption. Switch the VM's display to 16-bit color, 1024x768 as a sanity test.

Escalation Path to Siemens Support

If the rebuild path fails:

1. Open a support request via the Siemens Industry Online Support portal. Use the Support Request entry under "My Support".
2. Attach a sanitized project (strip proprietary code, retain block interfaces) in *.zip form. Per the discussion, Siemens Sweden escalated a similar case to Germany without resolution—attach the smallest reproducible project to improve turnaround.
3. Provide the STEP 7 version (Help → About in SIMATIC Manager, including Service Pack) and the OS build (winver output).
4. Generate a Windows process dump of the crashing S7EWNDEX.EXE (LAD/STL/FBD editor) using Sysinternals ProcDump with -ma -e 1 for a full dump on first-chance exceptions, and attach the *.dmp to the ticket.

Verification Checklist

After recovery, verify the rebuilt project is healthy:

• [ ] Open OB1, make a no-op change, save. Editor must close cleanly with the modified timestamp in the Blocks container.
• [ ] Open every FC, FB, DB, UDT, and re-save. Options → Check Block Consistency must report "No errors".
• [ ] PLC → Compile and Download All (with PG/PC interface set to PLCSIM or to the real CPU) must succeed.
• [ ] Options → Compare Blocks (Online vs. Offline) must show zero differences.
• [ ] File → Archive the project, then unzip to a new folder, then open in SIMATIC Manager. The unzipped project must open without errors (this exercises every container).

Troubleshooting Matrix

FAQ