1. Problem Overview
Siemens SIMATIC STEP 7 V5.5 SP4 (Classic, the predecessor to TIA Portal) is widely deployed on engineering workstations that maintain legacy S7-300, S7-400, and C7 projects. A recurring field complaint reports that when the same archived project is opened on one workstation the Program blocks folder is fully populated (OBs, FBs, FCs, DBs, UDTs, system data), but on another workstation the folder renders as empty even though the Sources subfolder shows the expected STL/SCL source files.
The behavior is not random project corruption. The container file is intact; only the offline view of compiled block objects fails to materialise. The most common trigger is a missing or mis-matched Hardware Support Package (HSP) on the affected workstation, combined with the 32-bit/64-bit divergence of Windows 7 between the two machines. The mismatch prevents the block containers from being deserialised into the SIMATIC Manager tree.
2. Symptoms and Field Conditions
The following conditions have been verified across multiple engineering workstations in the field:
- SIMATIC Manager launches without error and the project opens in the component view.
- The S7 Program node expands normally, but the Program blocks container is empty or shows only system data (SDB).
- The Sources container under the same S7 Program shows all STL/SCL/Graph sources correctly.
- The same project opened on a second workstation shows every block without any intervention.
- CPU type symbols (e.g., CPU 315-2 PN/DP) may be rendered as a generic icon or a yellow question mark in the hardware configuration.
- No error is logged in the Windows Application log unless the user attempts to recompile the empty folder.
3. Root Cause Analysis
Three independent root causes have been reproduced in lab and field conditions. They may co-exist, so the diagnostic procedure below tests all three sequentially.
| Cause | Mechanism | Indicator |
|---|---|---|
| Missing/incorrect Hardware Support Package (HSP) | The hardwarecatalog object cannot resolve the CPU family used in the project; the block container renderer depends on the same catalog resolver at project-open time. |
Yellow question-mark icon on PLC station; no blocks; Sources folder intact. |
| Project database deserialisation failure on 64-bit OS | STEP 7 V5.5 was originally built for Windows XP/32-bit. Registry pointers and the S7HK COM container handle behave differently under WOW64, occasionally producing a partially hydrated project tree. |
Problem only on Win7 x64; project opens correctly on Win7 x86 or on the same machine after repair install. |
| Fragmented offline view (slow reorganisation required) | Repeated online/offline sync, large global DB count, or interrupted save can leave the project file in a state where the block view is logically present but indexed incorrectly. | Archive/restore on the same machine restores the block view; the same archive opens fine elsewhere. |
4. Prerequisites for Recovery
Before starting the procedure, gather the following on the affected workstation:
- Original STEP 7 V5.5 installation DVD (or ISO) with Service Pack 4.
- The latest Hardware Support Package (HSP) for V5.5 from the Siemens Industry Online Support portal. As of the latest HSP roll-up, the archive is delivered as
HSP_V5.5_SPxxx.zipand is installed via the Hardware Support Package tool from the STEP 7 program group. - Local administrator account on the workstation (required for the S7EHK COM service and the registry write under
HKLM\SOFTWARE\Siemens\Automation). - A working project archive (
.zip) created on the working workstation, to be used for cross-validation.
5. Step-by-Step Diagnostic and Recovery Procedure
5.1 Validate the project is not the cause
- On the working workstation, open SIMATIC Manager and select File → Archive.
- Save the project as a
.ziparchive. STEP 7 archives are lossless; any working project will round-trip identically. - Transfer the
.zipto the affected workstation and File → Retrieve. - Open the retrieved project. If the block folder is now populated, the original project file was corrupted in transit or storage, and no install action is required. Proceed to 5.5 for reorganisation.
5.2 Check SIMATIC Manager view filters
- In SIMATIC Manager, select View → Filter.
- Confirm All objects is selected and that no checkbox under Block folders is hidden.
- If a custom filter set is active, click Default and re-open the project.
5.3 Install the matching Hardware Support Package
- Close SIMATIC Manager and the S7DOS Help service.
- Start → SIMATIC → STEP 7 → Hardware Support Package.
- Click Install and select the
HSP_V5.5_SP*.ziparchive. - After install, start → SIMATIC → STEP 7 → Hardware Support Package → Hardware Service Config Manager.
- Click Check for Updates. If a newer HSP is published (Siemens releases these periodically without bundling a new SP), apply it now.
- Restart the workstation.
HKLM\SOFTWARE\Siemens\Automation\HWConfig\Catalog and to %ProgramFiles%\Siemens\Automation\HWConfig\Catalog. Both 32-bit and 64-bit shells must point to the same catalog directory; verify the WOW64 redirection is not masking a write to SysWOW64 instead of System32.5.4 Repair the STEP 7 installation
- Insert or mount the STEP 7 V5.5 DVD.
- From the root of the DVD (or autorun), run
Setup.exe. - The installer detects the existing installation. Select Repair.
- Allow the repair to complete; it rewrites the SIMATIC Manager shell extensions, the
S7EHKservice, and the COM typelib registrations that the offline view depends on. - Apply Service Pack 4 again if the repair reverts the SP.
- Reboot before re-opening the project.
5.5 Force a slow project reorganisation
- Open the project in SIMATIC Manager.
- Select File → Save As.
- Browse to a new directory. The dialog offers With reorganisation (slow) and With reorganisation (fast). Select With reorganisation (slow).
- Reopen the newly saved project. The block container is re-indexed against the project database, which clears most deserialisation artifacts introduced by online/offline sync drift.
5.6 Re-import blocks from Sources if all else fails
- Open the Sources folder.
- Select all STL/SCL sources, right-click and choose Compile (or Generate blocks from source).
- Confirm the generated OBs/FBs/FCs/DBs land in Program blocks. This confirms the project is repairable from the source-of-truth files; the original block containers were the loss, not the logic.
6. Verification Procedure
After each fix attempt, validate the recovery against the checklist below. Do not declare the workstation healthy until all six checks pass.
| # | Check | Pass Criterion |
|---|---|---|
| 1 | Open the project from a clean SIMATIC Manager session. | No W#16#8xxx warning in the dialog. |
| 2 | Expand S7 Program → Program blocks. | All OBs (1, 35, 100, 121, 122...), FBs, FCs, instance DBs, and global DBs are listed. |
| 3 | Open HW Config and double-click the CPU. | CPU icon is the proper Siemens type, not a yellow question mark. |
| 4 | Right-click Program blocks → Consistency Check. | Returns No errors or only documented warnings. |
| 5 | Compile the entire S7 program (Edit → Compile All). | Compile completes with no fatal errors. |
| 6 | Compare offline/online against the target PLC if available. | Block timestamps match the project; no DIFFERENT markers on critical blocks. |
7. Why the 32-bit vs 64-bit Mismatch Matters
STEP 7 V5.5 was originally certified for Windows XP and Windows 7 32-bit. The 64-bit install is officially supported but routes all COM calls through WOW64. Two distinct effects break the project view on x64:
- The
S7EHKservice writes catalog pointers into the 64-bit registry hive (HKLM\SOFTWARE\Wow6432Node\Siemens\Automation), but the SIMATIC Manager shell reads from the 32-bit-aware alias. If an HSP installer runs in elevated mode it can write to the wrong hive on a locked-down workstation. - Large global DBs (above 32 KB) cross the WOW64 shared-memory threshold and require the OLE container to allocate a separate buffer. A partial allocation presents as an empty Program blocks view because the container object is rejected by the tree builder.
Running the Repair install regenerates the WOW64-aware COM proxies, which is why it consistently resolves the issue after the HSP has been applied.
8. Common False Paths
Engineers routinely lose time on the following dead ends. Document them in your maintenance log to avoid repeat diagnoses.
| Action Attempted | Why It Does Not Fix the Issue |
|---|---|
| Reinstalling STEP 7 without SP4 | V5.5 base is not binary-compatible with V5.5 SP4 catalog and the COM container. The reinstall re-introduces the same bug. |
| Copying the project folder across machines | Project is a multi-file set. Partial copy silently breaks the container linkage; always transfer via the STEP 7 archive mechanism. |
Editing the .s7p file by hand |
The project file is a non-ASCII link file. Manual edits corrupt the catalog references. |
| Deleting the Sources folder to force a recompile | Removes the only recoverable form of the logic. Always re-compile from sources, never delete them. |
| Lowering UAC to never notify | UAC off does not fix COM/WOW64; it can actually make the symptom worse because the HSP installer no longer elevates into the correct hive. |
9. Preventive Maintenance for Engineering Workstations
- Maintain a golden workstation image with V5.5 SP4 plus the latest HSP roll-up. Image the disk before any project archival is taken on the road.
- Document the exact HSP build in
%ProgramFiles%\Siemens\Automation\HWConfig\HSPInfo.txtand keep the file in the project folder for traceability. - Use the With reorganisation (slow) save once per quarter on active projects to keep the offline view index healthy.
- Always archive projects with File → Archive before transferring to another workstation or version control system. Never copy the project directory.
- Match the Windows version across engineering workstations. A mixed x86/x64 fleet is the single biggest predictor of this fault.
10. Related Issues and Adjacent Diagnostics
The empty-blocks symptom often appears alongside other V5.5 anomalies. A short reference table follows.
| Symptom | Likely Companion Cause | First Action |
|---|---|---|
| Yellow question mark on PLC station | Missing HSP for that CPU family | Run Hardware Support Package installer |
| Blocks present, but online comparison shows different on every DB | Drift between offline and online after partial download | Compile and download blocks once with Download to Target |
| Sources folder compiles but generates no blocks | Source files are STL and require the STL compiler package | Install S7-SCL option package and retry |
| Project opens but Station node is empty | Project was created in TIA Portal and saved as V5.5-compatible but the station export failed | Re-export from TIA Portal, validate via Project → Check Project Consistency |
11. Reference Documentation
The following official Siemens resources document the underlying mechanisms referenced in this article:
- Siemens Industry Online Support — search for "STEP 7 V5.5 HSP" to retrieve the latest Hardware Support Package and release notes.
- Block folder - STEP 7 (TIA Portal V20 reference) — describes the Program blocks folder layout that corresponds to the V5.5 Program blocks container.
- Saving blocks as external source files - STEP 7 (TIA Portal V21 reference) — documents the STL/SCL source-of-truth mechanism used in step 5.6 of the recovery procedure.
Why does the same STEP 7 project show blocks on a 32-bit Windows 7 PC but show an empty Blocks folder on a 64-bit Windows 7 PC?
The 64-bit workstation is most likely missing the matching Hardware Support Package (HSP) for the CPU family used in the project, and the WOW64 COM container is failing to deserialise the block objects. Install the latest V5.5 HSP via the Hardware Support Package tool, then run the V5.5 DVD setup with the Repair option and reboot.
Can I copy the project folder from the working PC instead of archiving it?
No. A STEP 7 V5.5 project is a multi-file container, and copying the directory by hand breaks the link between the .s7p file and the global / hOmSave7 subfolders. Always use File → Archive on the working PC and File → Retrieve on the target PC to transfer the project.
Is "Save As with reorganisation (slow)" safe to run on a live project?
Yes. The slow reorganisation rebuilds the project database index without changing any block logic. It is the recommended quarterly maintenance action for projects with many online/offline sync cycles or with global DBs above 32 KB. Save the result to a new directory to preserve the original until verified.
The Sources folder is present and compiles, but generated blocks never appear in Program blocks. What now?
Confirm the S7-SCL or S7-GRAPH optional package is installed; STL-only sources will compile but produce no block output without the matching compiler. If the option package is present, check the Compile output window for SFC error codes, the most common being SFC 30 / 31 indicating a missing or invalid system master.
Do I need to upgrade the affected PC to TIA Portal to fix this?
No. The empty Blocks folder symptom is a STEP 7 V5.5 issue and is fully resolvable inside V5.5 with the HSP and repair install described in this article. TIA Portal migration is a separate engineering decision and is not required to recover visibility of the blocks.