Resolving Siemens COMOS Runtime Check License Errors

Overview of the COMOS Runtime Check Error

The "COMOS runtime check" error is one of the most common license enforcement messages encountered by administrators of Siemens COMOS engineering platforms. The dialog appears when the COMOS application attempts to validate a feature entitlement at startup or while loading a project, and the local license service either cannot be reached, cannot identify the bound hardware, or has lost its authenticated session with a network-based license authority. The visible symptom is a modal dialog with the message text indicating that the license check has failed; the underlying failure has at least three well-documented causes: missing USB hardware key, lost network connection to the Comos License Server (CLS), or a non-green CLS service status.

Because COMOS licenses are bound to either a USB dongle (CodeMeter or WIBU-SYSTEMS depending on version) or to a server-issued license token, even a transient failure in any of the protection layers produces the same dialog. The error is therefore a symptom, not a diagnosis. The troubleshooting discipline is to eliminate each of the three license paths in a controlled sequence before opening a Siemens support ticket.

Affected COMOS Versions and License Models

COMOS licenses are issued in two principal forms, and the runtime check applies to both. The version of the COMOS application determines which license model is enforced, but the runtime check dialog wording is consistent across releases.

For the official product index and version compatibility, refer to the Siemens COMOS product information entry on SiePortal. The COMOS platform runs as a Windows client application on Windows 10 / Windows 11 or Windows Server 2016 / 2019 / 2022; the runtime check uses the local CodeMeter Runtime service and, when configured, the CLS TCP service.

Root Cause Categories

When the dialog appears for "a few users while it was working for others," the cause is almost always environmental rather than application-level. The COMOS client code is the same binary on every workstation; what differs is the license path. Siemens support and the official COMOS installation manual identify the following root cause groups:

1. Local USB dongle not detected. The CodeMeter Runtime service is not running, the dongle driver has been blocked by Windows User Account Control or an enterprise security policy, or the dongle has been physically disconnected from the workstation.
2. CodeMeter Runtime version mismatch. The COMOS release is bound to a specific CodeMeter Runtime build; an upgrade pushed by IT or a downgrade after a workstation re-image can render the dongle unreadable even though the hardware is present.
3. Network license path failure. The workstation cannot reach the CLS host, the TCP port used by CLS (default 22350) is blocked, or DNS resolution of the CLS hostname fails.
4. CLS service not healthy. The Comos License Server service on the central host is stopped, crashed, or running with a license pool that has been exhausted or expired.
5. Local configuration drift. A user profile copied from a working station or a Group Policy Object has redirected the license search to a CLS that no longer exists.

Diagnostic Procedure: Confirm Which License Path Is Active

Before changing anything, identify whether the affected user is configured for a USB dongle or a network CLS. The COMOS installation writes a registry record and a configuration entry that reveals the active license path.

1. Open the COMOS client on a known-working workstation and on an affected workstation.
2. In the COMOS menu, choose Extras > License information (or the equivalent in localized builds) and capture the displayed license type, license server name, and license feature name.
3. On the affected workstation, open the Windows Registry Editor (regedit) and inspect the key HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Siemens\COMOS\<version>\Licensing. The values LicenseServer, LicenseType, and LocalDongle define the active path.
4. Compare the entries between working and failing stations. Any divergence indicates where to focus.

If the COMOS log directory contains a fresh ComosLicense.log, open it. The log records the time of each license check, the target host or dongle, and the failure reason in human-readable form. The log is the single best source for the actual error string reported by the runtime check dialog.

Resolving the USB Dongle Path

When the affected workstation is licensed by a local USB dongle, the runtime check dialog is generated by the CodeMeter Runtime service. Validate the path with the following steps.

1. Verify the dongle is physically inserted and that the workstation's USB hub has not been disabled. Try a different USB port, preferably one directly attached to the chipset rather than through a USB extender.
2. Open the Windows Services console (services.msc) and confirm the CodeMeter Runtime Server service is in state Running and its startup type is Automatic. If the service is stopped, start it manually and re-launch COMOS.
3. Open the CodeMeter Control Center from the Start menu and verify the dongle is listed. The WIBU-SYSTEMS hardware key should appear with a non-empty License entry and the correct Serial Number. If the device is listed but the license is empty, the firmware container is locked or has been reset.
4. Confirm the CodeMeter Runtime version. Each COMOS release supports a defined range of CodeMeter builds; consult the COMOS installation manual for the matrix. If the installed version is outside that range, install the build that matches the COMOS version.
5. Check whether an enterprise security product (Defender Application Control, AppLocker, Trellix, Trend Micro) is blocking the CodeMeter device driver. The driver requires wibukey.sys / CodeMeter64.sys to load; an unsigned-driver block or a kernel-isolation block prevents the dongle from being read.

Resolving the Comos License Server (CLS) Path

When the workstation is licensed through a CLS, the runtime check dialog is generated by the network license client embedded in COMOS. Three things must be true: the workstation must be able to open a TCP session to the CLS host, the CLS service must be running and reachable, and the CLS must have an unused license for the feature the user is opening.

1. On the affected workstation, open a command prompt and execute telnet <CLS-hostname> 22350 (substitute the actual CLS hostname or IP address). A successful TCP connection produces a blank screen; a refused or timed-out connection confirms a network-layer problem.
2. If the connection fails, validate name resolution with nslookup <CLS-hostname>. Add a manual HOSTS entry or correct the DNS record.
3. If the connection succeeds, open the CLS web console (typically https://<CLS-hostname>:8443 or the URL provided by the COMOS administrator). Confirm the traffic light indicator at the top of the console is green. A yellow state indicates a license is being checked out but the pool is near exhaustion; a red state indicates the service is stopped or no licenses are available.
4. On the CLS host itself, open the Services console and confirm the Comos License Server service is running. The service depends on the WIBU CodeMeter License Server component; if the CodeMeter service is stopped, the CLS will report a red traffic light even though its own process is alive.
5. Check the CLS log directory. Entries for "license check-out failed" combined with "all licenses in use" confirm a license pool shortage. Increase the pool size in the CLS web console or remove a checked-out but idle session.

Local Configuration Drift and Group Policy Effects

A common cause of "works for some users, fails for others" is local configuration drift. COMOS stores the license server name in the user profile as well as in the machine-wide registry. When a user profile is copied from a working station, or a Group Policy Object pre-populates the license setting, the workstation may be pointing at a CLS that does not exist in the new network. The runtime check dialog then appears immediately on COMOS startup.

1. Inspect %APPDATA%\Siemens\COMOS\<version>\LicenseConfig.xml for a hard-coded server entry that overrides the registry.
2. Compare the COMOS environment variable COMOS_LICENSE_SERVER across affected and unaffected users. Remove any value that points to a deprecated host.
3. If a Group Policy template for COMOS has been deployed, re-run gpupdate /force on the affected workstation and verify the policy result with gpresult /h gp.html.
4. Clear the local COMOS license cache: stop the CodeMeter Runtime, rename %PROGRAMDATA%\CodeMeter\Cache, restart the service, and re-launch COMOS. The cache can retain an outdated server reference even after the registry is corrected.

Capturing Evidence for Siemens Support

When the standard diagnostics do not produce a green traffic light, the next step is to open a ticket with Siemens Industry Online Support. The COMOS support team requires specific files to reproduce or simulate the issue. Assemble the following evidence before submitting:

1. The ComosLicense.log from the affected workstation covering at least one full COMOS start and the failed license check.
2. The CodeMeter trace files generated by enabling verbose logging: in the CodeMeter Control Center, choose File > Settings > Tracing, enable file tracing, reproduce the issue, and attach the resulting .trace file.
3. The output of wmic csproduct get name, identifyingnumber and systeminfo from the affected workstation to confirm hardware and Windows build.
4. The COMOS version string and the patch level: launch COMOS once, choose Help > About, and capture the full version banner including build number.
5. The CLS license inventory report: in the CLS web console, export the license pool and the active sessions list.

Use the Siemens SiePortal support entry at support.industry.siemens.com to open a Service Request. Attach the files inside the ticket rather than posting them in public channels because license tokens and dongle serial numbers must be kept private.

Verification After Resolution

After applying a fix, validate the runtime check is no longer triggered. The validation must be performed on the originally affected workstation, with the same user account, and against the same COMOS project the user was trying to open when the dialog appeared.

1. Launch COMOS and observe the splash screen. A clean splash without the runtime check dialog is the first indicator.
2. Open the project that previously triggered the dialog. The project should load without a license warning and the Extras > License information panel should display the expected feature name with a Valid indicator.
3. From the same workstation, run LicenseClient -test (the command-line probe shipped with COMOS) to confirm the license check returns success independent of the GUI path.
4. On the CLS, if used, confirm the session is recorded in the active sessions list and the traffic light remains green for the duration of the work session.
5. Document the change in the change-management system: license server rename, dongle replacement, driver upgrade, or registry correction. Future incidents with the same symptom should be resolvable from the documentation alone.

Preventive Measures for Multi-User COMOS Environments

Once a root cause is identified, harden the environment so the same failure mode does not recur. The measures below are appropriate for any multi-user COMOS deployment that combines dongle-licensed and CLS-licensed workstations.

• Pin CodeMeter Runtime version. Distribute the CodeMeter Runtime build that matches the COMOS release through a managed software deployment. Block automatic updates that might deliver an incompatible runtime.
• Mirror CLS licensing. Operate the CLS on a host with redundant power and storage. Schedule a daily health check that emails the traffic-light status to the IT operations team.
• Reserve license pool. Configure the CLS with a safety margin in the license pool so brief check-out contention does not exhaust the pool and cause transient runtime check failures for all users.
• Document license topology. Maintain a single source of truth for which workstation is bound to which dongle serial number, and which user groups are routed to which CLS. Distribute the document to second-level support.
• Use Group Policy for license server name. Instead of leaving the license server name in the user profile, push it through a GPO preference so profile copy operations cannot redirect the license path.

Troubleshooting Matrix