Resolving Siemens ALM PlugIn SCP3 0x80090016 Error on 840D sl

Problem Summary

The Siemens Automation License Manager (ALM) raises the message "Cryptographic provider initialization failed (PlugIn SCP3 - 0x80090016)" during PCU boot on a SINUMERIK 840D sl system. The license service is unable to initialize its plug-in cryptographic layer, so license acquisition for SINUMERIK Operate, HMI-Pro, COM, and additional optional packages fails immediately after the operating system starts. End users see red status fields inside SINUMERIK Operate and the machine is unable to release option bits that depend on the local license stick or soft container.

This fault appears on the SINUMERIK PCU 50.x (Windows XP Embedded / Windows 7 Embedded Standard) and on PCU 50.5 with Windows 10 IoT LTSB. It is unrelated to license content, the CFast card, or the dongle hardware. The error is generated by the Microsoft CryptoAPI when the Microsoft Software Key Storage Provider (KSP) cannot enumerate the machine key set located under C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto (XP/embedded classic) or the corresponding %ProgramData%\Microsoft\Crypto location on newer PCU images. The ALM SCP3 plug-in uses this key set to sign and decrypt license containers, so any ACL damage, antivirus quarantine, or partial key-store corruption results in a startup-time CryptAcquireContext failure with HRESULT 0x80090016.

The error is logged in:

• %ALM_LOG_DIR%\almservice.log (typically C:\Program Files\Siemens\Automation License Manager\Bin\almservice.log)
• Windows Application Event Log: Source almservice, Event IDs 100, 200, 5000 with 0x80090016 in the data field
• SINUMERIK Operate diagnostics view: Diagnostics > Service Overview > Licenses shows the SCP3 plug-in as not loaded

Technical Background: ALM Plug-In SCP3 and Microsoft CryptoAPI

The SCP3 plug-in is the cryptographic service provider used by ALM to validate license keys signed with Microsoft's CryptoAPI. ALM versions 4.0 SP3 through 6.0 use SCP3 as the default provider for both signed soft containers (license files on disk) and CFast/USB license sticks. The plug-in is implemented in scp3.dll, registered as a Windows service dependency, and relies on a machine key set stored in the system-wide Crypto directory.

The Microsoft CryptoAPI key store layout is:

The MachineKeys directory contains files of the form {GUID} (e.g. d6b88a25-d3d3-4c2e-a4b3-1234567890ab) that represent individual key containers. Each container has a per-ACL that restricts Read, Write, and Delete to SYSTEM, Local Service, and the user account that originally created it. ALM runs under the almservice local account (or the configured service account) and must be able to enumerate and CryptAcquireContext against the machine-default provider for license validation.

Error code 0x80090016 is in the NTE-prefixed CryptoAPI HRESULT space (range 0x80090000 – 0x8009FFFF). The PlugIn SCP3 error path is generated when CryptAcquireContext returns a non-success NTSTATUS during the PlugInInitialize call. In the field, the most common triggering conditions are:

1. ACL on Crypto\MachineKeys has been changed and no longer grants Everyone or SERVICE enumeration rights.
2. An antivirus product (notably Kaspersky Endpoint Security) has placed a key container file in quarantine or replaced it with a quarantined.dat stub.
3. The folder has been re-created by a third-party cleanup tool without the original DACL.
4. A Windows update or embedded image restore has re-stamped permissions to the default, which on embedded SKUs does not include the Local Service SID needed by ALM.

Root Cause

On a freshly imaged or maintained 840D sl PCU, the Crypto directory under All Users\Application Data holds the default DACL that grants Everyone:Read and SYSTEM:Full Control. ALM's almservice relies on the explicit ACE for Everyone (or, in hardened images, for the dedicated service SID) to enumerate the MachineKeys directory at startup. The moment the ACE is removed, the CryptAcquireContext call inside SCP3 fails with a CryptoAPI error, which is wrapped into 0x80090016 and surfaced as a plug-in initialization failure.

In the case that triggered this article, the issue was compounded by Kaspersky Endpoint Security, which had hooked the Crypt32 and SCP3 libraries at boot. The Kaspersky self-protection module quarantined one of the machine key containers because it matched a heuristic signature, which removed the file from MachineKeys and forced the ALM service into a fail-state at startup. Reinstalling ALM 4.0 SP5 did not fix the issue because the underlying Crypto directory was still in a corrupted or inaccessible state.

Diagnostic Workflow

Before applying the resolution, run the following checks to confirm that the issue is in the key store and not in the ALM installation, license stick, or SINUMERIK Operate package set.

1. Capture the exact event log entry. Open Event Viewer on the PCU, navigate to Windows Logs > Application, and locate the almservice source entry containing the hex code. Note the Event ID and the user account referenced in the message.
2. Inspect the ALM service log. The file almservice.log in the ALM bin directory contains a line of the form:
   PlugInInitialize: SCP3 failed, hr=0x80090016, provType=1
3. Check the file system. Open an elevated command prompt and run icacls "%AllUsersProfile%\Application Data\Microsoft\Crypto" (XP/embedded) or icacls "%ProgramData%\Microsoft\Crypto" (Win 7/10). The output must include BUILTIN\Users with at least (R) or NT SERVICE\almservice:(R).
4. Verify the MachineKeys contents. List the directory MachineKeys. The presence of quarantined.dat, zero-byte files, or an empty folder indicates antivirus or backup-restore corruption.
5. Confirm the plug-in is registered. Run reg query "HKLM\SOFTWARE\Siemens\Automation License Manager\PlugIns" /s and verify that SCP3 is present and points to %ALM_BIN%\scp3.dll.

Step-by-Step Resolution

The remediation path is split into three phases: stop the ALM service, repair or rebuild the key-store permissions, then restart. Always perform the work from a SINUMERIK administrator account (member of the Siemens Administrators local group) and ensure the PCU is in a quiet, non-production state because the license manager is required to be stopped before touching the Crypto directory.

Phase 1 – Stop ALM and Capture State

1. Open a command prompt as administrator.
2. Stop the service:
   net stop almservice
3. Stop any dependent processes that may still hold handles to the Crypto directory:
   taskkill /F /IM almgui.exe
taskkill /F /IM sinumerik_operate.exe
4. Make a safety copy of the entire Crypto directory before any modification:
   xcopy /E /H /K "%AllUsersProfile%\Application Data\Microsoft\Crypto" "D:\Backup\Crypto_%date:~-4%%date:~3,2%%date:~0,2%\"
   (On Win 7/10 PCU 50.5 use %ProgramData%\Microsoft\Crypto.)

Phase 2 – Repair the Crypto Directory ACL

If you want to keep the existing machine keys, fix the ACL on the directory and the MachineKeys subdirectory. Use the explicit form below for Windows XP Embedded / Windows 7 Embedded SKUs (the default OS on PCU 50.x).

1. Reset the DACL on the parent Crypto directory and propagate the inheritance:
   icacls "%AllUsersProfile%\Application Data\Microsoft\Crypto" /reset /T
2. Add the Everyone principal with Read permission (the System account is already present after the reset):
   icacls "%AllUsersProfile%\Application Data\Microsoft\Crypto" /grant Everyone:(OI)(CI)RX
3. On the MachineKeys subdirectory grant Everyone the same rights and ensure SYSTEM retains Full Control:
   icacls "%AllUsersProfile%\Application Data\Microsoft\Crypto\MachineKeys" /grant Everyone:(R) /T
icacls "%AllUsersProfile%\Application Data\Microsoft\Crypto\MachineKeys" /grant System:(F) /T
4. Verify:
   icacls "%AllUsersProfile%\Application Data\Microsoft\Crypto\MachineKeys\*
   Each container file should list at least SYSTEM:(F) and BUILTIN\Users:(R).

Phase 2B – Rebuild the Machine Key Set (When ACL Repair Fails)

If the ALM log keeps reporting 0x80090016 after the ACL reset, the key containers themselves are damaged. The supported procedure on SINUMERIK PCU 50.x is to delete the entire Crypto directory tree and let Windows and ALM regenerate it on the next boot. License sticks are not affected by this action because their keys live in the dongle hardware, not in MachineKeys. Soft containers in the ALM licenses directory are also untouched.

1. Confirm the ALM service is stopped (Phase 1).
2. Delete the directory:
   rmdir /S /Q "%AllUsersProfile%\Application Data\Microsoft\Crypto"
3. Reboot the PCU. Windows recreates Crypto and MachineKeys with the default DACL, and ALM regenerates its plug-in key set on first start.
4. Open ALM View (Start > Siemens Automation > License Manager) and confirm the SCP3 plug-in shows OK in the status column.

Phase 3 – Restart ALM and Verify

1. Start the service:
   net start almservice
2. Confirm the service is running:
   sc query almservice → state must be RUNNING, exit code 0.
3. Open Event Viewer > Application. The almservice source must report PlugIn SCP3 loaded with no 0x80090016 entries.
4. In SINUMERIK Operate, navigate to Diagnostics > Service Overview > Licenses. All licensed axes and options must be marked active with green status indicators.

Verification Checklist

Antivirus Interference: The Kaspersky-Specific Caveat

Kaspersky Endpoint Security 10 SP2 MR3 and later, as well as Kaspersky Security 11, hooks the Crypt32 DLL and a number of CryptoAPI entry points as part of its self-protection subsystem. On an 840D sl PCU that is shut down hard or that runs an aggressive scan during boot, the Kaspersky self-protection driver can:

• Quarantine a key container file in MachineKeys because of a heuristic signature that triggers on RSA key blobs.
• Replace the original scp3.dll with a shadow copy during the pre-boot phase, breaking the integrity signature that ALM performs on load.
• Lock the Crypto directory against enumeration from local service accounts, which leads to the same 0x80090016 error.

Recommended actions for installations where Kaspersky is mandatory:

1. Add the entire ALM installation path (default C:\Program Files\Siemens\Automation License Manager) to the Kaspersky trusted applications list with the Do not scan opened files and Do not monitor application activity options enabled.
2. Add the Crypto directory and all its subdirectories to the exclusions list of both the File Anti-Virus module and the Behavior Detection module.
3. Disable the System Watcher component on the PCU if it is not required by corporate policy; it is the component that performs the heuristic checks on key containers.
4. After applying the exclusions, run the Phase 2B rebuild so that all quarantined or shadowed files are replaced with clean copies.

The original problem report on the field was resolved simply by closing Kaspersky, repairing the Crypto DACL, and rebooting. The user explicitly reported that reinstalling ALM was not necessary and that a clean reboot of the PCU (not just the ALM service) was sufficient to clear the fault.

Firmware and Software Version Notes

ALM 4.0 SP5 is the version explicitly named in the source fault report. Later versions of ALM (5.x, 6.x) replace SCP3 with the SCP4 plug-in, which uses the Microsoft Key Storage Provider (CNG) instead of the legacy CryptoAPI. The directory layout and the underlying DACL requirements are essentially the same, and the same Phase 2 procedure resolves the equivalent 0x80090016 error from SCP4 as well. Always confirm the running ALM build by reading the About dialog in ALM View before applying the fix, because some SINUMERIK images (notably the HMI-Pro sl variants) ship a customized 4.0 SP5 with an OEM signature check that requires the original installation media for a clean reinstall.

When to Reinstall ALM (and When Not To)

The field report confirms that reinstalling ALM 4.0 SP5 is not necessary when the underlying problem is a corrupted or inaccessible Crypto directory. The ALM installation itself is intact; the SCP3 plug-in fails because it cannot read a system-level key set. Reinstalling the same ALM build on top of the same corrupt key set simply re-runs the same failing CryptAcquireContext call and produces the same error.

Reinstall is justified only when:

1. The scp3.dll file is missing or has a binary mismatch (compare the SHA-256 hash with the original installation media).
2. The ALM service fails to start with error 1053 (service did not respond) which indicates a missing dependency rather than a key-store issue.
3. The license container file in C:\Program Files\Siemens\Automation License Manager\Licenses is corrupted. In that case the PlugInInitialize call succeeds but a subsequent CryptDecrypt call returns the same 0x80090016 HRESULT.
4. A SINUMERIK software update explicitly requires a new ALM build (consult the Siemens Industry Online Support release notes).

When reinstalling, use the Siemens Automation License Manager Setup from the matching SINUMERIK service pack, not the generic Siemens Automation Tools installer. The SINUMERIK installer registers the service under the correct local account (LocalSystem on 4.0 SP5, NT SERVICE\almservice on 5.x and later) and writes the correct plug-in registry entries.

Preventive Measures

1. Image the Crypto directory with the rest of the PCU image. When you build a golden PCU 50.x image, capture the Crypto directory with all DACLs. Use robocopy /MIR /SEC /SECFIX rather than xcopy to preserve the security descriptors when restoring to other PCUs.
2. Lock the directory against user modification. Apply a Group Policy preference that prevents Users from writing to %AllUsersProfile%\Application Data\Microsoft\Crypto on the PCU. Embedded GPOs are supported on Windows XP Embedded with the Secure Boot feature enabled.
3. Configure the antivirus exclusions described above before the first commissioning of the machine, not after the first fault. Most installations discover the issue only after a hard shutdown of the PCU that triggers a full Kaspersky scan.
4. Schedule a monthly health check that runs the following script and emails the result to maintenance:
   sc query almservice | findstr STATE
findstr /C:"0x80090016" "%ALM_BIN%\almservice.log"
icacls "%AllUsersProfile%\Application Data\Microsoft\Crypto" | findstr Everyone
   If any of the three checks fail, raise a maintenance ticket before the next production shift.
5. Document the OEM customizations. If the SINUMERIK image includes OEM-signed license containers (e.g. for a machine builder's option bits), back up the Licenses directory as well, and store it together with the Crypto backup on the same media.

Related Errors and How They Differ

When the ALM log shows any of the other hex codes in this table, apply the same Phase 2 DACL repair as a first step. If the error persists, escalate to a license-container rebuild or ALM reinstall as described in the previous section.

Files and Registry Touched by the Resolution

Safety and Production Considerations

Related Siemens Documentation and Knowledge Base

• SINUMERIK 840D sl Operator Components Manual (PCU 50.x) – License Manager section
• Automation License Manager V4.0 SP5 Release Notes and Installation Guide
• SINUMERIK 840D sl Commissioning Manual – Software Update and Image Restore
• SINUMERIK Operate V5.x Service Manual – License Diagnostics
• Microsoft CryptoAPI: CryptAcquireContext and Key Storage Providers
• Microsoft Key Storage Provider (KSP) reference

FAQ