To top
Support & Downloads Support & Downloads

Frequently Asked Questions




    Connecting removable devices on Linux requires device mounting into the local file structure to enable device access. While this happens by default for some desktop environments, this is not the default behavior in other environments.


    Use the menu item "System Settings | Hardware | Removable Devices" to check the settings for general automounting, or for the CmCard in particular.


    Please note that for mounting a CmCard, the CmCard must have been connected previously.


    This can happen if you possess a new CmDongle with a serial number 3-xxx (item number 1001-03-xxx). Please find the serial number on the USB connector and the item number on the casing.


    By default, these CmDongles ship without an assigned drive letter in Windows Explorer. The CmDongles instead register with the system as Human Interface Devices (HID).


    In order to make CodeMeter recognize these CmDongles, you require the CodeMeter Runtime version 5.00 or later. If you use Linux, please note that the system must support HID devices.


    Please use one of the following options to help CodeMeter find the new CmDongles:


    1. Update the CodeMeter Runtime to the current version you can download here.

    2. Reconfigure the CmDongle that the system detects it as removable disk. On a system able to detect the CmDongle, please proceed as follows:

    - Open a CodeMeter Command Prompt using "Start | All Programs | CodeMeter | Tools | CodeMeter Command Prompt".

    - Read the current configuration.

    Execute the following command, replacing <serial> with your CmDongle serial number, e.g. "3-123456":

    cmu32 -s <serial> --show-config-disk

    - Reconfigure your CmDongle to be detected as mass storage device.

    Execute: cmu32 -s <serial> --set-config-disk MsdCommunication

    - Remove and replug the CmDongle.


    There may be several reasons for this:


    - By default, all CmDongles 3-xxx (without flash memory) are delivered with HID configuration. Thus the CmDongle is detected as a potential keyboard or mouse device. Only in the configuration as MSD, a drive letter is assigned.


    - Eventually, the access to mass storage drives has been restricted on your system. To check this, please create a CmDust diagnostic file and send it to Wibu-Systems Support.


    - Windows assigns the mass storage drives, such as CodeMeter drive letters, to the fixed drives (hard disk, CDROM). However, if the next free drive letter is already occupied by a network drive, the mass storage drive is not displayed. So to ensure that the CmDongle can be recognized as a drive, please change the assignment of your network drives to the drive letters. If possible, use the last letters of the alphabet for network drives.


    If the CmDongle is not recognized as a device by Linux-Embedded, the CmDongle must be mounted with increased rights.


    For HID-Dongles (Human Interface Device) enter the command:

    sudo chmod o+rw /dev/hidraw0

    For MSD (Mass Storage Device) dongles, enter the command:

    sudo mount -t vfat -o umask=0000 /dev/sdc1 /media/usb


    Sdc1 sdb1 sda1 depends on the connected CmDongle. With dmesg you could determine which letter this is.

    This information changes after each boot/replug.


    In such a case, it may help to give CodeMeter full disk access.

    To do this, please proceed as follows:

    1. Open System Preferences.

    2. Navigate to System Preferences | Security & Privacy| Full Disk Access.

    3. Add to the list of authorized apps:



    Depending on the BIOS and the configuration of the boot manager of your system, it might occur that your system hangs during boot procedure. This happens because the system tries to boot from the CmDongle and receives responses it does not understand.


    This behavior can be avoided by reconfiguring your system. CmDongle can be configured to be detected as a local disk or removable disk. The boot problem appears mostly for CmDongles configured as local disks. You can reconfigure your CmDongle as a removable device as follows:


    1. Open a CodeMeter Command Prompt using "Start | All Programs | CodeMeter | Tools | CodeMeter Command Prompt".

    2. Read the current configuration.

    Execute the following command, replacing the <serial> with your CmDongle serial number, e.g. "3-123456":

    cmu32 -s <serial> --show-config-disk

    3. Reconfigure your CmDongle to be detected as removable device.

    Execute: cmu32 -s <serial> --set-config-disk RemovableDisk

    4. Remove and replug the CmDongle.


    Please check the booting behavior and functionality in default operations.


    If this hasn't helped, you can try other boot codes {Int18Boot,ZeroBoot,LoopBoot,SwapBoot,VbrBoot}. E.g. by executing the command: cmu32 -s <serial> --set-config-disk ZeroBoot


    EBL stands for "ExecuteBciLow". And Bci for "Basic Command Interface".

    Here corresponding commands are sent to the CmDongle and then evaluated or processed there.

    Accordingly, errors can also occur, which are then returned and output in the CodeMeter event log.

    These error codes can be interpreted by our hardware department to get more information about an error.

    In most cases, however, it is sufficient to look at the other entries in the CodeMeter event log.


    If those errors display, errors in the USB communication with the CmDongle have been occurred. If the communication after several attempts still fails, finally Error 70 displays and no further communication attempts with this CmDongle are performed.

    The possible reason for the failed communication between CmDongle and 'CodeMeter.exe' are varied, e.g. power supply, chipset driver, eventually drivers of Virtual Machines (VM), etc.

    - In a first step to limit possible causes, attempt to use the CmDongle for another PC. If the CmDongle performs trouble-free, you can exclude a defect CmDongle.

    - Another step covers to try another USB port of the PC on which the error occurs. Our experience is, that USB ports at the back of the PC work better than the one on the front. If you use a USB Hub, try to do without it or use a self-powered USB Hub to exclude power problems.

    - Moreover, you can check whether you already use the latest USB or chipset driver and if not, can install them.


    Form a CodeMeter point of view, the following options exist you should also attempt:

    - Update the firmware of the CmDongle; if this should not work eventually the CmDongle is defect.

    - Switch CmDongle USB device class from Human Interface (HID) to mass storage (MSD). For a description how to do this, see => KB-0110.



    The fact that the Firm Access Counter (FAC) has a value of 0 can have various causes:


    1. First, the FAC may have been set to a value of 0 by a protected application.

    This reduction is a security feature enabled by activating debugger detection and the "Block license access" option in AxProtector on the "Security Options" page.

    If debugger detection is activated for your application in AxProtector and a running debugger is detected on the system where your encrypted application will later run, the FAC of the Firm Item within which the required license was occupied is set to 0. This terminates the running application and a restart of the encrypted application is no longer possible with this CmContainer. If the encrypted application is now tried to start, but the FAC of the Firm Code containing the license has a value of 0, error 38 is output and the start of the application is prevented. This blocks and prevents any hack or reverse engineering attempts and increases the protection of your application.

    You will also find information and explanations on FAC and locking CmContainers in the separate "CodeMeter Developer Guide" in the section "Automatic Software Protection with AxProtector | Command Line Options for AxProtector | Encryption Settings". Here you can find the explanation of the FAC under the command line option '-cag'. The value corresponding to the license lock is '-cag16'.


    To avoid reducing the FAC, make sure that no debugger is running on the same system as your protected application.

    If you want the FAC to completely disable locking of the Firm Item level, you need to disable the "Lock license access" option in AxProtector to encrypt your application. If debugger detection is still enabled, the application will only be closed if a running debugger is detected, but the FAC is no longer set to a value of 0. Conversely, this setting also means that you are giving up some of the protection and security of your application.


    Since CodeMeter Version 6.0, if the FAC has been decremented, an encrypted log file is also created, which can be used in most cases to determine which application or debugger was responsible for slamming the debugger protection. If the debugger detection causes an unexpected behavior, send the log files of the affected computers to Wibu-Systems Support. After the FAC has been decremented, you will find this so-called "LicenseLock.log" file in the directory "C:\ProgramData\CodeMeter\Logs".


    2. In addition, the FAC is set to a value of 0 if the CmContainer is on the blacklist of CodeMeter License Central.

    Instead of programming new articles and licenses, the FAC=0 is programmed in this case.


    Incrementing the Firm Access Counter (FAC)

    If the FAC of your own Firm Item is set to 0, you can reset it to a value greater than 0 so that the license becomes valid again and can be used as usual.

    If you are using CodeMeter License Central to distribute your licenses, you should also use a CodeMeter License Central ticket to increase the FAC again. How this works is described in KB-0370.

    If you do not use CodeMeter License Central, you can also use CmBoxPgm and your Firm Security Box (FSB) to increment the FAC.

    Further information can be found in the separate "CodeMeter Developer Guide" in nsection "Programming CmContainers and Licensing Management | CmBoxPgm | Firm Item Options", "Advanced CodeMeter Properties | Locking the CmContainer".


    For older CmDongles with a specific controller version, there is no firmware version 2.x, because these controllers do not possess sufficient memory for the changed firmware update procedure that was introduced as part of version 2.0. However, future firmware updates will provide error corrections for these CmDongles, which are then delivered as version 1.xx using the Update Server.


    The following CmDongle item numbers will permanently be limited to firmware versions 1.x: 1001-01, 1010-01, 1011-01. On CmDongles with standard casing, you can find the item number on the bottom of the case.


    Please send damaged CmDongles to the address stated below.

    Please also enclose a note, if a special defect exists, e.g. information on related Ticket ID:




    Rueppurrer Strasse 52-54

    D-76137 Karlsruhe