Häufig gestellte Fragen
Teilen:
Troubleshooting
- In einem solchen Fall kann es helfen, CodeMeter einen Festplattenvollzugriff zu geben.
Gehen Sie bitte dazu wie folgt vor:
1. Öffnen der Systemeinstellungen.
2. Navigieren zu Systemeinstellungen | Sicherheit | Datenschutz | Festplattenvollzugriff
3. Hinzufügen CodeMeter.app zu der Liste an authorisierten Apps hinzu:
※ - Dies kann mehrere Gründe haben:
- Standardmäßig werden alle CmDongles 3-xxx (ohne Speicher) mit HID-Konfiguration ausgeliefert. Damit verhält sich der CmDongle quasi wie eine Tastatur oder Maus. Nur in der Konfiguration als MSD, wird ein Laufwerksbuchstaben vergeben.
- Eventuell ist auf Ihrem System der Zugriff auf Massenspeicherlaufwerke eingeschränkt worden. Um das zu überprüfen, erzeugen Sie bitte eine CmDust-Diagnosedatei und schicken diese an Wibu-Systems Support.
- Windows teilt den Massenspeicherlaufwerken wie CodeMeter Laufwerksbuchstaben nach den festen Laufwerken (Festplatte, CDROM) zu. Ist allerdings der nächste freie Laufwerksbuchstabe schon von einem Netzwerklaufwerk belegt, wird das Massenspeicherlaufwerk nicht angezeigt. Damit der CmDongle als Laufwerk erkannt werden kann, verändern Sie bitte die Zuordnung Ihrer Netzlaufwerke zu den Laufwerksbuchstaben. Verwenden Sie für Netzlaufwerke möglichst die hinteren Buchstaben des Alphabets. - Wird der CmDongle von Linux-Embedded nicht als Gerät erkannt, muss der CmDongle mit erhöhten Rechten gemounted werden.
Für HID-Dongles (Human Interface Device) Eingeben des Kommandos:
sudo chmod o+rw /dev/hidraw0
Für MSD-Dongles (Mass Storage Device) Eingeben des Kommandos:
sudo mount -t vfat -o umask=0000 /dev/sdc1 /media/usb
Sdc1 sdb1 sda1 hängt von dem angesteckten CmDongle ab. Mit dmesg könnten Sie ermitteln, welcher Buchstabe das ist.
Diese Angabe ändert sich nach jedem Boot/Replug. - EBL steht für "ExecuteBciLow". Und Bci für "Basic Command Interface".
Hier werden entsprechende Befehle zum CmDongle geschickt und dort dann ausgewertet bzw. verarbeitet.
Entsprechend können auch dabei Fehler auftreten, die dann zurückgeliefert und im CodeMeter-Ereignisprotokoll ausgegeben werden.
Diese Fehler-Codes können von unserer Hardware-Abteilung ggf. interpretiert werden, um mehr Information über einen Fehler zu erhalten.
In den meisten Fällen reicht es aber aus, wenn die sonstigen Einträge im CodeMeter-Ereignisprotokoll betrachtet werden. - Defekte CmDongle bitte an die unten stehende Adresse senden.
Bitte informieren Sie uns bei einem speziellen Defekt auch über eine beliegende Notiz , z.B. betroffene Ticket-Nr.:
WIBU-SYSTEMS AG
- COMPLAINT -
Zimmerstraße 5
76137 Karlsruhe
Germany - Bei der Anzeige dieser Fehler sind Fehler in der USB-Kommunikation mit dem CmDongle aufgetreten. Sollte die Verbindung nach mehreren Versuchen nicht möglich sein, erscheint zum Schluss Fehler 70 und es wird nicht weiter versucht, mit diesem CmDongle zu kommunizieren.
Die möglichen Ursachen können in solch einem Fall vielfältiger Natur sein, denn viele Faktoren können die Kommunikation zwischen CmDongle und 'CodeMeter.exe' beeinflussen, z.B. Stromversorgung, Chipsatz Treiber, evtl. Treiber von virtuellen Maschinen (VM), etc.
- In einem ersten Schritt zum Eingrenzen der möglichen Ursache können Sie zunächst den CmDongle versuchsweise auf einem anderen Rechner verwenden. Wenn der CmDongle dort einwandfrei funktioniert, können Sie zumindest einen Defekt des CmDongles ausschließen.
- Ein weiterer Schritt umfasst das Ausprobieren eines anderen USB-Port am Rechner, an dem der Fehler auftritt. Unserer Erfahrung nach, sind die USB-Ports hinten am Rechner meistens besser, als Front-USB Anschlüsse. Wenn Sie einen USB-Hub verwenden, sollten Sie es auch ohne diese versuchen bzw. einen aktiven (self-powered) USB-Hub verwenden, um Spannungsprobleme auszuschließen.
- Außerdem können Sie überprüfen, ob Sie bereits die neusten USB und/oder Chipsatz Treiber verwenden und falls nicht, diese installieren.
Aus CodeMeter-Sicht gibt es auch die folgenden Möglichkeiten, die Sie ebenfalls versuchen sollten:
- Aktualisieren der Firmware des CmDongles; falls dies nicht geht, könnte eventuell auch ein Defekt des CmDongles vorliegen.
- Umstellen der CmDongle-USB-Geräteklasse von HID- zu Massenspeicher (MSD). Wie Sie dies bewerkstelligen, erklärt => KB-0110 - Ursachen:
Dass der Firm Access Counter (FAC) einen Wert von 0 besitzt, kann verschiedene Ursachen haben:
1. Zum einen kann der FAC durch eine geschützte Anwendung auf einen Wert von 0 gesetzt worden sein.
Dieses Heruntersetzen ist ein Sicherheitsfeature, das durch die Aktivierung der Debugger-Erkennung und der Option "Sperren des Lizenz-Zugriffs" in AxProtector auf der Seite "Sicherheitsoptionen" aktiviert wird.
Ist die Debugger-Erkennung für Ihre Anwendung im AxProtector aktiviert und auf dem System, auf dem Ihre verschlüsselte Anwendung später ausgeführt wird, wird ein laufender Debugger erkannt, wird der FAC des Firm Items, innerhalb dessen die benötigte Lizenz belegt wurde, auf einen Wert von 0 gesetzt. Ebenso wird der FAC auf einen Wert von 0 gesetzt, wenn eine Methode, welche als Trap markiert wurde, aus der geschützten Anwendung aufgerufen wird. Hierdurch wird die laufende Anwendung beendet und ein erneuter Start der verschlüsselten Anwendung ist mit diesem CmContainer nicht mehr möglich. Wird nun versucht, die verschlüsselte Anwendung zu starten, aber der FAC des Firm Codes, der die Lizenz beinhaltet, hat einen Wert von 0, wird Fehler 38 ausgegeben und der Start der Anwendung wird unterbunden. So werden eventuelle Hacking- oder Reverse Engineering-Versuche geblockt und verhindert und der Schutz Ihrer Anwendung wird gesteigert.
Sie finden auch Informationen und Erklärungen zum FAC und dem Sperren von CmContainern im separaten "CodeMeter Entwicklerhandbuch" im Kapitel "Automatischer Softwareschutz mit AxProtector | Kommandozeilen-Optionen für AxProtector | Einstellungen zu Verschlüsselungsvorgängen“. Hier finden Sie die Erklärung zum FAC unter der Kommandozeilenoption '-cag'. Der Wert, der der Lizenzsperre entspricht, ist dabei '-cag16'.
Um das Heruntersetzen des FAC zu vermeiden, sollten Sie daher sicherstellen, dass auf dem gleichen System kein Debugger parallel zu Ihrer geschützten Anwendung ausgeführt wird.
Wenn Sie das Sperren der Firm Item-Ebene durch den FAC komplett deaktivieren wollen, müssen Sie die "Sperren des Lizenz-Zugriffs"-Option in AxProtector für die Verschlüsselung Ihrer Anwendung deaktivieren. Bei dennoch aktivierter Debugger-Erkennung wird dann lediglich die Anwendung beendet, wenn ein laufender Debugger erkannt wird, der FAC aber nicht mehr auf einen Wert von 0 gesetzt. Diese Einstellung bedeutet im Umkehrschluss aber auch, dass Sie ein Stück des Schutzes und der Sicherheit Ihrer Anwendung aufgeben.
Seit der CodeMeter Version 6.0 wird im Falle, dass der FAC dekrementiert wurde, auch eine verschlüsselte Logdatei angelegt, über die sich in den meisten Fällen ermitteln lässt, welche Anwendung oder welcher Debugger für das Zuschlagen des Debugger-Schutzes verantwortlich war. Sollte mit der Debugger-Erkennung ein von Ihnen nicht erwartetes Verhalten auftreten, schicken Sie diese Logdateien der betroffenen Rechner an Wibu-Systems Support. Nachdem der FAC heruntergezählt wurde, finden Sie diese so genannte "LicenseLock.log"-Datei im Verzeichnis "C:\ProgramData\CodeMeter\Logs".
2. Darüber hinaus wird der FAC auf einen Wert von 0 gesetzt, wenn der CmContainer auf der Blacklist der CodeMeter License Central steht.
Anstatt neue Artikel und Lizenzen zu programmieren, wird in diesem Fall der FAC=0 programmiert.
Hochsetzen des Firm Access Counter (FAC)
Wenn der FAC Ihres eigenen Firm Items auf den Wert 0 gesetzt ist, können Sie diesen wieder auf einen Wert größer 0 setzen, damit die Lizenz wieder gültig wird und wie üblich verwendet werden kann.
Wenn Sie CodeMeter License Central zum Verteilen Ihrer Lizenzen verwenden, sollten Sie den FAC auch über ein entsprechendes Ticket der CodeMeter License Central wieder hochsetzen. Wie dies funktioniert, wird in KB-0370 beschrieben.
Wenn Sie CodeMeter License Central nicht verwenden, können Sie den FAC auch mit CmBoxPgm und Ihrer Firm Security Box (FSB) wieder hochsetzen.
Weitere Informationen finden Sie auch im separaten "CodeMeter Entwicklerhandbuch" unter "Programmierung von CmContainern und Lizenzierungsverwaltung | CmBoxPgm | Firm Item Optionen“, "Erweiterte CodeMeter Eigenschaften | Sperren des CmContainer". - Welcher Modus verwendet werden soll, kann über die Windows-Registry und den Schlüssel UseUmsDA eingestellt werden.
Zum Öffnen der Registry gehen Sie bitte wie folgt vor:
- Drücken der Tastenkombination [Windows] + [R], um den Dialog
"Ausführen" zu öffnen.
- Eingabe des Befehls regedit und Bestätigen mit [Enter].
- Suchen des Wertes
[HKEY_LOCAL_MACHINE\SOFTWARE\WIBU-SYSTEMS\CodeMeter\Server\CurrentVersion]:
Steht der Parameter UseUmsDA auf einem Wert von 0, so ist der FileIO-Modus aktiviert, steht er auf einem Wert von 1, so ist der PassThrough-Modus (Standard) aktiviert.
Bitte beachten Sie, dass wenn keine ausreichenden Rechte für UseUmsDA=1 vorhanden sind, CodeMeter automatisch auf FileIO-Modus umschaltet.
In der Regel ist die Ursache, dass CodeMeter nicht als Dienst läuft und damit nicht ausreichend Rechte hat, um mit dem CmDongle im PassThrough-Modus zu kommunizieren. Daher ist die Lösung, einfach den CodeMeter-Dienst zu starten.
Alternativ kann für das Firmware Update der CmDongles auch auf einem anderen System betrieben werden, auf dem CodeMeter standardmäßig als Dienst installiert wurde.
Welcher Modus gerade verwendet wird, können Sie dem CodeMeter Event-Log entnehmen. Beim Start von CodeMeter wird als letzte Zeile ausgegeben:
Box Access: use direct access mode. entspricht dem PassThrough-Modus
oder
Box Access: use compatibility access mode. entspricht dem FileIO-Modus
ausgegeben. - Wenn ein CmDongle angeschlossen ist und in CodeMeter Kontrollzentrum angezeigt und ausgelesen werden kann, ist im Regelfall davon auszugehen, dass dieser funktioniert.
Ein Defekt eines CmDongles äußert sich bereits schon beim Anschließen. In CodeMeter Kontrollzentrum auf Register "Ereignisse" sind dann Einträge zu sehen, die Fehler aufzeigen und auch näher beschreiben.
Allerdings muss einem Fehler nicht gleich ein Defekt des CmDongles zu Grunde liegen, sondern liegt oft auch an der USB-Kommunikation, d.h. an den verwendeten USB-Port, USB-Hub oder USB-Treiber.
Weitere Information hierzu finden Sie auch in KB-0201.
In diesen Fällen sollten Sie den CmDongle noch auf anderen Systemen ausprobieren. Funktioniert der CmDongle auch an einem anderen System nicht, ist ein Defekt eher wahrscheinlich. - Für ältere CmDongles mit bestimmten Controllern gibt es keine Firmware-Versionen 2.x. Der auf diesen Controllern verfügbare Platz für die Firmware reichte nicht aus, um das mit 2.0 geänderte Update-Verfahren aufzunehmen. Falls in Zukunft notwendig, wird es auch für diese CmDongles aktualisierte Firmware-Versionen zur Fehlerbehebung geben; diese werden dann als Version 1.xx über den Update Server ausgeliefert.
Folgende CmDongle-Artikelnummern bleiben dauerhaft auf Firmware-Versionen 1.x beschränkt: 1001-01, 1010-01, 1011-01. Die Artikelnummern sind bei CmDongles in Standardgehäusen auf der Unterseite ablesbar. - Abhängig vom BIOS und dessen Einstellungen für den Rechner kann es vorkommen, dass ein Rechner im Boot-Prozess stecken bleibt, wenn ein CmDongle angesteckt ist. Das System versucht dann vom CmDongle zu starten, kommt aber mit den Antworten des CmDongles nicht zurecht.
Dieses Verhalten kann durch Umkonfiguration des CmDongles geändert werden. Die Boot-Problematik tritt meist bei CmDongles auf, die als lokale Festplatte konfiguriert sind. Es besteht die Möglichkeit, den CmDongle als Wechseldatenträger zu konfigurieren. Gehen Sie bitte wie folgt vor:
1. Öffnen einer CodeMeter Eingabeaufforderung über "Start | Alle Programme | CodeMeter | Tools | CodeMeter Command Prompt".
2. Auslesen der aktuellen Konfiguration.
Ausführen des Kommandos wobei der Platzhalter <serial> durch die Seriennummer Ihres CmDongles ersetzt werden muss, z.B. "3-123456":
cmu32 -s <serial> --show-config-disk
3. Umkonfigurieren des CmDongles als Wechseldatenträger.
Ausführen des Kommandos: cmu32 -s <serial> --set-config-disk RemovableDisk
4. Abziehen und erneutes Anstecken des CmDongles.
Überprüfen Sie danach das Boot-Verhalten und die Funktionalität im Normalzustand.
Sollte dies noch keine Verbesserung gebracht haben, können Sie noch andere Boot Codes {Int18Boot,ZeroBoot,LoopBoot,SwapBoot,VbrBoot} probieren. Z.B. mit Ausführen des Kommandos: cmu32 -s <serial> --set-config-disk ZeroBoot - Wenn unter Linux Wechseldatenträger eingesteckt werden, dann müssen diese erst in die lokale Dateistruktur eingebunden (eingehängt, "gemountet") werden, um auf die Datenträger zugreifen zu können. Unter einigen Desktop-Umgebungen geschieht dies mittlerweile automatisch, unter anderen jedoch nicht.
Prüfen Sie die Einstellungen zum automatischen Einbinden, allgemein als auch speziell für die CmCard, über den Menüeintrag "Systemeinstellungen | Hardware |Wechselmedien".
Bitte beachten Sie, dass für die spezielle Einbindung die CmCard bereits einmal am System eingesteckt gewesen sein muss.