USB Treiber mit DDK - auf Hardware entfernen verzichten

[Tobi (Gast)]

Hi!

Ich erstelle gerade einen Treiber für ein USB Gerät
(
Mit Atmega8 simuliertes Gerät, Low Speed, unterstützt nur
Control-Commands,
Abgeleitet von:
  USBasp - USB in-circuit programmer for Atmel AVR controllers
  Thomas Fischl <[e-mail]>
)
mit dem WINDDK.
Der Treiber ist abgeleitet vom "AVR309USB_0" Treiber von Igor Cesko
http://www.cesko.host.sk., der seinen Treiber vom isousb vom WinDDK
ableitet.
Dieser Treiber setzt das "Hardware entfernen oder Auswerfen" Icon in
der Startleiste und Windows schimpft, wenn man das Gerät einfach so vom
System trennt.
Kann man verhindern, das Windows dieses Verhalten zeigt und wie kann
man verhindern das dieses Icon in der Startleiste kommt? Ist das
überhaupt möglich? (Ich denke schon, denn eine USB-Maus wird ja auch
anders behandelt. Auch der USBIO-Treiber verhält sich da anders)
Das ganze muss man wohl im Treiber in der "AddDevice" Funktion
festgelegt werden. Aber welche Flags muss ich wo setzten?
Vielen Dank für eure Hilfe!

MfG Tobi

[René K. (king)]

Das machst Du in der DispatchPnP Funktion, wenn sie mit dem Minor
Function Code IRP_MN_QUERY_CAPABILITIES aufgerufen wird. Wenn Du in der
DEVICE_CAPABILITIES-Struktur "Removable" und "SurpriseRemovalOK" auf
TRUE setzt, sollte das Icon verschwinden (aber vorher den IRP an den
unteren Treiber weiterreichen).

[Tobi (Gast)]

Vielen Dank für die Hilfe!

Leider klappts immer noch nicht. Hab den Minor Function Code
IRP_MN_QUERY_CAPABILITIES in der "isopwr.c" gefunden. Dort gibt es
die Funktion "IsoUsb_QueryCapabilities" (siehe Anhang).
In dieser Funktion habe ich an verschiedenen Stellen (3 mal insgesamt)
"Removable" und "SurpriseRemovalOK" auf TRUE gesetzt und
entsprechend gekennzeichnet. Stimmt das so?

Zur Info: Ist mein allererster Windows Treiber!

MfG Tobi

[René K. (king)]

Du gibst einen falschen Status-Code zurück. IoCallDriver wird sich mit
STATUS_PENDING melden. Du wartest dann auf das Event, das in der
Completition Routine signalisiert wird und gibst jetzt ebenfalls
STATUS_PENDING zurück. Du solltest lieber den Status-Code des unteren
Treibers zurückgeben.

Außerdem darfst Du die Parameter erst dann ändern, wenn der untere
Treiber fertig ist. Die ersten Vorkommen von "SurpriseRemovalOK =
TRUE" habe ich deswegen entfernt.

Ich habe das mal in diese Richtung korrigiert.

BTW: Es ist gar nicht nötig, hier mit viel Aufwand einen IRP zu
allokieren. Du kannst locker den vorhandenen nehmen. Da mir unnötige
allocs immer ein Dorn im Auge sind, habe ich die Funktion so geändert,
daß sie den IRP der DispatchPnP Funktion direkt übernimmt. Mit der
Funktion als solches sollte das hier aber nichts zu tun haben.

Alle Angaben verstehen sich ohne Gewähr, die geänderte Fassung habe ich
weder getestet noch zu übersetzen versucht!

[Tobi (Gast)]

Vielen Dank für deine Hilfe!

Hab die Funktion eingefügt. Die Funktion der Funktion hat sich nicht
geändert. Leider ist das Icon auch noch nicht verschwunden.
Naja, irgenwie finde ich gerade, das das gar nicht so stört...