Resolving TIA Portal V18 ALM Error 1460 Service Start Failure

1. Symptom Description

After installing or upgrading to TIA Portal V18 (including V18 Update 5), the Siemens Automation License Manager (ALM) service fails to start. The installer displays the message "Failed to start the service, Error 1460..." and rolls back the ALM component. The same failure repeats when ALM is reinstalled standalone using either ALM_V6.0_SP12_Upd3 or ALM_V6.2_SP1.

Windows event log records the following entries:

• Log: Application
• Source: ALM (or ALMService)
• Message: API = Create GlobalData, os error code = 0, message = Could not initialize Plugins (CommonData).

Windows error 1460 is the Win32 ERROR_TIMEOUT status returned by the Service Control Manager when a service does not signal SERVICE_RUNNING inside the SCM start timeout (default 30,000 ms). The underlying ALM plugin initialization is failing before the service can handshake with the SCM, so the timeout is a downstream symptom rather than the root cause.

2. Affected Versions and Environments

3. Root Cause Analysis

The 1460 timeout is a single symptom with multiple independent root causes. Treat the following list as a diagnostic checklist and address each layer before reinstalling.

1. Antivirus / EDR filter driver conflict. ALM requires raw read access to its plugin directory and to HKLM\Software\Siemens\Automation License Manager. Symantec Endpoint Protection 14.x injects a Windows Filtering Platform (WFP) callout driver (sysfer.dll, symefasi.dll) that is not removed by the standard uninstaller. Even with the GUI disabled and the service stopped, the kernel driver remains loaded.
2. Corrupted ALM database (almdb). After TIA V15 uninstall, the database at C:\ProgramData\Siemens\Automation License Manager\almdb may hold orphaned license references that the V18 plugin chain cannot parse.
3. Mismatched ALM service registration. Downgrading from ALM V6.2 SP1 to V6.0 SP12 (or vice versa) leaves stale service entries under HKLM\SYSTEM\CurrentControlSet\Services\almsrv referencing DLLs that no longer exist.
4. Pending File Rename Operations. Files locked during the V15 removal (commonly Siemens.Automation.LicenseManager.dll) are queued in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations. The next ALM installer cannot overwrite them and silently aborts the plugin registration step.
5. DCOM / COM+ activation failure. ALM uses COM for inter-process license dispatch. If comsvcs.dll is unregistered or the COM+ System Application service is disabled, Create GlobalData returns to ALM with a NULL plugin handle and the service hangs.
6. .NET runtime mismatch. TIA V18 requires .NET Framework 4.8. A V15-era .NET 4.6 targeting pack can prevent Siemens.Alm.CommonData.dll from loading under the service host.
7. Local System account privilege loss. Group policy may have stripped SeLockMemoryPrivilege or SeImpersonatePrivilege from the Local System account via secpol.msc → Local Policies → User Rights Assignment.
8. Windows Defender Credential Guard. Blocks ALM's Logon as service assertion when the SCM tries to start the ALM service under LocalSystem on UEFI-secured hosts.

4. Event Viewer Diagnostics

Before changing anything, capture the full state of the failure so you can confirm the root cause.

1. Open eventvwr.msc.
2. Navigate to Windows Logs → Application and filter by Source = ALM. Capture the timestamp of the Create GlobalData message.
3. Navigate to Windows Logs → System and filter by Source = Service Control Manager. Look for Event IDs 7000 (service failed to start), 7009 (timeout on start), and 7011 (transactional dependency timeout).
4. Export both filtered logs to .evtx for diff against the post-fix baseline.

A confirmed baseline signature for this fault is:

Log Name:      Application
Source:        ALM
Event ID:      0
Level:         Error
Description:   API = Create GlobalData, os error code = 0,
              message = Could not initialize Plugins (CommonData).

Log Name:      System
Source:        Service Control Manager
Event ID:      7009
Description:   A timeout was reached (30000 milliseconds) while waiting for
              the Siemens ALM service to connect.

5. Pre-flight Checklist

Confirm each item before reinstalling ALM. Skipping a single item here is the most common reason the same 1460 timeout reappears after a "clean" reinstall.

6. Solution A: Remove Antivirus Filter Drivers

Symantec Endpoint Protection 14.x is the most common culprit. The standard Add/Remove Programs uninstall leaves residual drivers and the Tamper Protection daemon. Use the vendor's removal tool, not the GUI uninstaller.

1. Download the current CleanWipe removal utility from the Symantec Broadcom support portal. Verify the downloaded package against the SHA-256 published on the portal before extracting.
2. Boot Windows into Safe Mode with Networking (msconfig → Boot → Safe boot → Network).
3. Run CleanWipe with the default selection of components. Confirm reboot when prompted.
4. After reboot, confirm the WFP callout driver is gone:

sc query Sense
sc query smcinst
sc query SYMEVENT
sc query SymEFASI

Each command should return The specified service does not exist. If SYMEVENT or SymEFASI still report STOPPED, manually delete the corresponding HKLM\SYSTEM\CurrentControlSet\Services\<name> key and remove %ProgramFiles%\Symantec\* and %ProgramFiles(x86)%\Symantec\*.

5. Open wf.msc (Windows Firewall with Advanced Security). Under Monitoring → Callouts, verify no third-party callouts remain. Any entry pointing to a Symantec or other EDR DLL must be removed via its vendor's cleanup utility.
6. Reboot and re-run the Pre-flight Checklist items 2, 3, and 4.

7. Solution B: Clean Reinstall of Automation License Manager

After the AV drivers are gone, perform a documented uninstall and reinstall.

1. Open appwiz.cpl and uninstall in this exact order: SIMATIC Automation License Manager, then any Siemens PLM License Server entries, then any remaining Siemens entries.
2. Stop and remove the ALM service if it still exists:

sc stop almsrv
sc delete almsrv

3. Delete the ALM data directory:

rd /s /q "C:\ProgramData\Siemens\Automation License Manager"
rd /s /q "C:\Program Files\Siemens\Automation License Manager"
rd /s /q "C:\Program Files (x86)\Siemens\Automation License Manager"

4. Remove orphaned registry keys (export first for rollback):

reg delete "HKLM\SOFTWARE\Siemens\Automation License Manager" /f
reg delete "HKLM\SOFTWARE\WOW6432Node\Siemens\Automation License Manager" /f
reg delete "HKLM\SYSTEM\CurrentControlSet\Services\almsrv" /f

5. Reboot. Verify Pre-flight Checklist items 2 and 3 pass.
6. Launch the TIA V18 setup disk or the standalone ALM .exe and install only the Automation License Manager component. Confirm the service starts:

sc query almsrv

The expected result is STATE : 4 RUNNING. If the service starts and stays running for 60 seconds without manual intervention, proceed to verification.

8. Solution C: Repair Windows Service Configuration

If the service refuses to start even after a clean reinstall, rebuild the SCM entry by hand rather than relying on the installer.

1. Recreate the service with explicit dependencies:

sc create almsrv binPath= "C:\Program Files\Siemens\Automation License Manager\almsrv.exe" \
   DisplayName= "Siemens ALM Service" \
   start= auto depend= "RPCSS/Eventlog"

2. Confirm the LocalSystem account and that no password is required (it is a built-in account):

sc config almsrv obj= "LocalSystem" password= ""

3. Start the service with a 60 second timeout rather than the SCM default of 30:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\almsrv" /v WaitHint /t REG_DWORD /d 60000 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\almsrv" /v Start /t REG_DWORD /d 2 /f
sc start almsrv

4. If the service still times out, enable the ALM verbose log and inspect:

reg add "HKLM\SOFTWARE\Siemens\Automation License Manager" /v TraceLevel /t REG_DWORD /d 4 /f
reg add "HKLM\SOFTWARE\Siemens\Automation License Manager" /v TraceFile /t REG_SZ /d "C:\ProgramData\Siemens\Automation License Manager\alm.trc" /f
sc stop almsrv
sc start almsrv

Open the trace file and search for the Create GlobalData token. The line immediately above it lists the plugin that failed to load (most often CommonDataPlugin.dll or LicenseServerPlugin.dll).

9. Solution D: Repair Component Dependencies

The CommonData plugin chain depends on .NET Framework 4.8 and on the COM+ catalog. Both must be intact.

1. Repair .NET Framework 4.8 with the official repair tool (Microsoft .NET Framework Repair Tool). Reboot when prompted.
2. Reset the COM+ catalog:

net stop COMSysApp
net start COMSysApp
msdtc -uninstall
msdtc -install
net start msdtc

3. Re-register the ALM COM components:

cd /d "C:\Program Files\Siemens\Automation License Manager"
regsvr32 /u Siemens.Alm.CommonData.dll
regsvr32 Siemens.Alm.CommonData.dll
regsvr32 Siemens.Alm.LicenseServer.dll
regsvr32 Siemens.Alm.Client.dll

4. Restart the ALM service and verify with sc query almsrv.

10. Solution E: Resolve Pending File Rename / Reboot State

If the V15 uninstall queued file replacements that have not been committed, every subsequent ALM install will fail because it cannot overwrite Siemens.Alm.*.dll.

1. Inspect the queue:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v PendingFileRenameOperations

2. Process the queue by rebooting twice. The first reboot applies pending deletes, the second applies pending renames. Verify the value is empty:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v PendingFileRenameOperations

Expected: ERROR: The system was unable to find the specified registry key or value.

3. If the value persists, manually export and clear it (last resort). Reboot immediately afterward, then run an in-place DISM /Online /Cleanup-Image /RestoreHealth to repair the resulting inconsistency.

11. Verification

After the chosen solution completes, validate in this order.

1. Service state. sc query almsrv shows STATE : 4 RUNNING and the WIN32_EXIT_CODE : 0 field is 0.
2. ALM GUI. Launch almsrv.exe /gui from the install directory. The Manager window must appear within 5 seconds without the License Manager could not be started banner.
3. TIA integration. Start TIA Portal V18 and open Options → License Management. The ALM server must appear in the discovery list within 3 seconds. If the TIA-side timeout ("Automation License Manager Service has not been started!") still triggers, the LocalSystem account needs the Log on as a service right reasserted via secpol.msc.
4. Distributed license server test. From a second engineering station, point to the repaired server using almsrv.exe /connect <host>. A successful round trip confirms the service is listening on its default TCP port (4410 for ALM V5.x legacy, dynamic ephemeral for V6.x).
5. Reboot persistence. Reboot the host. Confirm ALM auto-starts under SCM and that the TIA Portal license state survives the reboot without manual service start.

12. Prevention and Best Practices

• Before every TIA upgrade, consult the Siemens Compatibility Tool for Automation and Drive Technology. Only AV products explicitly listed as compatible for the target TIA version may remain installed.
• Always uninstall the previous TIA version through the official setup's Modify / Uninstall wizard. Manual deletion of the install directory bypasses the PendingFileRenameOperations logic and leaves stale references.
• Schedule a reboot immediately after any TIA uninstall. Multiple reboots are sometimes required to fully drain the rename queue.
• Maintain a documented image of the engineering workstation with the AV exclusion list applied before ALM is installed. Required exclusions: C:\Program Files\Siemens\Automation License Manager\, C:\ProgramData\Siemens\Automation License Manager\, and the almsrv.exe process.
• Capture a baseline of the Pre-flight Checklist items after every successful TIA installation. Store the sc qc output and the registry export alongside the engineering workstation documentation.

13. FAQ