Resolving STEP 7 Error 3995:215 Cross-Reference Failure

1. Problem Description

When attempting to perform a cross-reference (Querverweis) operation in a Siemens STEP 7 project, the SIMATIC Manager displays the following dialog:

Internal Error: it was not possible create a link between two objects

Cross-reference is one of the most heavily used navigation tools in STEP 7 because it builds a complete map of where every operand, address, symbol, block call, and tag is used across the entire S7 program. When the cross-reference function aborts with an internal error, the engineer loses the ability to trace signal flow, find unused tags, perform I&O documentation, and verify rewires. The dialog typically appears immediately after the user selects Options > Cross-Reference (or presses Ctrl+Alt+Q) and STEP 7 begins building the offline cross-reference list.

The error is most often reported as a numeric tuple 3995:215 visible either in the dialog caption, the SIMATIC Manager status bar, or the STEP7Log text file. The error class 3995 belongs to the S7DB family of internal database errors, and the trailing 215 is an internal sub-code that the standard Siemens Error codes in STEP 7 reference document does not enumerate in its public form.

2. Affected Hardware and Software

This error has been observed on the following combinations:

The CPU 315T is a technology CPU in the S7-300 family. It integrates the standard S7-300 instruction set with technology functions for motion control, and it normally requires the optional S7-Technology (S7-Technologie) package on the engineering station. When S7-Technology is not installed, the technology objects (TO) appear in the project as placeholder references, and the cross-reference engine must traverse these placeholders to build the complete map. The fact that the engineer did not have S7-Technology installed is a relevant context flag for this error: the cross-reference engine was attempting to link objects across an S7-Technology container that the local installation could not resolve.

3. Decoding Error 3995:215

STEP 7 internal errors use the syntax <error_class>:<sub_code> where:

• error_class is the high-level group (e.g., 3000 = compilation, 3990 = database/link).
• sub_code is a granular internal descriptor.

The 3995:215 combination falls into the database / link group. According to the Siemens FAQ What is the meaning of the error codes (xxxx:yyyy) in STEP 7?, codes in the 399x range are typically generated when the offline database cannot complete a link operation between two project objects (blocks, sources, symbols, or system data). The specific sub-code 215 is not present in the publicly distributed Siemens error-code PDF; this is consistent with the fact that the S7DB error sub-codes are partially implementation-internal and not all are released to the public reference.

4. Root Cause Analysis

Three root causes cover the overwhelming majority of field cases:

1. Corrupted offline cross-reference index. STEP 7 caches the cross-reference in the CrossRef subdirectory of the project. If the cache becomes inconsistent with the actual project structure (after block deletions, re-imports, archive/restore cycles, or interrupted saves), the link engine cannot reconstruct the object graph and aborts with 3995:215.
2. Optional package mismatch. The S7-Technology option is not installed on the engineering station, but the project contains technology objects (TOs) or technology blocks created on a different station. The cross-reference engine tries to resolve these TOs and fails because the S7-Technology DB schema is missing.
3. Structural inconsistency from a Save As or project copy. A project that was copied, archived, or restored with a non-current version of STEP 7 may carry orphan references, duplicate block folders, or truncated S7Proj files that the link engine cannot traverse.

The combination of CPU 315T and missing S7-Technology strongly suggests that causes (1) and (2) are co-occurring: the link engine is trying to walk across TOs that the local installation cannot resolve, and the cached cross-reference index is simultaneously inconsistent.

5. Resolution: Reorganize (Slow) Procedure

The most reliable field-proven fix is to force a full database re-organisation with the Save As with Reorganisation (slow) path. The procedure rebuilds the offline database and the cross-reference index from the project files on disk, discarding the corrupted cache.

Prerequisites

• Close every SIMATIC Manager and S7 editor instance.
• Ensure no other engineer is editing the project (single-writer only).
• Make a complete archive of the project (.zip or .arc) before starting. STEP 7 archives are not always recoverable with stock unzip tools, so use File > Archive from SIMATIC Manager.
• Verify the workstation has at least 2 GB free on the partition that hosts the project folder.

Step-by-step

1. Open SIMATIC Manager and load the affected project.
2. Select the project root in the left-hand tree (the S7 project node, not the station).
3. Open File > Save As....
4. In the Save As dialog, browse to a new folder or a new project name. Do not overwrite the original.
5. Tick the option "With reorganisation (slow)" (German: Mit Reorganisation (langsam)). This checkbox is below the path field and is unchecked by default.
6. Confirm with OK. STEP 7 will run for several minutes on a large project; the progress bar at the bottom of SIMATIC Manager shows database pass activity.
7. When Save As completes, open the new project copy and trigger Options > Cross-Reference > Display. The error 3995:215 should no longer appear.
8. Confirm the new project is functionally identical: open the S7 program, double-check that all blocks compile (Program > Compile All) and that the offline/online view of the CPU 315T is consistent.
9. Once verified, the original (corrupted) project can be archived for forensic backup and removed.

6. Alternative Recovery Methods

If Save As with Reorganisation (slow) does not resolve the error, the following alternatives are available in order of increasing invasiveness.

6.1 In-place Reorganize (online)

STEP 7 exposes a lightweight reorganize command that runs against the currently open project:

1. In SIMATIC Manager, select the S7 program node.
2. Open File > Reorganize... (German: Datei > Reorganisieren).
3. Confirm the prompt that the project will be locked during the operation.

This rebuilds the in-memory index without writing a copy. It is faster but less thorough than the slow path. Use it as a first attempt before the Save As path.

6.2 Delete the CrossRef cache manually

For engineering workstations with file-system access to the project, the cross-reference cache can be removed manually so STEP 7 rebuilds it on next access:

1. Close the project in SIMATIC Manager.
2. Browse to <project_folder>\<project_name>\CrossRef\.
3. Delete the contents of the CrossRef folder (do not delete the folder itself).
4. Reopen the project. STEP 7 will rebuild the cross-reference on demand.

If the dialog reappears immediately, the project is structurally inconsistent and a Save As with reorganisation is required.

6.3 Install the missing S7-Technology package

On the affected engineering station, install the S7-Technology optional package that matches the STEP 7 version (e.g., S7-Technology V4.2 for STEP 7 V5.5). After installation, restart the workstation and reopen the project. This alone often eliminates the error when technology objects are present in the project. The package is available from the Siemens Industry Online Support portal under entry ID 109769370 for the S7-Technology V4.2 SPx releases.

6.4 Consolidate blocks via re-import

If the project was assembled from imported STL sources, re-import the sources from the integrated source folder:

1. Open the S7 program.
2. Right-click the Sources folder and choose Generate blocks from sources.
3. Compare the regenerated blocks against the compiled reference using Options > Compare Blocks.

This often clears orphan references that the link engine cannot resolve.

7. Database Integrity Checks

After the reorganisation, the engineer should verify that the offline database is fully consistent before trusting the project. Use the following checklist:

8. Verifying the Fix

The success criteria after reorganisation are:

1. Opening Options > Cross-Reference > Display no longer shows the Internal Error 3995:215 dialog.
2. The cross-reference table populates with the expected operands: I, Q, M, DB, T, C, FB, FC, SFB, SFC, and UDT instances.
3. Navigating from a cross-reference entry (double-click) opens the correct block and highlights the correct network.
4. Re-saving the project and reopening it on a second workstation reproduces a clean cross-reference (multi-user sanity check).

If criteria 1 passes but criteria 2 shows zero entries, the cross-reference engine ran but the index is empty; this is a different fault and is typically resolved by deleting the CrossRef cache (Section 6.2) and forcing a full rebuild.

9. Preventive Maintenance

To minimise recurrence, apply the following rules on the affected project:

• Single-writer discipline. Never open the same STEP 7 project from two SIMATIC Manager instances, even read-only, on a network share. STEP 7 uses a file-locking mechanism that does not protect against all write patterns.
• Use the official Archive/Retrieve path. Copying a STEP 7 project with Windows Explorer is the most common cause of cross-reference index corruption. Use File > Archive and File > Retrieve instead.
• Keep S7-Technology installed on every engineering station that opens a project with technology objects. The missing optional package is a leading contributor to this fault class.
• Schedule periodic reorganisation. On a project in active development, run File > Reorganize monthly; on long-running maintenance projects, run it on every major block release.
• Match STEP 7 versions across the engineering team. A project saved with a newer service pack and opened on an older one is a known source of structural drift.

10. Field-Proven Caveats and Edge Cases

• Hidden bookmarks / placeholder blocks. A related class of fault is the presence of "hidden" placeholder blocks created by interrupted source generation. These are not visible in the block tree but the cross-reference engine still attempts to resolve them. Save As with reorganisation drops the placeholders; manual deletion through the S7 sources view is otherwise required.
• CPU 315T with mismatched firmware. The CPU 315T-2 DP and 315T-3 PN/DP have different firmware trains. If the project was created on a station with newer firmware and opened on a station with older STEP 7 Technology, the technology container may not import cleanly. The fix is to keep firmware images in sync with the engineering software.
• Multi-language projects. STEP 7 projects with multiple language comment columns have been reported to amplify the corruption. Reorganisation still resolves the error, but engineers should also verify the comment columns render correctly after the rebuild.
• Do not run Save As with reorganisation across a network share. Always operate on a local drive to avoid SMB lock contention that can corrupt the rebuild mid-operation.

11. Summary of Repair Decision Path

1. Archive the project for forensic backup.
2. If S7-Technology is missing on a CPU 315T project, install it.
3. Try File > Reorganize (in-place) first.
4. If 3995:215 still appears, run Save As with the With reorganisation (slow) flag to a new project name.
5. Open the new project, rebuild the cross-reference, verify all blocks compile.
6. Decommission the original corrupted project copy.

12. FAQ