Frequently Asked Questions

Troubleshooting

• Expand all Collapse all
• A CmCard not automatically detected on Linux (graphic desktop KDE 4) URL copied to clipboard
  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.
• CmDongle is not shown as a drive in Windows Explorer URL copied to clipboard
  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.
• CmDongle not recognized by Linux embedded device URL copied to clipboard
  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.
• CmDongle with memory is not recognized on macOS URL copied to clipboard
  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 CodeMeter.app to the list of authorized apps:
  
  ※
• Computer does not boot when a CmDongle is plugged in URL copied to clipboard
  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
• Does a connected CmDongle work? URL copied to clipboard
  If a CmDongle is connected and can be displayed and read in CodeMeter Control Center, it can usually be assumed that it is working.
  A defect of a CmDongle is already apparent when connecting. In CodeMeter Control Center on the register "Events" you can see entries which show errors and describe them in more detail.
  
  However, an error is not necessarily caused by a defect in the CmDongle, but is often due to the USB communication, i.e. the USB port, USB hub or USB driver used.
  Further information can be found in KB-0201.
  In these cases you should try the CmDongle on other systems. If the CmDongle does not work on another system, a defect is more likely.
• EBL Trace explanation URL copied to clipboard
  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.
• Error 400-410 and Error 70 display URL copied to clipboard
  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.
• Firm Access Counter (FAC) has a value of 0, error 38 displays. URL copied to clipboard
  Causes:
  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 allocated is set to a value of 0. Also, the FAC is set to a value of 0 when a method that has been marked as a trap is called from within the protected application. 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".
• Firmware update does not work, error 89 URL copied to clipboard
  Which mode is to be used can be set via the Windows registry and the UseUmsDA key.
  Proceed as follows to open the registry:
  - Press the key combination [Windows] + [R] to open the dialog
  "Execute".
  - Enter the command regedit and confirm with [Enter].
  - Searching for the value
  [HKEY_LOCAL_MACHINE\SOFTWARE\WIBU-SYSTEMS\CodeMeter\Server\CurrentVersion].
  
  If the parameter UseUmsDA is set to a value of 0, FileIO mode is activated; if it is set to a value of 1, PassThrough mode (default) is activated.
  Please note that if there are no sufficient rights for UseUmsDA=1, CodeMeter automatically switches to FileIO mode.
  
  Usually the reason is that CodeMeter does not run as a service and therefore does not have sufficient rights to communicate with the CmDongle in PassThrough mode. Therefore the solution is to simply start the CodeMeter service.
  
  Alternatively the firmware update of the CmDongles can be run on another system where CodeMeter was installed as service by default.
  
  You can find out which mode is currently used from the CodeMeter Event Log. When CodeMeter is started, the last line is displayed:
  Box Access: use direct access mode. corresponds to PassThrough mode
  or
  Box Access: use compatibility access mode. corresponds to the FileIO mode
• For some dongles there is no firmware update availabel URL copied to clipboard
  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.
• FULA Error 90 or 91 URL copied to clipboard
  For security reasons, some functions in CmDongles are limited so that they cannot be used too often over a certain period of time. If these are used too often, the CmDongle locks itself in the firmware and a certain time must be waited without using these functionalities again to unlock the dongle. This is to prevent brute force attacks of various kinds.
  
  Error 90 occurs when too many attempts are made to authenticate with the password of the CmDongle, e.g. to activate the CmDongle or to perform a firmware update, but the password was not correct.
  Error 91 occurs when too many attempts are made to re-establish the encrypted communication between the CmDongle and CodeMeter. The encrypted communication should normally only ever be necessary when the CmDongle is initially recognized by CodeMeter. If error 91 occurs, it is possible that either the CmDongle has been reinserted too often or the USB port or controller is defective or the communication is disturbed.
  During normal operation the limit should not be reached.
  
  In both cases, the CmDongle must remain connected to the system for 5 minutes without using the respective functionality. If during the 5 minutes another attempt is made to enter a password or the communication is reset, the timer starts again from the beginning.
• Sending damaged CmDongles to Wibu-Systems URL copied to clipboard
  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:
  
  WIBU-SYSTEMS AG
  - COMPLAINT -
  Zimmerstraße 5
  D-76137 Karlsruhe
  Germany