auf 2 Laptops ähnlicher Bauart ist Win7pro 64bit installiert. Auf dem einen E8420 läuft WinAVR mit Arduino nano3 mit FTDI-Treiber CDM21218_Setup.exe problemlos. Auf dem anderen Gerät sollte ein Mega2560 laufen. Daher installierte ich arduino-1.6.12-windows.exe. Entsprechend der Anleitung im Netz probierte ich es mit arduino.inf. Leider klappte das so nicht. Siehe die Bilder. Wie bekomme ich den Treiber zum Laufen? Win7 neuinstallieren? Die letzte Installation war vor kurzem. Windows scheint sehr empfindlich auf Treiber von Fremdanbietern zu reagieren. Bei der Installation hatte ich auch einmal Treiber verwendet die neuer schienen - aber nicht von der Seite des Laptopherstellers stammten. Das erzeugte auch Meldungen wie oben. Leider war das für mich nicht wegzukommen - außer durch Neuinstallation. Kennt jemand diese Thema und eine Abhilfe - ohne wiederholte Neuinstallation? Leider scheint auch Wiederherstellung keine brauchbare Lösung zu sein. Es gibt einen Wiederherstellpunkt. Nur löst er das Problem nicht. Der Treiber CDM21218_Setup.exe läuft durch - sagt alles sei ok. Nur steht unten dann weiterhin das gelbe Rufzeichen. Deinstallieren mit CDMUninstaller_v1.4.zip klappt. Nur löst auch dies das Problem nicht.
fehlt da nicht noch eine .cat Datei? Darin sollte die Signatur legen.
Peter II schrieb: > fehlt da nicht noch eine .cat Datei? Darin sollte die Signatur legen. vielen Dank Peter. .cat-Dateien gibt es mehrere: ftdibus.cat in c:\users\name\AppData\Local\Temp\FTDI-Driver ftdiport.cat ebenso. Kann da ggf. ein Rechte-Problem sein?
Peter II schrieb: > fehlt da nicht noch eine .cat Datei? bei dem .exe sieht man nicht leicht was drin ist. Anders ist das bei dem neueren zip von FTDI CDM V2.12.24 WHQL Certified.zip. Da ist ein ftdibus.cat und ein ftdiport.cat neben den beiden .inf definitiv drin. Mit diesem zip ausgepackt geht es jedoch auch nicht.
:
Bearbeitet durch User
ein E554-Notebook ist noch da. Da habe ich das board angesteckt. Der Treiber wurde logischerweise nicht gefunden da noch nicht installiert. CDM21218_Setup.exe aufgerufen dauerte recht lange (lief über Netz). Da geht es nun einwandfrei. Warum nur streikt es auf dem anderen Rechner? Alle haben dasselbe Win7 64bit.
Matthias W. schrieb: > Warum nur streikt es auf dem anderen Rechner? Alle haben dasselbe Win7 > 64bit. Aber vermutlich nicht denselben Patch-Stand, z.B. Stichwort Stammzertifikate. Lass den nicht funktionierenden Win7 mal 'ne Nacht durchlaufen, dass er alle seine Updates findet und installiert.
Jim M. schrieb: > vermutlich nicht denselben Patch-Stand, z.B. Stichwort > Stammzertifikate. Vielen Dank Jim für den Hinweis. Windows-Updates sind bei allen 3 Rechnern abgeschaltet. Es ist Win7 64bit SP1. Ohne Updates sollten eigentlich alle 3 Rechner den selben Windows-Stand haben. Du meinst der eine Rechner hat oder braucht andere Zertifikate? natürlich kann ich die Updates mal aktivieren. Dann bricht wohl eine wahre Flut los. Ist die Frage ob das dem System gut tut. Die anderen beiden Rechner kommen scheinbar ohne das klar.
ich habe den INFCACHE.1 entfernt und das neu aufbauen lassen. Der Treiber wurde dann neu installiert über das .exe. Es dauerte jedoch viel weniger lang als auf dem E554. Laut Meldung hat es geklappt. nur leider ist unten wieder das gelbe Rufzeichen, obwohl der Treiber Erfolg behauptet hat.
Rücksetzen des Systems auf 8.10.2016 hat er zwar gemacht. Nur wurde das Installieren so auch nicht erfolgreicher. Das gelbe Symbol mag nicht wegbleiben.
cmd aufgerufen als Admin. sfc /scannow: Der Windows-Ressourenschutz hat beschädigte Dateien gefunden und konnte einige der Dateien nicht reparieren. Details in CBS.Log. Diese Datei ist ellenlang. Scheinbar bewirkt die Systemwiederherstellung nichts Brauchbares. Wie anders kann man das erklären? Das System wurde zuletzt neu installiert am 8.10.2016. Und davor schon ein paar mal.
Die *.cat kann man normalerweise auch einfach doppelklicken und sieht dann, ob die Signatur verifiziert werden kann oder kann sich den Zertifikatspfad anschauen und ggf. rausfinden welches Zertifikat fehlt
Der Hinweis von Jim Meba ist wahrscheinlich das richtige. Habe ich selber bei zwei Kunden erlebt, die es zuerst nicht glauben wollten. Mit einem (großen) update war alles wieder in Ordnung. Treiber, die relativ kürzlich signiert waren (ca 1 Jahr?) lassen sich nicht laden wenn der System Updatestand älter ist. Betrifft aber bei Win 7 nur die 64-bit Version. Es gibt bei Microsoft u. auch z.B. bei Symantec irgendwo eine Notiz dazu. Hintergrund war die Beseitigung eine Schwachstelle im bisherigen Zertifikatswesen bei Microsoft so vor ca 1 Jahr.
bluppdidupp schrieb: > Die *.cat kann man normalerweise auch einfach doppelklicken und sieht > dann, ob die Signatur verifiziert werden kann oder kann sich den > Zertifikatspfad anschauen und ggf. rausfinden welches Zertifikat fehlt vielen Dank für den Hinweis ! ftdibus.cat: Sicherheitskatalog gültig ab 21.6.2016. Treiberverzeichnis. ftdibus.cat: Sicherheitskatalog gültig ab 12.4.2011. Dies ist der Treiber im Arduino-Verzeichnis den ich anfangs versucht hatte. ftdiport.cat: Sicherheitskatalog gültig ab 21.6.2016. Treiberverzeichnis. ftdiport.cat: Sicherheitskatalog gültig ab 12.4.2011. Dies ist der Treiber im Arduino-Verzeichnis den ich anfangs versucht hatte.
cfgardiner schrieb: > Treiber, die relativ kürzlich signiert waren (ca 1 Jahr?) lassen sich > nicht laden wenn der System Updatestand älter ist. vielen Dank für den Hinweis. Auf allen 3 Systemen ist der Updatezustand gleich. Bei zweien geht es, auf dem dritten nicht. Ein Unterschied der 3 Rechner ist daß der Problemrechner eine neue Festplatte bekam. Statt der Originalplatte von Fujitsu 160GB ist das eine Seagate ST500LM000-1EJ162.
cfgardiner schrieb: > > Treiber, die relativ kürzlich signiert waren (ca 1 Jahr?) lassen sich > nicht laden wenn der System Updatestand älter ist. Betrifft aber bei Win > 7 nur die 64-bit Version. Aktuelle Zertificate sind mit SHA2 signiert, Bei Windows 7 muss man den Support dafür nachrüsten. Wenn man Updates abgeschaltet hat, geht das auch manuell: https://support.microsoft.com/de-de/kb/3033929 Wichtig: Installations Notizen lesen, gibt da ein paar Problemfälle. (Google ist dazu auch recht gesprächig)
Lattice User schrieb: > Wenn man Updates abgeschaltet hat, geht das > auch manuell: vielen Dank für den Hinweis !
ich habe nun die 160GB-Originalplatte wieder eingebaut. Die ist zwar viel kleiner als die 500GB-Seagate mit dem Halbleiterspeicher-CACHE, dafür scheinen die Probleme nun weg zu sein. Der FTDI läuft nun, kein gelbes Rufzeichen mehr. Natürlich werde ich das nun beobachten. Wie es scheint ist irgendetwas im Zusammenspiel der modernen ST500LM000-Platte mit dem Rechner anders. Genau dies scheint zu ungewünschtem Stress zu führen. Mir ist momentan nicht klar was da passiert und wie man moderne Platten in diese Geräte bauen kann ohne solch lästigen Schiffbruch zu erleben.
Du könntest testweise die 160GB-Platte auf die neue Platte clonen. Ist wenig Aufwand; Platten tauschen, Rechner von USB-Stick/CD/DVD mit "clonezilla" booten und in der richtigen Richtung kopieren. Dein Problem liegt mit Sicherheit nicht an der verwendeten Festplatte, da hat sich irgendwas anderers in Deiner Windows-Installation festgefressen.
Rufus Τ. F. schrieb: > Dein Problem liegt mit Sicherheit nicht an der verwendeten Festplatte, > da hat sich irgendwas anderers in Deiner Windows-Installation > festgefressen. Danke Rufus. Es ist halt so daß ich diesen Laptop nun schon diverse Male installiert habe. Immer wieder kam es zu ähnlichen Problemen mit der Signatur. Auf den anderen beiden Rechnern ist das so nicht der Fall gewesen. Es war nicht nur der Ärger mit dem FTDI. Vorher lief der PCGU1000 von Vellemann einfach nicht. Derselber Treiberärger. Auch da versagte die Wiederherstellung von Windows. Zudem gab es Probleme mit dem IE11. Der fing einfach zu spinnen. Daher vermute ich mittlerweile ein Problem im Zusammenspiel mit eben dieser Hybridplatte. Die Platte selbst scheint nicht defekt. Zumindest sagt der Test ok. Gute Idee mit dem Clonen. Vielleicht gelingt mir das. Es ist halt mühsam den Rechner unten immer wieder aufzuschrauben.
War da nicht irgendwas daß sich das komplette Windows 7 Update Räderwerk an einem bestimmten Datum dieses Jahr festgefressen hat (weil MS was am Update-Protokoll geändert hat) und man mit einer handvoll manuell zu installierenden Updates eingreifen muss um es wieder in Gang zu bekommen? Vielleicht hängen die Rechner ja in diesem Zustand? Meiner Erfahrung nach (wenn Windows nicht gerade irgendwo festhängt) installieren sich die FTDI-Treiber ohne Benutzereingriff vollkommen problemlos von selbst, und insbesondere ganz ohne irgendwelche cab oder inf Dateien: Einfach einstöpseln, Kaffee trinken gehen, 30min später ist es betriebsbereit, in guter alter gewohnter Windows-Zuverlässigkeit.
Bernd K. schrieb: > komplette Windows 7 Update Räderwerk Danke Bernd ! eben dieses Räderwerk habe ich ja bewusst abgeschaltet. Es ist nur SP1. Auf allen Rechnern lief dies - und nun auch auf dem Problemrechner wieder - mit der alten Platte. Keine Ahnung wie stabil das nun ist. Das wird sich zeigen.
Bernd K. schrieb: > FTDI-Treiber ohne Benutzereingriff vollkommen > problemlos Du meinst - man braucht keinen Treiber selbst suchen - lässt einfach Windows machen? Updates sind bei mir aus. Keine Ahnung wie Windows selber dann anfangen zu suchen soll. Jedenfalls geht der Treiber nun ja. Momentan läuft scheinbar alles was ich gerade installiert habe.
Rufus Τ. F. schrieb: > Rechner von USB-Stick/CD/DVD mit > "clonezilla" booten und in der richtigen Richtung kopieren. der Stick spinnt mittlerweile - Kontaktprobleme. Spray hilft manchmal. eine externe USB3-Platte habe ich. Wenn Clonezilla ohne extra Treiber darauf zugreifen kann sollte es gehen.
Matthias W. schrieb: > Du meinst - man braucht keinen Treiber selbst suchen - lässt einfach > Windows machen? Ja. FTDI zahlt Geld an Microsoft (bzw Microsoft verlangt viel Geld vom Hersteller für dieses Feature das bei anderen Betriebssystemen kostenlos ist) um ihre Treiber automatisch installieren und updaten zu lassen. Deshalb sind diese Chips auch signifikant teurer als alle anderen vergleichbaren.
Bernd K. schrieb: > Ja. FTDI zahlt Geld an Microsoft Vielen Dank Bernd. Das wusste ich nicht. Klar muss jeder Treiber irgendwo zertifiziert werden. Sonst wäre er ja nicht installierbar. Aber daß MS da auch noch Geld bekommt wusste ich nicht. Der Nachteil für den Kunden ist daß wohl kein Hersteller ernsthaft Interesse hat neuere Treiber für ältere Geräte zu machen. Der E8420 ist von 2009. Die Treiber sind daher nicht mehr neu. Selbst wenn man neuere im Netz findet muss es nicht so sein daß diese auch installierbar sind. Ich hatte das Problem daß neuere Treiber zu Problemen führten und ich so wieder bei den alten Treibern gelandet bin. Es scheint so als ob nur mit Linux da mehr Dauerhaftigkeit da ist. Da wird auch ältere Hardware wohl noch länger unterstützt. Der Reiz der älteren Geräte sind für mich die viel kleineren Treiber. Bisher komme ich damit viel besser klar als mit neueren Geräten wie E554/E754.
Bernd K. schrieb: > Matthias W. schrieb: >> Du meinst - man braucht keinen Treiber selbst suchen - lässt einfach >> Windows machen? > > Ja. FTDI zahlt Geld an Microsoft (bzw Microsoft verlangt viel Geld vom > Hersteller für dieses Feature das bei anderen Betriebssystemen kostenlos > ist) um ihre Treiber automatisch installieren und updaten zu lassen. Sehr teuer: Null €/$/whatever https://social.msdn.microsoft.com/Forums/en-US/00186286-a68c-4ac2-92da-c86a86d08bd4/cost-of-distributing-drivers-in-windows-update-?forum=whck Zertifizierungskosten: "As of 1/1/2014 no more fees are charged for any certification submissions. This dos cover both device and system submissions. The policy document updated on 1/10/2014 to reflect this new policy." https://blogs.msdn.microsoft.com/windows_hardware_certification/2013/12/13/hardware-certification-submission-fees-update/ Was bleibt sind die Kosten für das Zertifikat: ~150 €/Jahr und die Kosten für die Tests, die vor dem Einreichen durchgeführt werden...
Arc N. schrieb: > Kosten für das Zertifikat: ~150 €/Jahr Danke ! das klingt überschaubar. Andererseits - wie groß ist wirklich der Nutzen solcher Zertifikate? Bringt das wirklich etwas? Wie sinnvoll und wirksam sind ggf. durchgeführte Tests? Ich denke da an die seltsamen TÜV-Gutachten - sogar Glücksspiele für die im TV geworben wird haben nun angeblich eine TÜV-Abnahme. So wie brüchig werdende Herzschrittmacherkabel und Silikon das in Brüsten ausläuft. https://www.it-tuv.com/news/online -pok er-te xas.html http://www.ndr.de/ratgeber/gesundheit/Gefahr-durch-defekte-Medizinprodukte,medizinprodukte103.html https://www.deutsche-apotheker-zeitung.de/news/artikel/2016/09/16/tuev-rheinland-geraet-wegen-brustimplantaten-unter-druck das stimmt schon nachdenklich.
Digital signierte Treiber braucht man unabhängig von Windows-Update unter neueren 64bit Windows-Systemen sowieso. Von daher kommt man um die Signatur-Kosten ohnehin nicht wirklich herum. Über den Nutzen kann man Streiten ;D Die WHQL-Tests sind nur automatisierte Tests, die sagen über die Treiberqualität an sich also nicht viel aus, aber geben da zumindest ein gewisses minimales Grundlevel vor. "Sicherheitskatalog gültig": Wenn das der Fall ist, aber bei Installation trotzdem über ungültige Signatur gemeckert wird müssen die Treiberdateien abweichend zu den in den .cat-Dateien angegebenen sein. Die .cat-Dateien sind grob gesagt digital-signierte Listen von Dateihashes. Die Treiberdatei selbst wird dann nicht in der .cat-Datei enthalten sein - oder ist dort mit abweichendem Hash enthalten. => Jemand hat am Treiberpaket herumgebastelt gegenüber dem Originaltreiber zu dem die .cat erstellt wurde oder es das Treiberpaket ist an sich defekt heruntergeladen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.