Fixing Siemens ALM Error 1067 0xC0000005 Fault on TIA Portal V19

Problem Overview

When you install TIA Portal V19 on a Windows 10 22H2 system (build 19045) and then attempt to launch the Automation License Manager (ALM), the application posts a dialog: "The Automation License Manager Service has not been started! Please start the Service." Attempting to start the service manually from services.msc (Task Manager → Services → Open Services) produces the Windows error dialog:

Windows could not start the Automation License Manager Service service on local computer.
Error 1067: The process terminated unexpectedly.

Running the Siemens compatibility tool kompatool.exe (bundled with the TIA Portal installation media) reports the product as Automation License Manager V6.0 SP12 Upd2 — the ALM component bundled with TIA Portal V19. The tool displays the note: "You have a higher version installed that is approved. You can install a previous version for this product." Downgrading the ALM to V6.2 (or keeping V6.0 SP12) does not resolve the failure: the service still terminates on start with error 1067. The Event Viewer fault stack consistently shows:

Faulting application name: almsrv64x.exe, version: 600.904.101.3, time stamp: 0x63403f91
Faulting module name:    MSVCP140.dll, version: 14.38.33135.0, time stamp: 0x3031db4d
Exception code:           0xC0000005 (STATUS_ACCESS_VIOLATION)
Fault offset:             0x00000000000126bf
Faulting process ID:      0x403c
Faulting application path: C:\Program Files\Common Files\Siemens\sws\almsrv\almsrv64x.exe
Faulting module path:     C:\Windows\SYSTEM32\MSVCP140.dll
Report ID:                acf3387c-ade4-43d8-af27-fd20fbf8fc88

Immediately preceding the crash, the almsrv64x.exe service logs the API error:

API = Cannot modify the existing BBI root folder access rights.
       os error code = 19, os message = media is write protected.

The combination of Windows error 1067, the STATUS_ACCESS_VIOLATION (0xC0000005) in almsrv64x.exe, the MSVCP140.dll dependency, and OS error 19 against the BBI root folder identifies a specific installation/permissions defect rather than a hardware, network, or license-key issue. The failure is reproducible immediately after a clean installation, even before any license is loaded, which rules out license-file corruption.

Affected Software, Builds, and Operating Systems

The following matrix lists the confirmed-affected and known-working combinations. Cross-check the live compatibility list at the Siemens Industry Online Support portal before commissioning, because ALM and TIA Portal pairing is strict and Siemens rotates the ALM build per TIA Portal release.

Root Cause Analysis

Three concurrent defects combine to produce the symptom. The first two are environmental (user-side), and the third is a documented ALM hardening quirk that exposes the first two. Treat them as a chain — repairing only the C++ runtime or only the ACL set leaves the fault intact because the ALM service re-applies its ACL expectations on every start.

3.1 Defective or partially installed MSVCP140.dll

almsrv64x.exe is linked against the Microsoft Visual C++ 2015–2022 runtime (MSVCP140.dll). The exception code 0xC0000005 at offset 0x00000000000126bf lands inside the C++ stream/IO path that almsrv64x.exe uses to write its BBI data folder and license cache. If MSVCP140.dll version 14.38.33135.0 is present but the matching VCRUNTIME140.dll, VCRUNTIME140_1.dll, or MSVCP140_1.dll is missing or corrupt, the service dereferences a NULL stream object at the very first IO call and terminates with the access violation. Reinstalling only the redistributable is therefore the first corrective step and addresses the exception itself.

3.2 Revoked or redirected BBI root folder

ALM stores its database and license cache in a folder it refers to internally as the BBI root folder (default %ProgramData%\Siemens\Automation License Manager\BBI or, in TIA Portal V19, %ProgramData%\Siemens\SWS\BBI). On first service start, the ALM installer attempts to grant the LocalSystem account modify rights to that folder. If NTFS permissions have been stripped, if the folder is on a controlled-access path (OneDrive Documents, App-V, Controlled Folder Access, or a folder that has been redirected to a network share with read-only ACLs), or if the parent directory carries a read-only attribute that was set by a previous failed install, the OS returns ERROR_WRITE_PROTECT (19). The ALM API layer translates that to "Cannot modify the existing BBI root folder access rights", the stream constructor inside almsrv64x.exe throws, and the service exits with the access violation. This is the layer that produces the OS error 19 message that precedes the crash dump.

3.3 Order-of-installation defect

If TIA Portal V19 was upgraded in place over an older TIA Portal (V16/V17/V18) and the older ALM service binary remained in C:\Program Files\Common Files\Siemens\sws\almsrv\, the ALM 6.0 SP12 Upd2 installer can leave the previous service registration pointing at a now-removed DLL. The service starts, the loader resolves a stale path, and the access violation occurs before any of the ALM 6.0 logic executes. This is why the kompatool message "you can install a previous version" appears: the registry still references the older binary family. Confirm this with sc qc "almsrv64x" — the BINARY_PATH_NAME must point to the V19 file, not a leftover from a prior install.

3.4 Failure path overview

Diagnostic Procedure

Run the following checks in order. Each step verifies or eliminates one root-cause layer. Capture the output of every step — the artefacts (event text, sc output, attrib output, file versions) are exactly what Siemens support will request if escalation is required.

1. Capture the faulting event. Open Event Viewer → Windows Logs → Application and filter for Source = Application Error and Source = ALMSRV. Confirm the faulting module is MSVCP140.dll and the exception code is 0xC0000005. If the exception code is 0xC000007B (BAD_IMAGE_FORMAT), the issue is a 32/64-bit mismatch — re-extract the ALM package for x64 only.
2. Verify the service registration. From an elevated command prompt: sc qc "almsrv64x" Confirm BINARY_PATH_NAME points to C:\Program Files\Common Files\Siemens\sws\almsrv\almsrv64x.exe and that the file exists. A path that contains a non-existent file confirms root cause 3.3 (stale registration from a prior install).
3. Inspect the BBI root folder. In Explorer, enable View → Show → Hidden items, then navigate to %ProgramData%\Siemens\. Right-click the SWS (or Automation License Manager) subfolder, choose Properties → Security → Advanced. The SYSTEM account must have Modify (not just Read & Execute) and the folder must NOT carry the read-only attribute. Do the same for the parent %ProgramData%\Siemens.
4. Test the write path manually. From an elevated command prompt:

   echo test > "%ProgramData%\Siemens\SWS\BBI\_write_test.tmp"
   del "%ProgramData%\Siemens\SWS\BBI\_write_test.tmp"

   If this fails with Access is denied or media is write protected, the OS layer is blocking the ALM before it can even start.
5. Verify the C++ runtime version. Open C:\Windows\System32\MSVCP140.dll, Properties → Details. The file version must be 14.30.x or newer (matching VC++ 2015–2022 Redist 14.30+). Also confirm VCRUNTIME140.dll and VCRUNTIME140_1.dll have the same major version. If any one is older, replace the runtime.
6. Check for folder redirection. In the properties of %ProgramData%\Siemens confirm the path is a local NTFS path. OneDrive, Offline Files, or GPO folder redirection can re-route ProgramData on some hardened images; if so, fix the GPO or unhook the redirection. Run fsutil reparsepoint query "%ProgramData%\Siemens\SWS" — a non-empty result indicates a OneDrive or Offline Files reparse point.
7. Capture a process monitor trace (optional). Download Sysinternals Process Monitor and filter for almsrv64x.exe. Look for RESULT = MEDIA_WRITE_PROTECTED on CreateFile or SetSecurityFile calls against the BBI folder — this confirms the OS layer is the blocker, not the ALM logic.

Step-by-Step Resolution

Apply the steps in this exact order. Skipping ahead — for example, only reinstalling the redistributable without resetting the BBI folder permissions — usually leaves the fault intact because the ALM service re-applies ACLs at start-up and fails again. The total downtime on a healthy workstation is about 25 minutes, dominated by the Visual C++ redistributable install and the mandatory reboot.

5.1 Pre-flight: stop the service and capture state

1. Open Services (services.msc), locate Automation License Manager, right-click and choose Stop. If Stop fails, kill the process from Task Manager (Details tab → almsrv64x.exe → End task).
2. Back up the existing BBI folder: xcopy /E /H /K "%ProgramData%\Siemens\SWS" "%BackupDrive%\ALM_SWS_Backup_%date%"
3. Back up the registry keys HKLM\SOFTWARE\Siemens\Automation License Manager and HKLM\SYSTEM\CurrentControlSet\Services\almsrv64x:

   reg export "HKLM\SOFTWARE\Siemens\Automation License Manager" "%BackupDrive%\ALM_reg_backup.reg"
   reg export "HKLM\SYSTEM\CurrentControlSet\Services\almsrv64x" "%BackupDrive%\almsrv64x_reg_backup.reg"

5.2 Repair the Visual C++ runtime

1. Download the latest Microsoft Visual C++ 2015–2022 Redistributable (x64).
2. Run the installer with Repair first. If repair is not offered, uninstall both x86 and x64 entries from Apps & Features, then install the x64 package fresh.
3. Reboot the workstation. Do not skip this — the kernel-mode loader caches the runtime paths until restart, and a 0xC0000005 raised from a cached-but-stale DLL will look identical to the original fault.
4. Confirm the runtime version: dir C:\Windows\System32\MSVCP140.dll should show file version 14.40.x or newer. Also verify VCRUNTIME140.dll and VCRUNTIME140_1.dll are present and at the same major version.

5.3 Reset the BBI root folder and program-data ACLs

1. Open an elevated PowerShell.
2. Clear the read-only bit on the Siemens data folders:

   $paths = @("$env:ProgramData\Siemens", "$env:ProgramData\Siemens\SWS", "$env:ProgramData\Siemens\Automation License Manager")
   foreach ($p in $paths) { if (Test-Path $p) { attrib -r $p /S /D } }

3. Re-grant the SYSTEM account modify rights on the BBI root:

   $acl = Get-Acl "$env:ProgramData\Siemens\SWS"
   $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("SYSTEM","Modify","ContainerInherit,ObjectInherit","None","Allow")
   $acl.AddAccessRule($rule)
   Set-Acl "$env:ProgramData\Siemens\SWS" $acl

4. If OneDrive is installed, exclude %ProgramData%\Siemens from the OneDrive managed-backup list: OneDrive → Settings → Sync and back up → Manage backup → Manage folders → exclude Siemens. OneDrive can substitute a reparse point that returns ERROR_WRITE_PROTECT to NTFS writers.
5. Re-run the manual write test from §4 step 4. It must succeed before you continue; if it fails, the OS layer (OneDrive, GPO, AV) is still blocking writes and the rest of the procedure will fail again.

5.4 Clean re-install of Automation License Manager

1. Open Apps & Features, uninstall Siemens Automation License Manager. If the uninstaller reports an error, use the Microsoft Program Install and Uninstall Troubleshooter to force-removal of the MSI entry.
2. Delete the residual service registration: sc delete "almsrv64x"
3. Delete the BBI folder manually only after the MSI is removed: Remove-Item -Recurse -Force "$env:ProgramData\Siemens\SWS" Do not delete %ProgramData%\Siemens\CoRt — that is the SIMATIC Common Runtime and is shared with TIA Portal.
4. Re-run the TIA Portal V19 setup as Administrator. When the ALM component prompts, choose Install/Update, not Repair, because repair reuses the broken ACL set.
5. Reboot. Verify sc qc "almsrv64x" now shows the V19 BINARY_PATH_NAME and that the file exists.

5.5 Service verification

1. Open services.msc. The Automation License Manager service should be present, with Startup type = Automatic (Delayed Start) and Status = Running.
2. From an elevated command prompt:

   sc query "almsrv64x"
      → STATE              : 4  RUNNING

3. Launch the ALM UI from the Start menu. The license list should populate within ~5 seconds; no error dialog should appear. If a dialog appears, the Event Viewer will hold a fresh Application Error event that you can correlate with the original Report ID acf3387c-ade4-43d8-af27-fd20fbf8fc88 — a different Report ID confirms a different root cause.

Verification Checklist

Alternative Solutions

If the primary procedure above does not resolve the failure, work through the alternatives in order. Each addresses a different corner case seen in field deployments, especially on Windows 10 Enterprise and LTSC images that have been hardened beyond the Siemens-supported baseline.

7.1 Install via the standalone ALM SP12 Upd2 package

When TIA Portal V19 is installed on a system where the OS layer is suspicious, install the ALM component from the standalone Siemens Automation License Manager V6.0 SP12 Upd 2 package first, verify the service, then run the TIA Portal V19 setup in Modify mode. This sequence prevents the TIA Portal installer from overwriting a working ALM with a partially copied binary. Pull the ALM standalone from the TIA Portal V19 media's Support directory or from the Siemens Industry Online Support download center using your Software Update Service (SUS) contract.

7.2 Windows 10 Enterprise / LTSC hardening

On Windows 10 Enterprise, LTSC, and on images that have had Credential Guard or Attack Surface Reduction Rules enabled, the ALM service sometimes inherits a restricted token that strips the SeLockMemoryPrivilege and the SeRestorePrivilege. Add the almsrv64x.exe to the ASR exclusion list and disable Credential Guard for the service account during installation. Re-enable protections after the service is operational. This is the most likely root cause on systems where the kompatool reports a clean compatibility but the service still crashes — the OS, not the ALM package, is the differentiator.

7.3 Replace MSVCP140.dll manually (last resort)

If the redistributable installer repeatedly fails, replace the DLL manually:

1. From a known-good Windows 10 22H2 system, copy C:\Windows\System32\MSVCP140.dll, VCRUNTIME140.dll, and VCRUNTIME140_1.dll to a USB drive.
2. On the target system, take ownership of the existing files:

   takeown /f C:\Windows\System32\MSVCP140.dll
   icacls "C:\Windows\System32\MSVCP140.dll" /grant Administrators:F

3. Replace the files from the USB, then re-secure them: icacls "C:\Windows\System32\MSVCP140.dll" /reset

7.4 Revert to ALM V5.6 (legacy only)

For SCADA/MES environments that have not yet migrated to TIA Portal V19, ALM V5.6 SPx is known to install cleanly on Windows 10 22H2 because it does not use the new BBI folder schema. The Siemens compatibility tool will warn that V5.6 is not approved for TIA Portal V19 — this is expected, and the V19 license keys still work against V5.6 servers (license key formats are forward-compatible across the V5.x and V6.x ALM line). Use this only as a hot-fix while the primary procedure is escalated to Siemens support; do not leave a V5.6 ALM paired with a V19 TIA Portal in production.

7.5 ALM error-code cross-reference

The following table maps the most common ALM failure symptoms to the underlying Windows event so that on-call engineers can triage from the Event Viewer alone.

Prevention and Pre-Installation Checklist

1. Windows image baseline. Before installing TIA Portal V19, confirm the OS is at Windows 10 22H2 build 19045 with all cumulative updates applied. Older builds (19041, 19042) have a higher rate of STATUS_ACCESS_VIOLATION in C++ runtime stream paths. Capture the build with winver and the build chain with wmic os get caption,version,buildnumber,osarchitecture.
2. OneDrive purge. Remove OneDrive synchronization from %ProgramData% before the TIA Portal install. The TIA Portal installer will not write to a OneDrive-managed ProgramData subtree — it will appear to succeed, but the next service start will fail with the same 0xC0000005.
3. Antivirus exclusions. Add the following paths to the AV exclusion list before installation: C:\Program Files\Common Files\Siemens\, %ProgramData%\Siemens\, and the installer scratch folder. Real-time file-system protection can return ERROR_WRITE_PROTECT to a service that is mid-write. This applies equally to Windows Defender, CrowdStrike, SentinelOne, and Trend Micro agents.
4. VC++ runtime pre-install. Install the latest VC++ 2015–2022 Redistributable (both x86 and x64) before running the TIA Portal setup. This pre-empts the partial-install race that produces the 0xC0000005.
5. Run as Administrator. Always launch the TIA Portal setup from an elevated command prompt, not from a file-manager double-click. UAC elevation is required for the ALM service to register correctly under LocalSystem. A non-elevated install will appear to succeed but will fail on the first service start.
6. Clean prior ALM. If a previous TIA Portal version is installed, run the older TIA Portal's Control Panel → Programs and Features → Uninstall and use the cleanup tool shipped with the TIA Portal setup media to remove residual service registrations before installing V19. Confirm with sc query almsrv64x that no service registration survives the uninstall.
7. Document the build. Record the exact ALM build (almsrv64x.exe version), the MSVCP140.dll file version, and the Windows build string in the commissioning log. When a future upgrade reintroduces a similar fault, this is the first data Siemens support will request.

Advanced Diagnostics

When the standard procedure does not resolve the fault, escalate to the following toolchain. Each tool gives a different layer of evidence — ProcMon shows what the service asked for, ProcDump shows what crashed, Dependency Walker shows what was linked, and Windows Event Forwarding shows what a fleet of identical machines is doing in aggregate.

9.1 ProcMon — System call trace

Filter Process Monitor for Process Name is almsrv64x.exe and Result is not SUCCESS. The first failing IO is almost always the BBI folder. If the failing operation is SetSecurityFile with result MEDIA_WRITE_PROTECTED, the OS layer (folders, GPO, AV) is the cause. If the failing operation is an std::ofstream::open deep in the call stack, the runtime DLL is the cause. Save the filter as a .PML file and attach it to the Siemens support ticket — the symbolicated stack is what the support engineer needs.

9.2 ProcDump — Crash dump capture

Install ProcDump and register it as the post-mortem debugger:

On the next service start, the crash dump is written to C:\CrashDumps\almsrv64x.exe-<pid>.dmp. Open the dump in WinDbg and run !analyze -v to obtain the exact exception context. The fault offset 0x00000000000126bf should resolve to std::filesystem::permissions inside MSVCP140.dll when the BBI ACL is the cause, or to std::ofstream::open when the runtime is the cause. The Report ID embedded in the event (e.g., acf3387c-ade4-43d8-af27-fd20fbf8fc88) is a deterministic hash of the faulting path and can be used to deduplicate faults across the fleet.

9.3 Dependency Walker — Import validation

Open almsrv64x.exe in Dependency Walker (x64) and verify that every import is resolved against the System32 MSVCP140.dll. A red icon against the runtime DLL indicates a mismatched architecture or a 32/64-bit side-by-side mix. Pay particular attention to api-ms-win-crt-runtime-l1-1-0.dll and api-ms-win-crt-stdio-l1-1-0.dll — these are the UCRT (Universal C Runtime) forwarders that MSVCP140.dll ultimately calls into.

9.4 Windows Event Forwarding for fleet triage

For multi-engineer deployments, configure a Windows Event Collector subscription that forwards Event ID 1000 (Application Error) and Event ID 7034 (Service terminated unexpectedly) to a central SIEM. The unique Report ID from the faulting event (for example, acf3387c-ade4-43d8-af27-fd20fbf8fc88) can be correlated with Siemens support tickets for faster root-cause confirmation across the fleet. Decode Windows system error codes server-side so the SIEM can auto-classify ERROR_WRITE_PROTECT (19) and ERROR_PROCESS_ABORTED (1067) without manual triage.

Siemens Support Escalation

When the fault persists after the primary procedure, gather the following artefacts and open a ticket at the Siemens Industry Online Support portal under the SIMATIC product tree. Attach everything in a single .zip named with the Report ID for traceability.

1. The full Application Error event text, including Report ID and module versions.
2. The sc qc almsrv64x output.
3. The output of kompatool for the affected TIA Portal / ALM combination.
4. The ProcMon filter file (.PML) covering the failed service start.
5. A full crash dump captured with ProcDump.
6. The exact Windows build string from winver (for example, Windows 10 Enterprise Version 22H2 (OS Build 19045.3324)).
7. The file-version details of MSVCP140.dll, VCRUNTIME140.dll, and VCRUNTIME140_1.dll.

Reference the internal Siemens entry for the V19 ALM compatibility note and the Automation License Manager V6.0 SP12 Upd2 release notes when filing; the Siemens support engineer will be able to cross-reference the exact almsrv64x.exe build 600.904.101.3 against the known-issue database. If the report is filed under the wrong product tree (for example, under TIA Portal instead of SIMATIC Automation License Manager), the SLA clock does not start — confirm the product tree is set to "SIMATIC Automation License Manager" before submission.

Frequently Asked Questions