none
usbser.sys (CDC) COM Port verschwindet

    Frage

  • Hallo,

    ich habe ein Problem mit dem Microsoft Virtual Modem Com Port Treibern "usbser.sys"

    Ich habe leider kein passendes Unterforum gefunden. Falls das ein Probem ist bitte verschieben.

    Das Problem ist, dass dieser Treiber ein großen Bug hat den wohl alle kennen aber keiner richtig zuordnen konnten.

    Das Problem ist, dass der virtualle Com port dauerhaft verschwindet bis man das Gerät wieder rein/raus steckt bzw. Bus Resettet.

    Reproduzieren:

    1) USB Gerät dass ein VCP anbietet anschließen. Im Gerätemeanger erscheint Gerät und COM4 wird zugewiesen

    2) Port mit nen Terminal Programm öffnen

    3) Kabel ziehen

    4) Kabel wieder anstecken (Gerät An/Aus geht auch)

    5) Im Terminal Port schließen.

    Ab hier verschwindet der (neue) Port in der Registry und bleibt verschwunden.Das Gerät ist aber normal angeschlossen und der Benutzer weiß nicht was los ist. DasKabel zeihen könnte z.B: auch durch ein kurzen Wackelkontakt passieren oder sonnst was.

    Das Gerät ist aber noch im Hardwaremanger. Aber durch schließen des ungültigen Ports (den es ja durch den Reset nicht mehr gab), hat sich irgendwas im Treiber verhapselt. Lösung bisher ist, den rausziehen als Event abzufangen und selbst den Port vorzeitig zu schließen.

    Gibt es vielleict eine API um ein USB Bus Reset auszulösen?

    Mittwoch, 22. Februar 2012 08:05

Alle Antworten

  • Hallo,

    Du bist hier im Forumsbereich für Entwickler (MSDN). Deine Frage gehört in das entsprechende Anwenderforum:

    http://answers.microsoft.com/de-de/windows/forum/

    Schöne Grüße

    Oliver

    Mittwoch, 22. Februar 2012 08:18
  • Hallo,

    Siverlight ist aber auch ein Endprodukt von Windows und hat hier sogar ein Unterform. Ich entwickle ein Programm. Also bin ich Entwickler. Es ist ein Entwicklerproblem. Mir ging es eher darum, dass es kein Unterforum für API Probleme gibt.

    Vielleicht wurde das nicht klar. Device und Windows Treiber schreibe ich und die Anwendung die daruf fußt auch wieder.

    Mittwoch, 22. Februar 2012 13:54
  • Hallo,

    als erstes: Silverlight ist kein Produkt sondern eine Technologie, die zum entwickeln von Produkten benutzt werden kann.

    Ok, wenn Du wirklich Entwickler bist und ein Problem hast, formuliere bitte dein Posting komplett um und füge bitte alle notwendigen Details bei. Alles was ich bisher lesen kann, deutet eher auf ein Anwenderproblem hin und dann bist Du hier falsch.

    Schöne Grüße

    Oliver

    Mittwoch, 22. Februar 2012 14:25
  • Hallo,

    leider ist mein Problem, dass ich schlecht Dinge erklären kann. Ich hoffe aber, dass ich das Problem trotzdem so gut wie möglich erklären kann.

    usbser.sys ist ein von Microsoft erstellter Modemtreiber der ab XP immer bei ist. Dieser erzeugt einen virtuellen COM Port für Geräte, die das VCP Profil unterstützen. Dieser Treiber unterstützt ausdrücklich kein Suspend Mode, wenn der Port offen ist. Das ist vermutlich auch der Grund für meine Probleme.

    Der Virtuelle Com Port (VCP) wird erzeugt, wenn das Gerät mit USB verbunden wird. usbser.sys legt einen Registry Key unter:

    HARDWARE\DEVICEMAP\SERIALCOMM

    an (\device\usbser00) . Ich kann nun mit Createfile auf diesen COM Port zugreifen. Ich bekomme damit ein Handle den ich mit CloseHandle wieder schließen kann bzw. muss.

    Nun passiert es, dass usbser.sys von sich aus den VCP schließt (weil USB Gerät verschwunden ist) und damit wird der Handle ungültig. Rufe ich CloseHandle mit diesem ungültigen Handle auf, kommt ein Error oder Timeout. Klar.

    Wenn nun aber ein neuer VCP erzeugt wird und ich den ungültigen Handle zum schließen sende, kommt usbser.sys durcheinander. Er entfernt den  (bereis neu erzeugten) Registry key \device\usbser000

    Damit wird der neu erzeugte VCP auch nicht mehr ansprechbar.

    Meine Frage: Wie erkenne ich, dass der Handle ungültig wurde, ohne ihn per CloseHandle zum schließen zu senden?

    Leider kann man das Gesammte Verhalten nur reproduzieren, wenn man ein Gerät hat, dass usbser.sys verwendet.

    Hoffe, das Problem wird nun klarer.

    Danke

    • Als Antwort vorgeschlagen Niko Mix Donnerstag, 15. März 2012 07:27
    • Nicht als Antwort vorgeschlagen Niko Mix Donnerstag, 15. März 2012 07:27
    Freitag, 24. Februar 2012 10:31
  • Hallo,

    ich bin Geräteentwickler und kann das beschriebene Problem reproduzieren. Ich verwende usbser.sys in der Version 5.1.2600.2. Welche hast Du? Hast Du schonmal die Ver. 5.1.2600.3226 ausprobiert, dessen "Problemlösung"

    http://support.microsoft.com/kb/943198

    beschrieben ist. Allerdings scheint es sich um eine andere Problemlösung zu handeln.

    Der zweiten Punkt ist, dass der Port in der Registry auch als aktiver Port eingetragen ist. Prinzipiell stehen aktive COM-Ports nämlich an anderer Stelle als die die du nanntest, nämlich zB

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\Vid_04d8&Pid_000a\123456789088\Device Parameters

    (wobei Vid_<VendorID> & Pid<ProductID> und das naechste Verzeichnis (bei mir 123456789088 zum Testen) die Geräteseriennummer ist).

    darin muß ein key "PortName" vorhanden sein mit dem String-Wert COM<no>, dann gilt der VCOM port als aktiv, sollte also funzen. Tut er aber nicht, obwohl hier vorhanden! Genau wie bei Dir schlägt CreateFile auf diesem Port fehl; werde gleich mal incl. GetLastError debuggen.

    Bei meinem Gerät ist der USB_devicestate =0x20, dh das Gerät wurde vom Treiber korrekt enumeriert. Ich kann da also auch Geräteseitig kein workaround machen - wär ja auch ungewöhnlich, normalerwiese soll ein Treiber ja Hardwareprobleme lösen und nicht umgekehrt... Aber bei DIESEM Treiber ist man echt am Verzweifeln...

    Übrigens: Durch meien Beobachtungen glaube ich nicht, daß das ganze was mit USB-Suspend zu tun hat, wie Du vermutetest. Ich denke eher, daß der Treiber beim Erzeugen des VCOM-ports Mist baut.

    Montag, 2. Juli 2012 17:37
  • Die GetLastError() Antwort nach fehlgeschlagenem CreateFile(...) ist 2 dh File not found. Der billigste Fehler, dh es besagt leider gar nichts.
    Montag, 2. Juli 2012 18:08
  • Hallo!

    Gibt es hier inzwischen eine Lösung?

    Ich habe hier das gleiche Problem auch noch unter Windows7 64-bit (usbser.sys 6.1.7601.17514 win7sp1_rtm.101119-1850).

    Allerdings komme ich von der anderen Seite, ich entwickel eine Steuerung, die den genrischen MS Treiber als CDC Treiber verwendet.

    Eine Unterbrechung der USB Verbindung oder ein Reset des µControllers führt - wie oben beschrieben - zur Nichtereichbarkeit des COM-Ports. Erst ein vermeindliches Schließen des Ports mit anschließendem Trennen/Verbinden der USB Verbindung löst das Problem.

    Oben sind die Interna auf PC Seite sicher besser erklärt.

    Gruß, Dirk

    Freitag, 11. Januar 2013 13:36