TIA Portal V16 Crash Going Online with S7-300: Causes and Fixes

Problem Description

TIA Portal V16 terminates unexpectedly when an engineer attempts to establish an online connection to a SIMATIC S7-300 CPU using a project that has been migrated from STEP 7 V5.x. The crash occurs at the moment the Go online action is invoked from the project tree, the toolbar, or the device context menu. The application exits without a recoverable dialog; no rollback, no save prompt, and no error number is surfaced to the user.

Three patterns are consistently reported in the field:

1. The crash is reproducible only against a project that has been imported through the TIA Portal migration tool from STEP 7 V5.5 or V5.6. A freshly authored TIA Portal project targeting the same S7-300 order number connects online without fault.
2. The fault appears regardless of the physical online interface used: PROFINET over a CP 343-1, MPI over a USB PC adapter (6ES7972-0CB20-0XA0), PROFIBUS over a CP 5611 (6GK1561-1AA01), or TCP/IP routed through an S7 router.
3. Some engineers report the same behavior on TIA Portal V15.1 Update 7 with the matching S7-300/400 Optional Package, indicating that the root cause is not strictly version-bound to V16. Both V15.1 and V16 share the same online subsystem codebase; the migration residue from STEP 7 V5.x is the common trigger.

The delta between "crashes" and "works" is the most diagnostic signal: it points firmly at migration-introduced artifacts in the project database rather than at a runtime defect in TIA Portal itself.

Environment and Version Matrix

The S7-300/400 Optional Package is mandatory to author and go online with S7-300 CPUs in TIA Portal. When the package is missing, TIA Portal will not present the S7-300 device family in the device catalog, and online operations will fail with descriptive warnings — not with a hard crash. A hard crash therefore implies that the optional package is present, the device family is loaded, but the project structure contains unresolved migration residue.

Root Cause Analysis

Three plausible root causes account for the vast majority of TIA Portal V16 crashes observed during the online handshake with a migrated S7-300 project. None of them are version-specific defects; all are project-state issues that the engineer can resolve locally.

1. Incomplete Migration and Uncompiled Residue

STEP 7 V5.x projects compiled for the target S7-300 are migrated through the TIA Portal migration tool (Project → Migrate project). The migration produces a TIA Portal project that references the S7-300 family but does not perform a clean rebuild during import. Inconsistent compile state, particularly blocks that reference libraries no longer present in the TIA Portal environment (e.g., custom libraries, IEC function blocks, or S7-300 CPUs that have been re-ordered during the migration), produces corruption in the offline/online signature that the online subsystem attempts to resolve at connection time.

Diagnostic signal: opening the migrated project surfaces compile warnings about "blocks that could not be migrated automatically" or "blocks with absolute addressing that may need to be revised". Yellow warning triangles remain on program blocks in the project tree.

2. Online Interface or PG/PC Interface Misconfiguration

TIA Portal V16 uses the same Set PG/PC Interface tool as STEP 7 V5.x, but the routing rules are evaluated differently. If the S7-300 is reached through a subnet router (for example, an S7-300 CPU in another rack with routing enabled, or a CP that has not been added to the TIA Portal device configuration), TIA Portal may attempt to discover online partners using a topology that does not match the migrated hardware configuration. The crash can originate from an unrecoverable error in the online topology resolver when it encounters a referenced but unconfigured node.

Diagnostic signal: a "Compiling hardware" warning is raised before going online, or a topology mismatch is listed in the project tree under Devices & Networks with a red exclamation mark on the S7-300 station.

3. Mixed TIA Portal and STEP 7 V5.x Cache for the Same Project

A project that has been opened in both STEP 7 V5.x and TIA Portal V16 can develop inconsistent cache files. When TIA Portal V16 reads the cached online signature and tries to bind it to a STEP 7 V5.x session pointer, the online DLL (s7onlinx.dll) can fault. This is the most common cause of a fault reported against s7onlinx.dll in the Windows Application Event Log.

Diagnostic signal: the project is stored in a folder containing both .s7p and .ap16 files, or the S7-300 station appears in TIA Portal with a warning icon indicating that the station was last modified by a different TIA Portal version.

4. Missing or Mismatched Hardware Support Package (HSP)

The migrated project references an S7-300 CPU whose firmware or hardware revision is not part of the default TIA Portal V16 device catalog. If the matching HSP is not imported, TIA Portal falls back to a generic S7-300 placeholder. The online handshake then fails because the placeholder does not carry the same online identifier as the real CPU.

Diagnostic signal: the device in the hardware catalog displays a placeholder icon, and the diagnostic buffer of the CPU shows a hardware mismatch entry.

5. Corrupted User Profile Cache

The TIA Portal user profile under %LOCALAPPDATA%\Siemens\Automation stores compiled assemblies and online cache. A corrupted profile produces crashes that are reproducible only for one engineer but not for another on the same workstation.

Diagnostic signal: a second engineer logging into Windows on the same PC does not reproduce the crash.

Diagnostic Procedure

Step 1 — Capture TIA Portal and OS Versions

1. Open TIA Portal V16. Select Help → About and record the exact build identifier (e.g., V16.0 + Update 6, build 6ES7822-1AA06-0YA5).
2. Open a command prompt and run winver. Record the Windows version and build number.
3. Confirm the S7-300/400 Optional Package is installed: in TIA Portal, Options → Support Packages should list the S7-300/400 package version matching the TIA Portal installation. Cross-reference the version with the matrix published in the TIA Portal V16 release notes.

Step 2 — Isolate the Project

1. Copy the migrated project to a clean folder. Remove any .s7p, .s7l, .s7backup, .log, and _log files. Keep only the .ap16 file.
2. Open TIA Portal V16, select Project → Migrate project, and point to the STEP 7 V5.x source rather than the previously migrated file. This forces a clean migration from the canonical source.
3. Recompile the hardware first: open Devices & Networks → Device view, right-click the S7-300 station, and select Compile → Hardware (rebuild all).
4. Recompile the software: in the project tree, right-click the PLC_1 node and select Compile → Software (rebuild all).

Step 3 — Test Online with a Blank Project

1. Create a new TIA Portal V16 project.
2. Insert an S7-300 station of the same order number as the migrated project.
3. Connect the PG to the S7-300 CPU using the same interface and physical adapter.
4. Attempt Online → Go online. If this succeeds, the crash is project-bound, not environment-bound.

Step 4 — Check Interface Assignment

1. Open Control Panel → Set PG/PC Interface.
2. Verify the access point S7ONLINE points to the correct adapter (TCP/IP for PROFINET, PC Adapter for MPI/PROFIBUS, or CP 5611/CP 5622 for PROFIBUS).
3. If the migrated project contains an S7-300 with both PROFINET and MPI interfaces, ensure the PG/PC is the only master in the MPI subnet. Multiple MPI masters produce bus contention that can fault the online handshake.

Step 5 — Review the Windows Event Log

1. Open Event Viewer → Windows Logs → Application.
2. Filter for the source Application Error in the last hour.
3. Record the Faulting module name from the crash entry. This is critical when escalating to Siemens Support. A fault in s7onlinx.dll points to the online subsystem; a fault in s7epa.dll points to the project access layer; a fault in OxyPlot or a .NET PresentationFramework module points to the HMI/UI render path; a fault in Siemens.Automation.Portal.exe points to the TIA Portal shell itself.

Compile Warnings Inventory

During a forced recompile after migration, the following warnings are the most common and the most likely precursors of an online crash:

Migration Workflow Considerations

The TIA Portal migration tool performs a structural transformation of the STEP 7 V5.x project into the TIA Portal project database. The transformation is not a recompile: it copies data, rewrites references, and creates the project tree, but it leaves the original compile artifacts intact. The engineer is responsible for triggering the rebuild after migration.

The recommended migration sequence is:

1. Source preparation. In STEP 7 V5.x, perform Program → Compile (rebuild all) on the source project. Resolve every warning. Save and close STEP 7 V5.x.
2. Project migration. In TIA Portal, select Project → Migrate project. Do not open the migrated project in STEP 7 V5.x after this step.
3. Hardware rebuild. In TIA Portal, recompile the hardware with the matching HSP installed.
4. Software rebuild. Recompile all program blocks, paying attention to OB1, OB35, OB82, OB86, OB100, OB121, OB122 (the OBs most commonly affected by migration residue in S7-300 projects).
5. Library reconciliation. Re-install or remove all library references that the migration tool flagged.
6. First online. Establish the first online connection on a known-good interface. The first online handshake triggers a full signature reconciliation.
7. Project save. Save the project as .ap16 once online is established.

Library Migration Reference

Libraries are a frequent crash trigger because the TIA Portal library manager is structurally different from the STEP 7 V5.x library structure. The migration tool attempts to translate references but cannot resolve cases where the original library no longer exists or has been renamed.

Online Topology Resolution

TIA Portal resolves the online path to the target CPU using the topology defined in Devices & Networks. The migrated project retains the STEP 7 V5.x topology, which may not match the physical wiring. A mismatch causes the online resolver to enumerate nodes that do not exist and fault when one of them fails to respond.

The diagnostics surface for this case is Online → Accessible nodes (the equivalent of STEP 7 V5.x's PLC → Edit Ethernet Node). If Accessible nodes returns no entries when the PG is known to be connected, the topology has been corrupted by migration. Re-authoring the topology from scratch resolves the crash.

Firmware Compatibility

S7-300 CPUs released after the TIA Portal V16 release date may require an updated HSP. As a general guideline:

If the CPU firmware in the field is newer than the version known to TIA Portal V16, import the matching HSP via Options → Support Packages → Install HSP. The HSP is published on the Siemens Industry Online Support portal at support.industry.siemens.com.

Solution Matrix

Step-by-Step Fix Procedure

1. Close TIA Portal completely. End the s7tgtopx.exe process if it persists in Task Manager.
2. Back up the project folder. Create a *.zip archive before any modification.
3. Clean the project folder. Remove .s7p, .s7l, *.log, global, ombstx, LAYOUTS, and any Reuse folder from the project directory. Keep only the .ap16 file and the associated user folders.
4. Re-migrate from STEP 7 V5.x source. In TIA Portal, Project → Migrate project; select the original .s7p file. Do not migrate from a previously migrated TIA Portal project.
5. Recompile hardware. Right-click the S7-300 station → Compile → Hardware (rebuild all). Resolve every warning that the compiler surfaces.
6. Recompile software. Right-click PLC_1 → Program blocks → Compile → Software (rebuild all). Pay specific attention to OB1, OB35, OB82, OB86, OB100, OB121, OB122 — these are the blocks most commonly affected by migration residue in S7-300 projects.
7. Verify the project. In the project tree, every block should display a green check mark. Yellow triangles indicate unresolved references.
8. Set the PG/PC interface. Confirm the S7ONLINE access point matches the physical adapter connected to the CPU.
9. Go online. Right-click PLC_1 → Go online. The first online connection takes 10–30 s; subsequent connections complete within 5 s.
10. Save the project as .ap16 once online is established.

Verification

After the fix procedure, verify each of the following:

• TIA Portal V16 establishes an online connection to the S7-300 CPU without terminating the application.
• The online view shows a green check mark on every block of the S7-300 program.
• The diagnostic buffer of the S7-300 CPU is readable via Online → Online & Diagnostics → Diagnostic buffer.
• A forced download (Online → Download to device) completes successfully. A download is the strongest end-to-end test of the online subsystem.
• Closing and reopening TIA Portal V16 with the same project does not regress to a crash.
• Reproducing the original sequence (close project, reopen project, Go online) on the same project produces a stable online connection three times in a row.

Escalation Path

If the crash persists after all the above steps:

1. Generate a TIA Portal support request: Project → Support → Create support request. This packages the project, the Windows event log, and the TIA Portal installation log into a single .zip.
2. Submit the request through the Siemens Industry Online Support portal at support.industry.siemens.com with the SR number logged.
3. Provide the crash module name from the Application Event Log; Siemens Support uses this to route the case to the responsible development group (online subsystem, project access, or UI rendering).
4. As a workaround, open the migrated project in TIA Portal V15.1 (with the matching S7-300/400 Optional Package) and confirm whether V15.1 also crashes. If V15.1 is stable but V16 is not, the issue is version-specific and will be tracked by Siemens under the V16 hotfix roadmap.

Related Field Observations

Several workarounds reported by engineers have proven effective in production environments:

• Some engineers have reported that disabling the antivirus real-time scan on the project folder eliminates the crash. This points to AV products that hook the file system and interfere with TIA Portal's lazy-loaded assembly resolver. If the crash disappears with AV disabled, configure an exclusion for C:\Program Files\Siemens\Automation\ and the project root.
• A second workaround reported in the field is to launch TIA Portal V16 with Run as administrator, especially when the project is stored under C:\Users\Public\Documents.
• Windows 10 21H2 has been observed to be more tolerant of TIA Portal V16 online operations than Windows 10 1909. If the deployment environment permits, upgrading the operating system is a defensive measure.
• TIA Portal V16 Update 7 and later include stability fixes for the online subsystem against S7-300 projects. Update to the latest V16 update available on the Siemens Software Update Server before escalating.
• If the migrated project contains a long symbol table (> 5000 symbols), the online signature calculation can time out and produce a crash. Splitting the symbol table into multiple smaller tables before migration has been reported to avoid this case.
• If the migrated project was last saved on a non-Windows drive (e.g., a network share), copy it to a local NTFS drive before opening in TIA Portal. Some online subsystem paths do not handle SMB-mounted projects cleanly.