CodeMeter: why your FactoryTalk activations vanish, and the order to check things in

September 07, 2026
Diagram of FactoryTalk Activation Manager sitting above the CodeMeter runtime service and its four license container types
Published on  Updated on  

The call always sounds the same. Studio 5000 opened fine on Friday, nobody went near the machine over the weekend, and Monday morning there are no activations at all. Or FactoryTalk Activation Manager throws an error before it finishes drawing its window. Almost none of those turn out to be a lost license. It is the layer underneath that stopped handing it over, and there are about five reasons why. Here is what CodeMeter is actually doing on that PC, which failures are real, and the order I work through them in.

What CodeMeter is doing on your engineering PC

CodeMeter is licensing software from Wibu-Systems, a private German company out of Karlsruhe. Rockwell does not own it and did not write it, it licenses it, the same way CODESYS, Aveva, Cognex, Delta, Win-911 and Siemens do for some of their products. Put two of those on one engineering PC and each arrives with its own copy of the same licensing runtime. That is where a lot of this trouble starts.

Rockwell's older system was Flexera, a plain-text .lic file you could open in Notepad and, with some effort, defeat. The replacement is signed, encrypted containers. Both can sit on one machine at once, which is why FactoryTalk Activation Manager carries a Use CodeMeter First checkbox in its advanced server settings: when a Flexera activation and an encrypted one exist for the same feature name, that box decides which the software takes.

Three pieces get installed: a runtime service that holds the licenses and answers the network, Control Center that lists the containers on this machine, and WebAdmin for looking at them in detail. FactoryTalk Activation Manager sits on top as a separate Rockwell layer, asking the service what it has. Two layers, and either can be the broken one. Worth holding onto while you stare at an empty activation list.

Which container the license actually sits in

Find out where the license physically lives before changing anything. Four options, and they fail in completely different ways.

Container

Where the license lives

What kills it

CmDongle (CmStick, CmCard)

In a smart card chip inside the USB stick or memory card. The secret keys never leave the unit

Losing or damaging the dongle. There is no software recovery

Software license (CmActLicense)

An encrypted file on the PC, bound to a hardware fingerprint of that PC

Hardware changes, VM snapshot rollback, antivirus or backup touching the license folder, some Windows updates

Network license server

A dongle or software license on one server, handed out to clients over the LAN

Run Network Server left unchecked, port 22350 closed, server offline

CmCloudLicense

On Wibu's servers, tied to a user rather than to a machine

No route out to the internet

 

Rockwell's dongles are the 9509 family: 9509-USB-DONG and 9509-USB-DONG2, the CmStick versions 9509-CMSTICKC (compact, no storage) and 9509-CMSTICK8 with 8 GB on board, plus 9509-CMSDCD4 and 9509-CMSDMICRO for SD and microSD. Assigned activations land in C:\Users\Public\Documents\Rockwell Automation\Activations.

Control Center tells you which case you are in about three seconds after it opens. A red container with a broken symbol puts you in the second row.

Diagram showing how a VM snapshot rollback breaks the SmartBind hardware fingerprint of a CodeMeter license

A rollback rewinds part of the fingerprint while everything else moved on. That is why the license does not come back.

The VM problem, and why a snapshot rollback is a one-way trip

If the Rockwell software runs in a virtual machine, read this part twice. Roll that VM back to a snapshot and the CodeMeter activation inside it is usually gone. Not broken and repairable. Gone.

A software license gets tied to the machine through something Wibu calls SmartBind. It reads hardware properties, weights them, and stores a fingerprint: motherboard, CPU, hard disks, operating system details, the TPM chip, even a battery serial number where there is one. A readable TPM carries a lot of that weight. The vendor picks how far the fingerprint may drift before the license breaks, tight, medium or loose, and virtual environments get detected automatically as part of it.

Parts of the container also sit hidden around the system, what Wibu calls the dynamic data, and all of it has to line up for the license to decrypt. A rollback rewinds some of that while the rest moved on. Nothing lines up, and the container comes back invalid.

Wibu supports three ways to license inside a virtual environment, and is direct about the trade in each.

Arrangement

What it survives

What breaks it

No activation inside the VM. License on the host or a license server, guest pulls it over the network

Snapshots, rollbacks, rebuilding the guest from scratch

Losing the network path to the host or the license server

Activation inside the VM, bound hard to that VM

Normal running on that one host

Copying or moving the VM to another host

Activation inside the VM, high-availability arrangement

Moving the VM between hosts

Copying the VM

 

The first row is the only one that survives snapshots, and it is what I set up by default now. On a single workstation, a host-only virtual adapter between host and guest holds up better than a bridged one. Bridged goes down with the physical NIC and takes the license path with it.

There is a second VM failure with nothing to do with binding. FactoryTalk Activation Manager older than 4.03.03 cannot read certain license types when the product runs from a VMware image, and the symptom is not an error. The activation list is simply empty. Either bring FTAM up to a version that matches your runtime, or have Rockwell rehost those activations as Flexera type.

When another vendor's installer takes out FactoryTalk Activation Manager

Put In-Sight Vision Suite or VisionPro on a PC that already runs Rockwell software and there is a fair chance FactoryTalk Activation Manager stops opening. The Cognex installer brings its own CodeMeter Runtime Kit, and the version it drops in does not agree with what FTAM expects. Cognex documents the way out, and it is more than a reinstall:

1.    Uninstall the runtime kit and FactoryTalk Activation Manager, both of them, from Control Panel.

2.    Restart the computer.

3.    Delete any leftover CodeMeter folders in C:\Users\<username>\AppData\Local\Temp, C:\Program Files (x86), C:\Program Files and C:\ProgramData.

4.    Install the current runtime from Wibu.

5.    Install a version of FactoryTalk Activation Manager that is compatible with it.

6.    If Control Center reports the service running and the license activated but FTAM still errors out, run UpdateProtectionOnlyLicense.WibuCmRaU from C:\Program Files (x86)\Rockwell Software\FactoryTalk Activation\Tools.

Step 3 gets skipped, and step 3 decides whether any of this works. If the newer version refuses to install, end CodeMeter Runtime.exe and CodeMeterCC.exe in Task Manager and run it again.

Do not fix it by rolling CodeMeter back

The shortcut everyone reaches for is downgrading until FactoryTalk Activation Manager is happy again. It works, and it is a bad trade. Three vulnerabilities were published and fixed in 2021, the worst scoring 9.1 out of 10 and reachable over the network against the license server port. The patched side is FactoryTalk Activation Manager 4.05.03 or later, 4.06.11 or later, or runtime 7.30a and up straight from Wibu. Downgrade below that and you have left a listening service with a known critical hole on a plant network. Work upward until both layers agree, not down.

Diagram of a FactoryTalk activation server serving CodeMeter licenses over port 22350 through a firewall

The port is 22350 in both directions of the problem: serving licenses, and finding the server in the first place.

The network activation server: one port and one checkbox

Two things have to be true for a shared activation server, and usually exactly one of them is.

In FactoryTalk Activation Manager, under the advanced server settings, Run Network Server has to be checked. That opens the port and lets the server distribute licenses. Clear it and the ports shut in both directions.

Then the firewall has to let it through. The port is 22350 TCP, registered to Wibu at IANA and used for nothing else. It does double duty: a client hunting for an activation server broadcasts on 22350 as UDP. WebAdmin answers on 22352, or 22353 for HTTPS, and 22350 forwards to it, so 22352 is the one to open when WebAdmin needs reaching from another machine.

Here is the trap. From runtime version 6.90 onward that firewall rule is required, and FactoryTalk Activation Manager 4.04 creates it during installation. On an older FTAM, anywhere from 4.00.02 through 4.03, with a newer runtime installed by hand, the rule was never created. It only gets added when the Network Server option is picked during that install, and that is not the default. Activations look perfectly healthy on the server and stay invisible to every client on the line.

The software-license failures you will actually meet

What you see

What it means

What to do

Red container, marked broken

The binding no longer matches the hardware, or the Windows WMI service is not running

Confirm WMI is running, then try Repair License. If the hardware really changed, it needs reactivating

Container marked invalid

The hidden dynamic data around the license cannot be read, or no longer matches

Repair License, then find what is touching the folder

Error 5523 in the event log

Another program is holding the license file locked

Exclude the license folder from antivirus and backup, then Repair License

No software licenses listed at all

The runtime is running as an application instead of a service. Software licenses only work as a service

Control Center, Action menu, Restart CodeMeter Service

Service quits on its own after a few minutes

Its self-check saw a process attach to it, usually a deep-scanning antivirus, and shut down

Add CodeMeter.exe as an antivirus exception

 

Diagram comparing healthy, broken, and invalid CodeMeter license states in Control Center

Broken and invalid are two different faults with two different causes. Repair License only helps with one of them.

Antivirus and backup software are behind most of that table. Exclude the folder C:\ProgramData\CodeMeter\CmAct from antivirus, backup and cleaning tools alike. Anything that deletes, quarantines or restores files under ProgramData can invalidate a license that was healthy an hour earlier, and a partial restore from backup does it reliably.

Windows updates land in the same bucket. Wibu has carried a standing note about software licenses going invalid after a Windows 10 update for years, and the 24H2 update on Windows 11 took CodeMeter down quietly on plenty of machines until runtime 8.20 shipped. If a PC comes back from patching with no activations, check the runtime version before touching the license.

The dongle trade

A dongle moves the whole problem off the PC. The license sits in a smart card chip inside the stick and the secret keys never leave it, so the machine underneath can be reimaged, rebuilt or virtualized and the license does not care. Unplug it, put it in the next laptop, carry on. For a service laptop that lands somewhere different every week, that alone pays for the stick.

The other half of the trade is blunt. There is no software recovery for a dongle that is gone. A software license can at least be returned and reissued through the vendor, which is the only way it ever changes machines anyway. A dongle is one physical object holding your whole toolchain, and if it walks off, the road back runs through Rockwell.

FAQ

Is CodeMeter safe to leave running on a plant PC?

Yes, with a version caveat. It is a commercial licensing product, not adware, and it does nothing until a protected application asks it for a license. The caveat is those 2021 vulnerabilities: keep it current, and where it serves licenses over the network, treat 22350 like any other listening port and keep it in the segment that needs it.

Can I move a CodeMeter activation to another computer?

Not if it is a software license. Those containers do not move between systems, and copying the files does not get you there. Have the activation returned and reissued instead, which on the Rockwell side is the rehost process inside FactoryTalk Activation Manager. A dongle you just unplug and take with you.

Why does CodeMeter show a valid license while FactoryTalk says there is no activation?

Two layers, remember. Either their versions do not match, or the Protection Only license that FactoryTalk Activation Manager needs for itself has gone stale. Run UpdateProtectionOnlyLicense.WibuCmRaU out of the FactoryTalk Activation Tools folder first, it takes ten seconds. If nothing changes, compare the two version numbers.

Do I need it at all if I only run older Rockwell software?

Older versions activate through Flexera, so a machine that never gets anything new installed may genuinely never need it. The moment newer software goes on, both systems are present, and a checkbox in FactoryTalk Activation Manager decides which one wins for a feature that exists on both sides.

What actually keeps this quiet

The fewer times you rebuild the engineering PC, the fewer times you find out how CodeMeter feels about it. Put the license on a dongle or a proper server, keep both layers on versions that match, exclude the license folder from whatever is scanning it, and leave that machine boring.

The hardware around it is where we come in. IQElectro keeps refurbished and surplus Allen-Bradley on the shelf, tested and ready to ship: CompactLogix and ControlLogix controllers, PanelView terminals, Stratix switches, I/O. Useful when the line is older than its own documentation and licensing is the smallest thing you are chasing.

Published on  Updated on