TIA Portal V12 Crash on CPU Insert: S7DOS Section Repair

Problem Overview

Symptom: launching TIA Portal V12, creating a new project (or opening an existing project with no devices), invoking Insert > New Object > CPU, selecting any S7-300 / S7-400 / S7-1200 / S7-1500 CPU from the catalog, and pressing Insert terminates the process immediately with no dialog and no Windows error prompt beyond a generic application crash. The fault is reproducible across multiple CPU types, after a normal uninstall/reinstall cycle, and after a TIA Portal Repair launched from Programs and Features. During the in-place repair the installer reports a non-fatal warning of the form:

Cannot repair all, because a part of software have version greater than the installing source.

The message identifies no specific component, so the root cause is hidden from the operator. This article documents the confirmed resolution path: repair of the Step 7 S7DOS installation section (Microsoft Windows Installer product {CCC01ADD-3A54-11D6-92A8-00A0245B3AC6}) followed by a clean TIA Portal V12 reinstall.

Symptoms and Reproduction Steps

Reproduction is deterministic on a corrupted host:

1. Start TIA Portal V12 (Start > Siemens Automation > TIA Portal V12).
2. Create a new project or open a project with an empty project tree.
3. In the project tree, right-click the project node and choose Insert New Object > Device.
4. Browse the device catalog to any controller family, expand SIMATIC S7-300 / S7-400 / S7-1200 / S7-1500, and select a specific CPU article number (e.g. 6ES7 315-2EH14-0AB0, 6ES7 151-8AB01-0AB0).
5. Click Insert or press the Insert key.

TIA Portal exits to the desktop without writing a TIA log entry. On a host with WER (Windows Error Reporting) enabled, %LOCALAPPDATA%\Microsoft\Windows\WER\ReportQueue\ contains an AppCrash_TIA_Portal.exe_*.dmp referencing an unhandled exception inside the device configuration component. The same crash is observed on physical and virtual machines that ship with mismatched Step 7 / TIA Portal media.

Root Cause Analysis

TIA Portal V12 and Step 7 V12 SP1 share a common Microsoft Windows Installer substrate, and the S7DOS section is registered as its own MSI product with product code {CCC01ADD-3A54-11D6-92A8-00A0245B3AC6}. S7DOS provides the DOS-protected-mode / license-handling layer that TIA Portal's device configurator calls when materializing a CPU object (it loads catalog metadata and validates the CPU's licensing envelope). When the S7DOS install is partially applied — i.e. the cached MSI in %WINDIR%\Installer no longer matches the source media — three failure modes manifest:

1. Catalog insert crash. TIA's device configurator calls a DLL exported by S7DOS that resolves against the cached MSI; a stale cache returns an inconsistent state and the configurator throws an unhandled SEH exception.
2. Silent repair warning. The TIA Repair mode invokes msiexec /f {product} for every product it knows about. When the locally installed feature version exceeds the feature version in the source media (typical after applying a hotfix or service pack to one product but not the other), msiexec emits the warning reproduced above and skips the repair, leaving the system in a half-fixed state.
3. Repair that 'succeeds' but does not heal the device insert path because the offending component is registered to a different product (S7DOS), not to the TIA Portal MSI itself.

The fix is to force a clean reapplication of the S7DOS product from the Step 7 media so that the cached MSI and feature state are coherent, and only then reinstall TIA Portal V12.

Pre-Repair Diagnostics

Before mutating the Windows Installer cache, confirm that the host matches the failure signature.

1. Open Programs and Features (appwiz.cpl) and verify the presence of SIMATIC STEP 7 Professional V12.0 SP1 and SIMATIC TIA Portal V12. Note the exact version strings and build numbers.
2. Open an elevated command prompt and list all registered MSI products whose name contains SIMATIC or S7DOS:
   wmic product where "name like '%%SIMATIC%%' or name like '%%S7DOS%%'" get name,version,identifyingnumber
3. Confirm that {CCC01ADD-3A54-11D6-92A8-00A0245B3AC6} is listed with a non-empty Version field. If it is missing entirely, the failure is a different component — proceed to the Related Failure Modes section.
4. Verify the Windows Installer cache. The folder %WINDIR%\Installer\{CCC01ADD-3A54-11D6-92A8-00A0245B3AC6} should exist; if it has been removed by cleanup utilities, the S7DOS section will not repair.
5. Capture the WER crash dump so you can confirm the failing module is inside the TIA device configurator and not, for example, a graphics driver fault. The dump path is logged in the Event Viewer > Windows Logs > Application entry, Event ID 1000 / 1001, source Application Error.

Step-by-Step S7DOS Repair Procedure

The procedure below was confirmed on a host running STEP 7 Professional V12.0 SP1 with the original DVD media mounted. The same steps apply to a mounted ISO.

1. Close TIA Portal, Automation License Manager, and any service that depends on the S7DOS driver.
2. Open Programs and Features, select SIMATIC STEP 7 Professional V12.0 SP1, and choose Uninstall. Wait for the wizard to complete. If a reboot is requested, perform it before continuing.
3. Open an elevated cmd.exe prompt. Verify that the S7DOS product is still registered:
   reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /f "{CCC01ADD-3A54-11D6-92A8-00A0245B3AC6}" /s
4. Attempt a direct msiexec removal:
   msiexec /x {CCC01ADD-3A54-11D6-92A8-00A0245B3AC6} /qb REBOOT=R
   If the command reports This action is only valid for products that are currently installed, the cached MSI under %WINDIR%\Installer is corrupt or missing — proceed to the next step.
5. Rename the cached installer folder so Windows Installer is forced to re-extract it from the source media:
   ren "%WINDIR%\Installer\{CCC01ADD-3A54-11D6-92A8-00A0245B3AC6}" "{CCC01ADD-3A54-11D6-92A8-00A0245B3AC6}.old"
   Do not delete it; the rename is a safety valve so you can revert if the repair re-extracts an equally broken MSI.
6. Mount the original Step 7 V12 SP1 DVD or ISO. From the elevated prompt, run the original Start.exe with the explicit intent to repair:
   D:\Start.exe /repair
   where D: is the DVD/ISO drive letter. The setup detects the missing cache entry and re-streams the S7DOS MSI into %WINDIR%\Installer\{CCC01ADD-3A54-11D6-92A8-00A0245B3AC6}, then runs an Install of the S7DOS feature against the live product registration. The setup log is written to %TEMP%\S7Setup.log — verify the line S7DOS: Installation successful appears.
7. After the repair wizard completes, do not reboot if the dialog offers the option; reboot only if it is mandatory. Then re-query the S7DOS product:
   wmic product where "IdentifyingNumber='{CCC01ADD-3A54-11D6-92A8-00A0245B3AC6}'" get name,version
   The version should match the media (V12.0 SP1: 12.01.0000 or higher as supplied on the disc).
8. Delete the renamed backup folder once the version is confirmed correct:
   rmdir /s /q "%WINDIR%\Installer\{CCC01ADD-3A54-11D6-92A8-00A0245B3AC6}.old"

TIA Portal V12 Reinstallation

After the S7DOS feature is restored, TIA Portal V12 itself is reinstalled from its own DVD or ISO so the device configuration links to the freshly-installed S7DOS runtime.

1. Uninstall TIA Portal V12 from Programs and Features. If a reboot is requested, perform it.
2. Manually clear residual TIA Portal entries to avoid orphan features:
   msiexec /x {TIA_PORTAL_V12_GUID} /qb REBOOT=R
   (Replace {TIA_PORTAL_V12_GUID} with the value returned by the wmic product where "name like '%%TIA Portal%%'" get identifyingnumber query.)
3. Delete orphaned TIA cache directories:
   rd /s /q "%PROGRAMDATA%\Siemens\Automation\Portal V12"
rd /s /q "%LOCALAPPDATA%\Siemens\Automation\Portal V12"
4. Mount the TIA Portal V12 DVD/ISO and run Start.exe. Select Install / reinstall and accept the default feature set including SIMATIC S7-300/400, SIMATIC S7-1200/1500, and S7DOS.
5. Reboot when prompted. The SIMATIC Automation License Manager service and the S7DOS service are started by the SCM post-install.

Verification

Verify the fix in this order. Each step must pass before the next is attempted.

1. Open TIA Portal V12 and create a new project. The project tree must populate without warnings.
2. Insert a CPU of each family that previously crashed: an S7-300 (e.g. CPU 315-2 PN/DP, 6ES7 315-2EH14-0AB0), an S7-400 (e.g. CPU 414-3 PN/DP, 6ES7 414-3EM06-0AB0), and an S7-1500 (e.g. CPU 1515-2 PN, 6ES7 515-2AM02-0AB0). Each insertion must complete with a fully populated device view.
3. Open Automation License Manager and confirm the S7DOS license slot is populated; an empty slot means the S7DOS install was not picked up.
4. Open a hardware catalog and confirm the device filters return the expected count of CPUs and I/O modules per family. A truncated catalog means the catalog index was not rebuilt — run Options > Update Catalog from inside TIA Portal.
5. From an elevated command prompt, force a self-repair and confirm no version warnings appear:
   msiexec /f {CCC01ADD-3A54-11D6-92A8-00A0245B3AC6} /qb REBOOT=R
   Output must not contain Another version of this product is already installed.
6. Compile the project to PLC code. A successful compile is the strongest end-to-end signal that the device configuration, catalog, and S7DOS runtime are aligned.

Affected Versions and Compatibility Matrix

Related Failure Modes

If the diagnostic in step 3 of the Pre-Repair Diagnostics section does not show the S7DOS product code, the failure is one of the following and the S7DOS procedure does not apply.

• Missing .NET Framework 4.5 prerequisite. TIA V12 requires .NET 4.5. A missing or downgraded CLR causes a silent device-configurator crash. Re-enable .NET Framework 4.5 Advanced Services via Turn Windows features on or off.
• Orphaned Automation License Manager service. The ALM service failing to start (event ID 7000) prevents the license cache from being rebuilt; the CPU insert path surfaces a different exception. Repair ALM independently from its own media.
• Corrupt TIA Portal catalog index. If the device insert succeeds but the catalog shows zero entries, delete %PROGRAMDATA%\Siemens\Automation\Portal V12\Catalog and re-open TIA Portal to trigger an automatic rebuild.
• Mixed 32/64-bit installations. TIA V12 ships native x64 binaries. A 32-bit Office / 32-bit ALM coexisting with a 64-bit TIA Portal can corrupt COM activation. Force the matching platform for both TIA and ALM.
• Antivirus file-locking. Some real-time AV products lock files inside %WINDIR%\Installer during scans. Whitelist the Installer and Siemens program data directories before retrying the procedure.

Prevention and Best Practices

1. Always install Step 7 and TIA Portal from the same media set. The DVD image must contain matching Updates / Service Packs descriptors; mixing a Step 7 SP1 disc with a TIA Portal RT disc is the most common path into this failure.
2. Use the Siemens Technical Support knowledge base before repairing — search the product code CCC01ADD-3A54-11D6-92A8-00A0245B3AC6 to surface any newer advisories.
3. Avoid third-party installer cleaners (for example, MSICUU, PatchCleaner) on TIA hosts. They will purge the very MSI cache entry that the repair procedure depends on.
4. Snapshot the system before applying any TIA V12 hotfix. Use the in-place Update path of Start.exe, not a manual MSI repackage.
5. Maintain a side-by-side DVD image library per major version (V12, V13 SP1, V14, V15.1, V16, V17, V18, V19) and tag the ISOs with their media build number.
6. For multi-engineer environments, deploy TIA Portal as a VMWare / Hyper-V image rather than per-workstation installs. Image-based rollback is faster than the MSI repair above.

FAQ