RegisterDeviceNotification schlägt immer mit Error 13 fehl

**OldGrumpy**

Hallo zusammen,

ich hab mal wieder ein seltsames Problem *grins*

Ich versuche auf das Abziehen/Anstecken eines USB-Geräts zu reagieren, ohne RegisterDeviceNotification funktioniert das leider nicht, ich bekomme in meiner Notify-Funktion dann nur WM_DEVICECHANGE mit wParam=$0007 ("DEV_NODES_CHANGED") zu sehen, ohne weitere Infos was sich wo geändert hat.

Daraufhin wollte ich dann schauen ob sich das mit RegisterDeviceNotification ändern lässt, doch irgendwo klemmts da ganz enorm. Ich habe aus den Jedis die DBT.pas und JvComputerInfoEx.pas in meine Uses-Liste aufgenommen und arbeite mit den Typedefs von dort. Mein Code beschränkt sich dann auf folgendes:

zusammenfalten · markieren

Delphi-Quellcode:

			Procedure TTestForm.RegisterUsbNotification;

var

  UsbNotifyInfo: TDevBroadcastDeviceinterfaceA;

  Examine: Pointer;

  Error: Cardinal;

begin

  ZeroMemory(@UsbNotifyInfo, sizeof(UsbNotifyInfo));

  UsbNotifyInfo.dbcc_size:=sizeof(UsbNotifyInfo);

  UsbNotifyInfo.dbcc_devicetype:=DBT_DEVTYP_DEVICEINTERFACE;

  UsbNotifyInfo.dbcc_reserved:=0;

  UsbNotifyInfo.dbcc_classguid:=StringToGuid('{A5DCBF10-6530-11D2-901F-00C04FB951ED}');

  Examine:=RegisterDeviceNotification(self.WindowHandle, @UsbNotifyInfo, 0); //0=DEVICE_NOTIFY_WINDOW_HANDLE

  Error:=GetLastError;

end;

Leider ist nach dem Aufruf von RegisterDeviceNotification Examine=Nil und GetLastError liefert den Wert 13 ("ERROR_INVALID_DATA"). Ich hab schon den halben Tag mit Google verbracht aber nichts hilfreiches gefunden, bei Delphi3000 steht sogar ein Artikel der bis auf eigene Typedefs praktisch alles genauso macht wie mein Code - wo ist der Haken? Hilfäh!

Welche GUID ist das denn? Wenn sie aus dem INF-File kommt, dann ist es die falsche. Ein USB-Geraet hat naemlich zwei GUIDs. Eine fuer die Setup Class und eine fuer den Treiber. Die GUID aus dem INF-File ist immer die Setup Class.
Schau dich mal unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\U SB um. Da sollte sich die andere auch finden lassen.

**OldGrumpy**

Die GUID hab ich aus dem

Sample bei Delphi3000 entnommen, um zu testen obs damit geht - aber auch die GUID geht nicht. Unter Enum\USB finde ich zwar mein Device, aber woher kriege ich da eine GUID mit der ich arbeiten kann? Oh, ich seh schon, andere Devices haben einen Wert "ClassGUID", "mein" Device aber nicht *grmpf*

Edit: Auch mit der GUID für GUID_DEVCLASS_USB (siehe

hier) bekomme ich den gleichen Fehler. Mach ich denn da was grundsätzliches falsch?

Die ClassGUID ist genau die falsche. Schau mal nach "Driver". Gerne ist die GUID in einem der anderen Strings enthalten.

Mach doch mal mit AllocateHWnd ein unsichtbares Fenster fuer genau diesen Einsatzzweck. Vielleicht faengst du ja die Message nicht richtig ab.
Meine HID-Komponente

http://www.soft-gem.net/HID.php macht das so. Klau ruhig von den Sourcen.

**OldGrumpy**

Komischerweise seh ich da nix was einer GUID auch nur nahe käm - ich häng mal den Registry-Export an. Vielleicht bin ich ja auch nur wieder blind für das Offensichtliche

Edit: Man sollte das Ding auch einstöpseln - es gibt jetzt einen weiteren Eintrag unter dem entsprechenden Node, ich häng das neue File mal auch noch an. Übrigens steht da unter "Driver": {36FC9E60-C465-11CF-8056-444553540000}\0036 - und unter ClassGUID {36FC9E60-C465-11CF-8056-444553540000} - wenn die also falsch ist, welche soll ich dann nehmen? Fast ganz unten im Reg-File taucht übrigens auch ein Bekannter wieder auf, unter "Symbolic Name" findet sich die GUID die ich in meinem Ursprungspost verwendet hab...

Ich habe mal nachgeschaut und es scheint ein Dongle zu sein. Geht es hier um die Umgehung des Dongles? Die Google-Suche hat haufenweise Warez-Seiten ausgeworfen. Das Ding scheint schon geknackt worden zu sein.
Ich denke ich helfe jetzt sicherheitshalber nicht weiter als bis zur erfolgreichen Benutzung von RegisterDeviceNotification.

**OldGrumpy**

Nein, es geht genau um das Gegenteil. Wir setzen das Ding in der Firma ein und mein Chef will jetzt halt, dass die Applikation auch darauf reagiert wenn das Dongle im laufenden Betrieb abgezogen wird. Was google dazu so auswirft, kann ich nicht sagen, die Website des Herstellers ist

www.ftsafe.com - tut ja auch nix zur Sache. Wäre ich an der Umgehung interessiert, würde ich sicherlich nicht hier fragen

Unsere Applikation steuert ausserdem noch Hardware via USB an, da käme dann das gleiche Thema wieder auf - von mir aus können wir den ganzen Salat auch mit dem Registryzweig von der USB-Hardware mit FT245BL aus diskutieren... Das Problem bleibt ja das gleiche.

Nachtrag: Wenn das mit dem RegisterDeviceNotification mal klappt, ist der Rest ja auch gegessen, das Handling für WM_DEVICECHANGE ist schon fertig, kriegt halt nur keine Infos weil das Ding wohl kein "port device" ist - vgl. MSDN und diverse Diskussionen hier schon (ja, ich habe ausführlich die Boardsuche gequält *g*)

2. Nachtrag: Im Detail gehts halt darum dass die Applikation ein relativ kritisches Timing einhalten muss und die Kommunikation mit dem Dongle via API tierisch lahm ist, selbst das Auslagern in einen extra Thread beseitigt nicht alle Nebenwirkungen. Deswegen wollte ich die Checks auf ein Mindestmass beschränken indem ich nur teste, wenn sich am USB was getan hat. Und da klemmts nun aufs Derbste

Trigger doch einfach auf WM_DEVICECHANGE DBT_DEVNODES_CHANGED. Das sollte man auch ohne RegisterDeviceNotification bekommen. Es loest aber noch nicht das Problem der Enumeration, denn man will ja herauskriegen ob das Geraet verschwunden ist. Die Enumeration mit den SetupDi-Funktionen sollte aber mit der GUID_DEVCLASS_USB funktionieren. Ich schau mal zuhause nach was ich da an Sourcen habe.

**OldGrumpy**

Na gut, das wäre dann ein Notbehelf - der immer noch nicht erklärt, warum diese in etlichen Tutorials genauso benutzte Funktion bei mir nicht geht

Natürlich kann ich auch auf das DBT_DEVNODES_CHANGED hin triggern, aber das kriege ich auch ab und zu ohne dass sich was im System bemerkbar geändert hat, hatte heute vormittag mal einen Breakpoint in der entsprechenden Proc gesetzt und der triggerte alle paar Minuten. Der Knackpunkt ist halt, dass der Check möglichst effizient laufen soll, alle Devices enummerieren dauert auch wieder ein Weilchen...

Danke auf jeden Fall für den Input

Edit: Typos...

**c113plpbr**

Ich hatte soeben dasselbe Problem mit dieser Funktion, und habe herausfinden müssen, dass es an der Struktur TDevBroadcastDeviceInterfaceA liegt. Diese war falsch deklariert (ist kein "packed record"), zmd. in den Jedi's von vor 2 Monaten (vor 5. April 07). Robert Marquardt hat das zwischenzeitlich korrigiert.

Nur für den Fall, dass es außer mir noch jemanden gibt, der sich damit rumärgert ...

mfg,
Philipp