Windows-Bug mit bestimmter Netzlaufwerkskonstellation (*Herausforderung gesucht?*)

[CodeX]

Kurzfassung:
Man kann Netzlaufwerke, die beim Einloggen in Windows nicht verfügbar waren, anschließend per Code nicht mehr trennen bzw. entfernen. Manuell per Rechtsklick im Explorer geht dies jedoch.
Gesucht werden eine Erklärung und ein Workaround für diesen Bug.

Anleitung zum Reproduzieren (Windows XP / 7 / 8.1 / 10):

1. Netzlaufwerk persistent (!) verbinden.
   („Verbindung bei Anmeldung wiederherstellen“)
   Dieses darf sich nicht auf eine lokale Freigabe beziehen, sondern auf einen anderen Rechner oder VM im Netzwerk.
   http://www.delphipraxis.net/attachme...5&d=1439850292
   
2. Die Verbindung zum Rechner mit der Freigabe trennen,
   (Entweder Netzwerkkabel am Zielsystem oder am lokalen System ziehen oder in VM Netzwerk trennen).
   
3. Ausloggen und wieder einloggen (alternativ Rechner neustarten)
   Eine Windows-Sprechblase wird sagen, dass nicht alle Netzlaufwerke wiederhergestellt werden konnten:
   http://www.delphipraxis.net/attachme...3&d=1439850264
   
   Wenn diese Meldung kam, könnt Ihr Euch sicher sein, das Problem gleich reproduzieren zu können. Kam diese nicht, wurde die Verbindung entweder doch nicht getrennt oder das Laufwerk wurde nicht persistent verbunden. Dann die Schritte bitte nochmal lesen!

An dieser Stelle möchte ich das Laufwerk gerne über mein Programm trennen.

3 Möglichkeiten zum Trennen:

1. Kommandozeile:
   Delphi-Quellcode:

   net use Z: /delete

2. Windows API:
   Delphi-Quellcode:

   WNetCancelConnection2(PChar('Z:'), CONNECT_UPDATE_PROFILE, true);

3. Manuell im Explorer per Rechtsklick auf das Laufwerk und „Trennen”

Möglichkeiten 1 & 2 trennen zwar das Netzlaufwerk, jedoch verbleibt das Laufwerkssymbol im Explorer. Es verschwindet erst, wenn man sich aus- und wieder einloggt, oder explorer.exe abschießt und erneut startet.

Allerdings funktioniert die manuelle Variante absolut problemlos, wenn man diese durchführt, ohne vorher per Code oder Kommandozeile anzusetzen. Die Verbindung wird getrennt und das Icon verschwindet.
http://www.delphipraxis.net/attachme...4&d=1439850275

Worin besteht der Unterschied? Was geschieht bei der manuellen Trennung per Kontextmenü, was die anderen Methoden nicht tun?
Die Tatsache, dass das Icon verschwunden ist, wenn man explorer.exe abschießt und erneut startet, deutet für mich sehr stark darauf hin, dass irgendein Cache oder eine interne Laufwerks-Liste nicht korrekt aktualisiert wird. Ich hätte das ja schon längst als Windows-Bug bei Seite gelegt, allerdings besteht das Problem beim manuellen Trennen ja nicht! Also muss es irgendeine Möglichkeit geben...

Ein Zusammenhang mit UAC scheidet für mich aus, da das Problem auch mit XP besteht, wo der Anwender keine unterschiedlichen Tokens besitzt.

Angemerkt sei auch, dass das Trennen von Netzlaufwerken per Code oder Kommandozeile unter normalen Umständen (also wenn nicht persistent, oder wenn mit Verbindung eingeloggt) problemlos funktioniert.

Ich habe nun aktuell versucht, das Kontextmenü per Code aufzurufen und die Prozedur darüber zu starten. Allerdings hat das denselben Effekt wie die Kommandozeile und die API-Funktion. Wie kann das sein? Wie kann sich der manuelle Aufruf dermaßen unterscheiden? Nach etwa einer Woche an Experimenten bin ich nun doch ziemlich verzweifelt. :(

[Sir Rufo]

Das riecht eher danach, dass dort eine Nachricht nicht geschickt wird. Die braucht der Explorer aber. Trennt man das direkt vom Explorer aus, dann braucht der die Nachricht nicht, weil er ja dann weiß, das Laufwerk soll weg.

Einfach mal nach der Nachricht suchen und dann diese Nachricht selber losschicken.

[CodeX]

Zitat:

Zitat von Sir Rufo (Beitrag 1312500)

Einfach mal nach der Nachricht suchen und dann diese Nachricht selber losschicken.

Wie genau soll das gehen? Ich habe schon versucht, mit Spy++ und Winspector draufzuschauen, aber das hat mich leider nicht weitergebracht.

[Sir Rufo]

Das sind die Nachrichten die normal ankommen

Laufwerk verbinden

Code:

<000501> 00CC0206 S WM_DEVICECHANGE Event:DBT_DEVICEARRIVAL dwData:0680EFA0
<000502> 00CC0206 R WM_DEVICECHANGE fComplete:True
<000503> 00CC0206 S message:0xC27D [Registriert:"INTENTAPI_UPDATE"] wParam:00000000 lParam:00000000
<000504> 00CC0206 R message:0xC27D [Registriert:"INTENTAPI_UPDATE"] lResult:00000000
<000505> 00CC0206 P message:0xC28D [Registriert:"ShellFileOpened"] wParam:00000000 lParam:00000000

Laufwerk trennen

Code:

<000506> 00CC0206 S WM_DEVICECHANGE Event:DBT_DEVICEREMOVECOMPLETE dwData:0680EFA0
<000507> 00CC0206 R WM_DEVICECHANGE fComplete:True
<000508> 00CC0206 S message:0xC27D [Registriert:"INTENTAPI_UPDATE"] wParam:00000000 lParam:00000000
<000509> 00CC0206 R message:0xC27D [Registriert:"INTENTAPI_UPDATE"] lResult:00000000

[CodeX]

Wo hast Du das jetzt her?

Ich habe bereits folgende Benachrichtigungen versucht:

Delphi-Quellcode:

SHChangeNotify(SHCNE_DRIVEREMOVED, SHCNF_PATH, PAnsiChar('Z:\'), nil);
SendMessage(HWND_BROADCAST, WM_DEVICECHANGE, DBT_DEVICEREMOVECOMPLETE, 0);
SendMessage(HWND_BROADCAST, WM_DEVICECHANGE, DBT_CONFIGCHANGED, 0);

Hat aber keinen Unterschied gemacht. Bzw. in manchen Tests hat die SHCNE_DRIVEREMOVED das Laufwerk sogar tatsächlich entfernt, aber nur bis zum F5 oder öffnen eines neuen Explorer-Fensters. Mit der Nachricht konnte ich im Prinzip alle Laufwerke visuell entfernen und mit F5 wieder anzeigen... Scheint also nur kosmetisch zu sein.

Wie setzt man die anderen Messages, die du aufgelistet hast, um? Bzw. was ist denn "INTENTAPI_UPDATE"?

[Sir Rufo]

Die Nachrichten habe ich mit Spy++ mitgeschnitten (Tool von Micr*s*ft was beim VS dabei ist).

Was, wie und wo müsstest du da noch eruieren ... bzw. das Wichtigste ist zu prüfen welche Nachricht denn eben nicht verschickt wird und die muss man sich genauer anschauen.

[CodeX]

Zitat:

Zitat von Sir Rufo (Beitrag 1312505)

Die Nachrichten habe ich mit Spy++ mitgeschnitten

Dann scheine ich das falsch verwendet zu haben. Hast du das Fadenkreuz auf ein Explorer-Fenster gezogen und dort dann das Laufwerk getrennt? Ich wurde von Messages erschlagen und wusste gar nicht wonach ich filtern soll.

[Sir Rufo]

Das Trennen habe ich von einem anderen Fenster aus gemacht, weil sonst erschlagen einen ja die Messages, wenn man keinen Filter setzt :mrgreen:

[jaenicke]

Ein mächtiges Werkzeug ist dafür der API Monitor:
http://www.rohitab.com/apimonitor
Damit kann man herausfinden welche API Funktionen der Explorer oder ein anderes Tool aufruft. Vielleicht gibt es ja doch eine Funktion dafür, die auch den Explorer aktualisiert.

[CodeX]

Zitat:

Zitat von Sir Rufo (Beitrag 1312507)

Das Trennen habe ich von einem anderen Fenster aus gemacht, weil sonst erschlagen einen ja die Messages, wenn man keinen Filter setzt :mrgreen:

Also ich musste zwar schmunzeln, aber wirklich schlau werde ich daraus trotzdem nicht. Kannst Du Dein Vorgehen bitte kurz Schritt-für-Schritt beschreiben? Alternativ kurzes Video? Oder Screensharing? Das wäre für die Zukunft sicherlich sehr hilfreich.
Aber unabhängig davon: Wenn ich Dein Ergebnis richtig deute, hast Du genau 2 Messages mitgeschnitten, die jeweils gesendet und empfangen werden. Die erste ist klar (siehe Code in meinem vorherigen Posting). Aber was ist die zweite?
Das war jetzt ohnehin nur beispielhaft bei einem normalen Netzlaufwerk, ohne die besagte fehlerhafte Konstellation, oder?

Zitat:

Zitat von jaenicke (Beitrag 1312512)

Ein mächtiges Werkzeug ist dafür der API Monitor:
http://www.rohitab.com/apimonitor
Damit kann man herausfinden welche API Funktionen der Explorer oder ein anderes Tool aufruft. Vielleicht gibt es ja doch eine Funktion dafür, die auch den Explorer aktualisiert.

Das sieht in der Tat sehr vielversprechend aus. Damit werde ich mich dann heute mal auseinandersetzen. Dadurch, dass das Tool für mich völlig neu ist, befürchte ich nur schon vorab, dass ich damit nicht alles relevante finden/sehen werde. Bist Du mit dem Tool vertraut? Düfte ich dich bitten, da auch mal mit einem geübten Blick draufzuschauen? :oops:

[Sir Rufo]

Nun ja, ein Video, wo du zwei Explorer Fenster siehst, von denen ich das eine Fenster überwache und in dem anderen Fenster das Laufwerk verbinde und wieder trenne, wäre schon etwas Overkill.

[CodeX]

Und welche Einstellungen genau? "Additional Windows"? Welche Auswahl bei "Messages"?
Und der zweite Teil meiner Frage nach der Deutung der zweiten Message?
Mensch, jetzt lass Dir doch nicht alles aus der Nase ziehen. :-D

[CodeX]

Nach einer Stunde mit dem API Monitor weiß ich nun zumindest, dass net.exe bei

Delphi-Quellcode:

net use z: /disconnect

intern auch einfach nur WNetCancelConnection2 aufruft. Das erklärt das gleiche Resultat. Beim Trennen über den Explorer habe ich den Aufruf dieser Funktion allerdings nicht gefunden. Scheinbar macht er das also irgendwie anders!? Das Problem ist, dass die explorer.exe auch noch für tausend andere Dinge zuständig ist und das Monitoring entsprechend viel aufzeichnet, was mich gar nicht interessiert. Ich habe versucht, mich Stück für Stück manuell durchzuhangeln, habe aber leider nicht gesehen, wo das Laufwerk dann tatsächlich getrennt wird. Ich sehe zwar viele Zugriffe auf das Laufwerk wie PathGetDriveNumber oder WNetGetConnection, aber damit alleine komme ich leider nicht weiter. :cry:

[einbeliebigername]

Hallo,

habe jetzt nicht herauslesen können, ob du auch darauf geachtet hast, dass das zu überwachende Explorer-Fenster in einem eigenen Prozess ausgeführt wird. Auch könnte ich mir vorstellen, das es helfen könnte, den Explorer als einen anderen Benutzer auszuführen. Ich könnte mir auch vorstellen das die Nachricht an einen anderen Systemprozess geht, und der Explorer über eine andere API davon erfährt. Probiere doch auch mal einen alternativen Dateibrowser wie Total Commander, ob der sich anders verhält oder andere Aktionen auslöst. Auf alle fälle wirst du viele Nachrichten und API-Funktionen durch Recherche und/oder probieren ausschließen müssen, um die Richtige zu finden.

einbeliebigername.

[Sir Rufo]

Zitat:

Zitat von CodeX (Beitrag 1312552)

Und welche Einstellungen genau? "Additional Windows"? Welche Auswahl bei "Messages"?
Und der zweite Teil meiner Frage nach der Deutung der zweiten Message?
Mensch, jetzt lass Dir doch nicht alles aus der Nase ziehen. :-D

Öhm, einfach ein Explorer Fenster ausgewählt (Titellsite des Fensters) und keine Einschränkungen bei den Messages oder so gemacht.

Dieses überwachte Fenster lasse ich dann komplett in Ruhe und arbeite mit einem anderen Explorer-Fesnter um die Aktionen auszuführen.

Nach dem Verbinden eines Netzlaufwerks schaue ich mir die Meldungen an ... aha, so viele
Und nach dem Trennen des Netzlaufwerks speichere ich die Meldungen in eine Datei.

Mehr ist/war da nicht.

[CodeX]

Zitat:

Zitat von einbeliebigername (Beitrag 1312559)

das zu überwachende Explorer-Fenster in einem eigenen Prozess ausgeführt wird

Wie sollte das gehen?

Zitat:

Zitat von einbeliebigername (Beitrag 1312559)

Auch könnte ich mir vorstellen, das es helfen könnte, den Explorer als einen anderen Benutzer auszuführen.

Das Ausführen des Explorers unter einem anderen lokalen Benutzer hat bei einem kurzen Test nicht funktioniert.

Zitat:

Zitat von einbeliebigername (Beitrag 1312559)

Probiere doch auch mal einen alternativen Dateibrowser wie Total Commander, ob der sich anders verhält oder andere Aktionen auslöst.

Gleiches Fehlverhalten bei:

• Total Commander
• FileZilla
• "Wizzard" im Explorer: Hauptmenü (ALT-Taste) > Tools > Netzlaufwerk trennen ... > Auswahl
• Windows API (WNetCancelConnection2)
• Kommandozeile (net.exe)
• Aufrufen des Kontextmenüs per API: z.B. per Jcl DisplayContextMenu
• Aufrufen des Kontextmenüs über die professionelle Komponente "ShellBrowser" von JAM Software

Funktioniert fehlerfrei:

• Rechtsklick auf Netzlaufwerk im Explorer > Trennen

Das größte Rätsel ist für mich ja weiterhin, warum das Ausführen des Befehls über das Kontextmenü nicht funktioniert, wenn man das Kontextmenü in einer anderen Software aufruft. Ich dachte, das wäre zwar eine Notlösung, muss aber funktionieren, da hier exakt derselbe Kontextmenüpunkt aufgerufen wird. :?

[Dalai]

Zitat:

Zitat von einbeliebigername (Beitrag 1312559)

Auch könnte ich mir vorstellen, das es helfen könnte, den Explorer als einen anderen Benutzer auszuführen.

Das funktioniert ohne Klimmzüge ab Vista nicht mehr (ebensowenig wie das Ausführen als Administrator).

@CodeX: Wie hast du beim Total Commander das Netzlaufwerk getrennt? Via Rechtsklick auf die Pfadleiste (um das Kontextmenü des Laufwerks zu bekommen) und dann Klick auf Trennen oder mit Menü Netz > Netzlaufwerk trennen, das den Systemdialog aufruft? Wenn letzteres: was passiert, wenn du im Explorer diesen Dialog ebenfalls bemühst/benutzt?

MfG Dalai

[CodeX]

@Dalai: Ich habe beide Varianten ausprobiert. Die aus dem Hauptmenü öffnet den gleichen Wizzard wie der Explorer. Bei beiden funktioniert es nicht (siehe auch meine Auflistung im letzten Beitrag). Der Rechtsklick entfernt das Icon auch nicht. Ich nehme an, dass das Kontextmenü auf die gleiche Weise aufgerufen wird, wie ich es zuvor schon versucht habe (ebenfalls siehe Auflistung).

Wie kann denn das Kontextmenü im Explorer ein anderes Ergebnis liefern wie wenn man das Kontextmenü per API in einer anderen Software aufruft?

Edit: Ich möchte kurz darauf hinweisen, dass das Problem nicht nur auf meinem System besteht, sondern bei allen recht einfach reproduzierbar sein sollte. Wer dieses Rätsel mit eigenen Augen sehen möchte, kann dies sehr gerne selbst mal versuchen. Vielleicht packt ja noch jemand anderen der Ehrgeiz, dieses Mysterium zu lösen. Ich würde mich sehr freuen. :)

[einbeliebigername]

Zitat:

Zitat von CodeX (Beitrag 1312563)

Zitat:

Zitat von einbeliebigername (Beitrag 1312559)

das zu überwachende Explorer-Fenster in einem eigenen Prozess ausgeführt wird

Wie sollte das gehen?

In den Ordneroptionen unter Ansicht den Punkt "Ordnerfenster in einem eigenen Prozess starten" anhaken.

Zitat:

Zitat von CodeX (Beitrag 1312563)

Zitat:

Zitat von einbeliebigername (Beitrag 1312559)

Auch könnte ich mir vorstellen, das es helfen könnte, den Explorer als einen anderen Benutzer auszuführen.

Das Ausführen des Explorers unter einem anderen lokalen Benutzer hat bei einem kurzen Test nicht funktioniert.

Zitat:

Zitat von Dalai (Beitrag 1312569)

Das funktioniert ohne Klimmzüge ab Vista nicht mehr (ebensowenig wie das Ausführen als Administrator).

Stimmt. Als anderer Benutzer will der Explorer mit Fehlermeldung nicht mehr. Für als Admin gibt es eine Anleitung http://www.heise.de/ct/hotline/Explo...n-1258468.html.

Zitat:

Zitat von CodeX (Beitrag 1312563)

Zitat:

Zitat von einbeliebigername (Beitrag 1312559)

Probiere doch auch mal einen alternativen Dateibrowser wie Total Commander, ob der sich anders verhält oder andere Aktionen auslöst.

Gleiches Fehlverhalten bei:

• Total Commander
• FileZilla
• "Wizzard" im Explorer: Hauptmenü (ALT-Taste) > Tools > Netzlaufwerk trennen ... > Auswahl
• Windows API (WNetCancelConnection2)
• Kommandozeile (net.exe)
• Aufrufen des Kontextmenüs per API: z.B. per Jcl DisplayContextMenu
• Aufrufen des Kontextmenüs über die professionelle Komponente "ShellBrowser" von JAM Software

Funktioniert fehlerfrei:

• Rechtsklick auf Netzlaufwerk im Explorer > Trennen

Habe ich das jetzt richtig erfasst? Du hast mit den oben genannten Programmen das Netzlaufwerk unter der speziellen Bedingung getrennt und der Explorer hat nicht wie erwartet reagiert. Aber wie sieht es bei den anderen Programmen aus? Reagieren die unter der Bedingung und trennen mit einem anderen Programm richtig?

Zitat:

Zitat von CodeX (Beitrag 1312563)

Das größte Rätsel ist für mich ja weiterhin, warum das Ausführen des Befehls über das Kontextmenü nicht funktioniert, wenn man das Kontextmenü in einer anderen Software aufruft. Ich dachte, das wäre zwar eine Notlösung, muss aber funktionieren, da hier exakt derselbe Kontextmenüpunkt aufgerufen wird. :?

Ich glaube langsam du versuchst einen Workaround für einen Bug im Explorer zu finden. Das lässt sich aber mit zwei Explorer-Prozessen testen. Wenn sich nur der Explorer-Prozess korrekt verhält mit dem das Laufwerk getrennt wird, der andere Explorer-Prozess das Fehlverhalten zeigt und alle anderen Programme richtig reagieren, dann ist das ein Bug im Explorer. Sollte aber alle Explorer-Prozesse richtig reagieren, wenn man das mit einem der Explorer trennt, dann gibt es da noch eine Möglichkeit den Explorer nach dem Trennen auf die Sprünge zu verhelfen.

einbeliebigername.

[CodeX]

Zitat:

Zitat von einbeliebigername (Beitrag 1312573)

In den Ordneroptionen unter Ansicht den Punkt "Ordnerfenster in einem eigenen Prozess starten" anhaken.

Stimmt, das könnte weiterhelfen. Werde ich untersuchen.

Zitat:

Zitat von einbeliebigername (Beitrag 1312573)

Habe ich das jetzt richtig erfasst? Du hast mit den oben genannten Programmen das Netzlaufwerk unter der speziellen Bedingung getrennt und der Explorer hat nicht wie erwartet reagiert. Aber wie sieht es bei den anderen Programmen aus? Reagieren die unter der Bedingung und trennen mit einem anderen Programm richtig?

Erster Teil der Frage: Ja
Zweiter Teil: Bin mir unschlüssig, ob ich deine Frage verstehe. Grunsätzlich ist es so, dass nur der Explorer die verwaisten Laufwerke anzeigt. Nach dem Trennen tauchen diese in anderen Programmen nicht mehr auf. Man kann diese Laufwerke auch direkt im Anschluss per "Netzlaufwerk verbinden" neu zuweisen (der Wizzard zeigt die getrennten Laufwerke auch korrekt als frei an). "Lustigerweise" ändert sich der Name des Laufwerks nicht (bleibt der alte, getrennte), aber das rote X verschwindet und der Speicherkapazitätsbalken ist dann da. Wenn man das Laufwerk jetzt per Rechtsklick trennt, sieht es so aus wie zuvor. Wie das technisch sein kann, weiß ich nicht. Muss man wohl mal mit eigenen Augen gesehen haben.

Zitat:

Zitat von einbeliebigername (Beitrag 1312573)

Ich glaube langsam du versuchst einen Workaround für einen Bug im Explorer zu finden.

Naja, was bleibt mir anderes übrig? Ich möchte Netzlaufwerke aus meiner Software heraus trennen können. Den Anwender interessiert nicht, welche Bugs im Explorer enthalten sind. Er weiß lediglich, wenn er das von Hand macht, dann funktioniert es.

Zitat:

Zitat von einbeliebigername (Beitrag 1312573)

Das lässt sich aber mit zwei Explorer-Prozessen testen. Wenn sich nur der Explorer-Prozess korrekt verhält mit dem das Laufwerk getrennt wird, der andere Explorer-Prozess das Fehlverhalten zeigt und alle anderen Programme richtig reagieren, dann ist das ein Bug im Explorer. Sollte aber alle Explorer-Prozesse richtig reagieren, wenn man das mit einem der Explorer trennt, dann gibt es da noch eine Möglichkeit den Explorer nach dem Trennen auf die Sprünge zu verhelfen.

Soeben getestet: Sowohl im gleichen Prozess als auch bei zwei Fenstern in unterschiedlichen Prozessen (so wie du oben empfohlen hast) verschwindet das Icon SOFORT in beiden Fenstern, wenn man es per Rechtsklick trennt.

[CodeX]

Der Grund, warum sich ein manuell entferntes Laufwerk in allen Explorer-Fenstern gleichzeitig aktualisiert, dürfte alleine diese Message hier sein:

Code:

<000001> 0001015E S WM_DEVICECHANGE Event:DBT_DEVICEREMOVECOMPLETE dwData:00D6F95C
<000002> 0001015E R WM_DEVICECHANGE fComplete:True

Ich glaube, dass das dem hier entsprechen müsste:

Delphi-Quellcode:

SendMessage(HWND_BROADCAST, WM_DEVICECHANGE, DBT_DEVICEREMOVECOMPLETE, 0);

Allerdings führt das nicht zum Löschen des Laufwerks, sondern führt letztlich zu einer Art "F5" in Explorer.
Der API-Monitor ist deshalb wohl meine letzte Chance. Allerdings tue ich es mir damit sehr schwer, etwas brauchbares zu finden. Sollte jemand mit dem Tool oder mit einem anderen Debugging/Monitoring Tool vertraut sein, wäre ich für Hilfe bei der Analyse wirklich sehr dankbar. :!:

Fällt alternativ jemandem ein API-Befehl ein, mit dem man den Explorer quasi komplett reinitialisieren kann oder zumindest die Laufwerke komplett neu aufbauen?

[CodeX]

Ich habe bemerkt, dass die Versendung der DBT_DEVICEREMOVECOMPLETE Nachricht zumindest unvollständig sein dürfte. Keine Ahnung, ob das wirklich das Problem ist, aber ich würde das zumindest doch gerne in korrekter Form ausprobieren.

Ich habe das jetzt so versucht:

Delphi-Quellcode:

const
  DBT_DEVICEREMOVECOMPLETE = 32772;
var
  phdr: PDevBroadcastHdr; //Aus JvComputerInfoEx
begin
  phdr.dbch_size := SizeOf(DEV_BROADCAST_HDR);
  phdr.dbch_devicetype := DBT_DEVTYP_VOLUME;
  SendMessage(HWND_BROADCAST, WM_DEVICECHANGE, DBT_DEVICEREMOVECOMPLETE, INTEGER(@phdr));

//Auszug aus JvComputerInfoEx:
  {$EXTERNALSYM PDevBroadcastHdr}
  PDevBroadcastHdr = ^TDevBroadcastHdr;
  {$EXTERNALSYM DEV_BROADCAST_HDR}
  DEV_BROADCAST_HDR = packed record
    dbch_size: DWORD;
    dbch_devicetype: DWORD;
    dbch_reserved: DWORD;
  end;
  TDevBroadcastHdr = DEV_BROADCAST_HDR;

Aber das kann so nicht stimmen.

MSDN:
WM_DEVICECHANGE message
DBT_DEVICEREMOVECOMPLETE event
Hier steht:

Code:

lParam: A pointer to a structure identifying the device removed. The structure consists of an event-independent header, followed by event-dependent members that describe the device. To use this structure, treat the structure as a DEV_BROADCAST_HDR structure, then check its dbch_devicetype member to determine the device type.

Allerdings sehe ich in DEV_BROADCAST_HDR keine Möglichkeit, ein Laufwerk anzugeben. :?
Was übersehe ich?

[HolgerX]

Hallo..

Du übersiehst da was.. ;)

Wenn deine Application ein WM_DEVICECHANGE Event erhält, dann kann in lParm ein Record sein, welches verschiedenen Inhalt haben kann.

Um zu ermitteln, welches 'richtige' Record darin ist, sollst Du den Pointer mit DEV_BROADCAST_HDR casten und dann dbch_devicetype auslesen.

Anhand dessen Wert wird der Pointer dann mit dem richtigen Record gecastet.



DBT_DEVTYP_DEVICEINTERFACE 0x00000005
Class of devices. This structure is a DEV_BROADCAST_DEVICEINTERFACE structure.

DBT_DEVTYP_HANDLE 0x00000006
File system handle. This structure is a DEV_BROADCAST_HANDLE structure.

DBT_DEVTYP_OEM 0x00000000
OEM- or IHV-defined device type. This structure is a DEV_BROADCAST_OEM structure.

DBT_DEVTYP_PORT 0x00000003
Port device (serial or parallel). This structure is a DEV_BROADCAST_PORT structure.

DBT_DEVTYP_VOLUME 0x00000002
Logical volume. This structure is a DEV_BROADCAST_VOLUME structure.



Somit musst Du in der von Dir generierten Message ein DEV_BROADCAST_VOLUME (https://msdn.microsoft.com/de-de/library/aa363249) angeben mit

dbch_devicetype = DBT_DEVTYP_VOLUME
dbcv_unitmask = 4 // entspricht z.B. D:
dbcv_flags = DBTF_NET // 0x0002

[CodeX]

Danke, aber wo kommt das DEV_BROADCAST_VOLUME denn hin?

Delphi-Quellcode:

const
  DBT_DEVICEREMOVECOMPLETE = 32772;
  DBTF_NET = 2;
var
  phdr: PDevBroadcastHdr;
  pvol: PDevBroadcastVolume;
begin
  pvol.dbcv_size := SizeOf(DEV_BROADCAST_VOLUME);
  pvol.dbcv_devicetype := DBT_DEVTYP_VOLUME;
  pvol.dbcv_unitmask := 26; //Z:
  pvol.dbcv_flags := DBTF_NET;

  phdr.dbch_size := SizeOf(DEV_BROADCAST_HDR);
  phdr.dbch_devicetype := DBT_DEVTYP_VOLUME;

  SendMessage(HWND_BROADCAST, WM_DEVICECHANGE, DBT_DEVICEREMOVECOMPLETE, INTEGER(@phdr));

[HolgerX]

Delphi-Quellcode:

const
  DBT_DEVICEREMOVECOMPLETE = 32772;
  DBTF_NET = 2;
var
  pvol: PDevBroadcastVolume;
begin
  pvol.dbcv_size := SizeOf(DEV_BROADCAST_VOLUME);
  pvol.dbcv_devicetype := DBT_DEVTYP_VOLUME;
  pvol.dbcv_unitmask := 26; //Z:
  pvol.dbcv_flags := DBTF_NET;

  SendMessage(HWND_BROADCAST, WM_DEVICECHANGE, DBT_DEVICEREMOVECOMPLETE, INTEGER(@pvol));

DEV_BROADCAST_HDR wird nicht bei SendMessage verwendet!

Nur, wenn Du die Message selber erhälst und wissen willst, auf was für ein Record lParam zeigt.

Da alle DevBroadcast Records mit den gleichen Feldern anfangen wie DEV_BROADCAST_HDR, kannst Du dann den Typ auslesen um dann mit dem richtigen Typ (z.B. DEV_BROADCAST_VOLUME) zu casten und weiter zu arbeiten.

Wenn es nicht Records währen, sondern Objecte, dann währe DEV_BROADCAST_VOLUME von DEV_BROADCAST_HDR abgeleitet.

Ach ja
pvol.dbcv_unitmask := 26; //Z:
ist falsch, Z: hat die ID 25, da A = ID 0 ist.. ;)

OK auch falsch...
Hier wird eine Bitmaske gebraucht.. $02000000 = Z

[CodeX]

Zitat:

Zitat von HolgerX (Beitrag 1312737)

DEV_BROADCAST_HDR wird nicht bei SendMessage verwendet!

Oh, OK ... das hatte ich irgendwie falsch verstanden.

Zitat:

Zitat von HolgerX (Beitrag 1312737)

Z: hat die ID 25, da A = ID 0 ist.. ;)

Dann ist 4 = D: in deinem Beispiel vorhin aber auch falsch. ;)


Scheinbar knallts aber bei jeder Zuweisung der Werte von pvol:

Code:

Access violation at address 0053CFAD in module 'disconnect.exe'. Write of address 00000000.

Muss das irgendwie noch initialisiert werden? pvol ist erstmal nur nil.

Edit:
Also so bekomme ich die Funktion zum Laufen:

Delphi-Quellcode:

var
  pvol: PDevBroadcastVolume;
  sDrive: String;
const
  DBT_DEVICEREMOVECOMPLETE = 32772;
  DBTF_NET = 2;
  EmptyDevBroadcastVolume: TDevBroadcastVolume = (
    dbcv_size: 0;
    dbcv_devicetype: 0;
    dbcv_reserved: 0;
    dbcv_unitmask: 0;
    dbcv_flags: 0);
begin
  sDrive := 'Z:';
  pvol := @EmptyDevBroadcastVolume;
  pvol.dbcv_size := SizeOf(DEV_BROADCAST_VOLUME);
  pvol.dbcv_devicetype := DBT_DEVTYP_VOLUME;
  pvol.dbcv_unitmask := PathGetDriveNumber(PChar(sDrive))
  pvol.dbcv_flags := DBTF_NET;

  SendMessage(HWND_BROADCAST, WM_DEVICECHANGE, DBT_DEVICEREMOVECOMPLETE, INTEGER(@pvol));

Einen Unterschied scheint es aber dennoch nicht zu machen. Das Laufwerk ist immer noch da. :(

[HolgerX]

Hmm..

Mit meiner Test-Version kann ich dem Explorer mitteilen, das er ein angegebenes Laufwerk aus der Ansicht entfernt.
Das klappt sogar mit meinem Festplatten-Laufwerk D:.

Wieso Du Pointer auf eine Const machst und diese dann verändern willst ist mir schleierhaft ?!?! :?

Der folgende Code ist mit D6 erstellt und läuft unter Win 8.1.
Wenn der Explorer offen ist, kannste ihn dazu bringen, sogar das LW C: auszublenden. Mit einem F5 im Explorer ist es dann wieder da....

Edit:
Korrektur, das Ausblenden von C: mag der Explorer nicht und führt anschließend direkt ein F5 aus ;)

Meine Funktionen GetDrive und GetDriveMask berücksichtigen hier nur jeweils ein Laufwerk.
In der Message kannst Du aber direkt auch alle Laufwerke ausblenden lassen, da die dbcv_unitmask alle von Laufwerke von A-Z auf einmal enthalten kann.

Delphi-Quellcode:

const
  DBT_DEVICEREMOVECOMPLETE = $8004;

  DBT_DEVTYP_VOLUME =  $00000002;

  DBTF_MEDIA = $0001;
  DBTF_NET   = $0002;

type
  PDEV_BROADCAST_HDR = ^DEV_BROADCAST_HDR;
  DEV_BROADCAST_HDR = packed record
    dbch_size : DWORD;
    dbch_devicetype : DWORD;
    dbch_reserved : DWORD;
  end;

  PDEV_BROADCAST_VOLUME = ^DEV_BROADCAST_VOLUME;
  DEV_BROADCAST_VOLUME = packed record
    dbcv_size: DWORD;
    dbcv_devicetype: DWORD;
    dbcv_reserved: DWORD;
    dbcv_unitmask: DWORD;
    dbcv_flags: WORD;
  end;

function GetDrive(unitmask: DWORD): Char;
var
  i: Byte;
begin
  result := ' ';
  for i := 0 to 25 do begin
    if (unitmask and 1) = 1 then begin
      Result := Char(i + Ord('A'));
      break;
    end;
    unitmask := unitmask shr 1;
  end;
end;

function GetDriveMask(Drive: Char): DWORD;
begin
  result := 1 shl (ord(Drive) - ord('A'));
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  DevVol: DEV_BROADCAST_VOLUME;
  sDrive: Char;
begin
  sDrive := Edit1.text[1];
  FillChar(DevVol,SizeOf(DEV_BROADCAST_VOLUME),0);
  DevVol.dbcv_size := SizeOf(DEV_BROADCAST_VOLUME);
  DevVol.dbcv_devicetype := DBT_DEVTYP_VOLUME;
  DevVol.dbcv_unitmask := GetDriveMask(sDrive);
  DevVol.dbcv_flags := DBTF_NET;
  SendMessage(HWND_BROADCAST, WM_DEVICECHANGE, DBT_DEVICEREMOVECOMPLETE, INTEGER(@DevVol));
end;

procedure TForm1.WMDeviceChange(var Msg: TMessage);
begin
  if Msg.WParam = DBT_DEVICEREMOVECOMPLETE then begin
    if PDEV_BROADCAST_HDR(Msg.LParam)^.dbch_devicetype = DBT_DEVTYP_VOLUME then
      ShowMessage(GetDrive(PDEV_BROADCAST_VOLUME(msg.LParam)^.dbcv_unitmask));
  end;
end;

[CodeX]

Ich hatte mich wohl irgendwie in eine Richtung verrannt.
Bei der unitmask lag ich auch noch komplett falsch...
Vielen Dank für deine Unterstützung! :)

Mit Deiner Version kann ich tatsächlich Laufwerke ausblenden. Bei mir bleiben diese auch bei einem F5 weg. Wenn ich den Explorer abschieße und wieder starte, sind die lokalen Laufwerke (korrekterweise) wieder da. Habe es soeben auf 2 Systemen getestet.

Leider funktioniert es nur mit echten Laufwerken, aber mit keinen Netzlaufwerken. Egal ob mit dem "Problem-Szenario" oder ganz normal frisch verbunden. Dabei steht DBTF_NET ja gerade für "Indicated logical volume is a network volume". Oder funktioniert das bei dir (falls kein anderer Rechner/VM vorhanden ist, kann man ja auch ein freigegebenes Verzeichnis auf dem gleichen Rechner mounten)?

[HolgerX]

So...

Hab mich mal ein bischen intensiver mit den 'nicht verbundenen' Netzwerklaufwerken im Explorer beschäftigt.

Anscheinend listet der Explorer auch alle nicht verbundenen (persistenten) Laufwerke auf.

Bei Verwendung von WNetEnumResource werden als RESOURCE_CONNECTED nur die tatsächlich vorhandenen und verfügbaren Connections aufgelistet, erst mit RESOURCE_REMEMBERED auch die getrennten.

Versucht man dann mit WNetCancelConnection2 dieses 'nicht verbundenen' Laufwerk zu löschen kommt der Fehlercode 2250 (ERROR_NOT_CONNECTED) = 'Diese Netzwerkverbindung ist nicht vorhanden.'. Die Anzeige im Explorer bleibt bestehen.

Was ja auch richtig ist, da keine 'aktive' Connection besteht.

Benutzt mann dann 'Trennen' im Explorer wird eventuell das Laufwerk entfernt, manchmal aber auch nicht.

Dies kann ein BUG im Explorer sein oder ein Feature...
Schließlich ist dies eine Info, das etwas mit der Verbindung nicht funktioniert hat! ;)

WM_DEVICECHANGE / DBT_DEVICEREMOVECOMPLETE funktioniert anscheinend tatsächlich nur mit echten DRIVES, also HDs, Wechselplatten, CD-LW.... nicht mit NetzwerkCONNECTIONs..

Somit musste mit dem Explorer so leben, wie es ist, oder einfach keine persistenten Netzwerkverbindungen verwenden.

[CodeX]

Vielen herzlichen Dank für deine Analyse, HolgerX!

Feature oder Bug:
Wenn man ein Netzlaufwerk dieser Konstellation trennt (mit dem Wizzard von Windows per Explorer-Hauptmenü > Extras > Trennen, oder alternativ per net use oder API), dann verbleibt die Verbindung wie schon bekannt sichtbar. Verbindet man jetzt ein neues Netzlaufwerk auf diesen Laufwerksbuchstaben (was ja problemlos geht, auch wenn der Buchstabe laut Explorer schon/noch vergeben ist), wird weiterhin der Name/Pfad der alten Verbindung angezeigt. Klickt man allerdings drauf kommt man ins neu verbundene Verzeichnis. [Edit: Ich habe gerade mal versucht, ein lokales Laufwerk auf den Laufwerksbuchstaben vom halb-getrennten Netzlaufwerk zu legen. Das geht problemlos, nur dass im Explorer das Laufwerk unverändert als getrenntes Netzlaufwerk mit Netzwerknamen angezeigt wird; per Doppelklick kommt man dann allerdings auf den Inhalt des lokalen Laufwerks. Verrückt.]
Zudem: Der Explorer zeigt nach dem "fehlerhaften Trennen" ein Laufwerk an, das nirgends sonst anzeigbar ist. Weder in anderen Tools, noch in anderen Windows-Darstellungen (Netzlaufwerk verbinden, etc.)
Ich glaube, man kann das durchaus als Bug bezeichnen.

Zitat:

Zitat von HolgerX (Beitrag 1312961)

Benutzt mann dann 'Trennen' im Explorer wird eventuell das Laufwerk entfernt, manchmal aber auch nicht.

Das Laufwerk wird meinen Tests nach manuell immer korrekt getrennt und entfernt, sofern man die Trennung zuvor nicht schon auf anderem Wege durchgeführt hat (dann sagt er, die Netzwerkverbindung würde nicht existieren).

Genau das ist auch der Grund, warum es eine Lösung geben muss. Irgendetwas tut der Explorer zusätzlich. Und falls er eine Funktion auslöst, die per API nicht verfügbar ist, dann war mein gedanklicher Ansatz, dass man eben zumindest das "Rechtsklick+Trennen"-Verhalten irgendwie reproduzieren kann. Aus diesem Grund habe ich es zunächst mit diesem Thread hier versucht:
:arrow: http://www.delphipraxis.net/186217-e...usfuehren.html

Wenn man exakt den gleichen Kontextmenüpunkt ausführen könnte, müsste ja auch das gleiche Ergebnis kommen, oder?

Absurderweise scheint das Netzlaufwerk-Kontextmenü, das man per API aufruft zwar exakt so auszusehen und augenscheinlich auch die richtigen Funktionen auszuführen. Aber das betätigen von "Trennen" führt zum gleichen fehlerhaften Ergebnis. Wie kann das sein?
Und: Das Kontextmenü zu einem "halb getrennten" Netzlaufwerk lässt sich im Explorer problemlos öffnen und bedienen, aber per API kann man auf dieses Kontextmenü nicht mehr zugreifen, weil das Laufwerk darüber nicht mehr zugreifbar ist. Ich glaube mittlerweile aber, dass sobald dieser Fehlerfall eingetreten ist, man nichts mehr tun kann (eben ein Explorer-Bug). Aber bevor der Fehler eintritt muss man doch den "Trennen"-Punkt irgendwie exakt so ausführen können wie per Maus, oder?? :wall:

[CodeX]

Ich möchte zwar weiterhin nicht aufgeben, aber ein ganz anderer Lösungsweg wäre ja vielleicht, das an Microsoft heranzutragen, sodass der Fehler behoben werden könnte!? Kann jemand einen möglichst direkten Weg hierfür empfehlen? Per MSDN? Per Insider Programm (Win10)? Direkte Kontakte?

[CodeX]

Ich habe eine Anfrage im Technet gestellt. Seit einer Woche leider ohne nennenswerte Rückmeldung.
Eine direktere Kontaktmöglichkeit habe ich nicht gefunden.
Möchte man über einen "Supportfall" gehen, kostet das entweder 299€ oder man hat ein MSDN- oder Technet-Abonnement. :(
Hat jemand so ein Abo, über das er den Fall für mich einreichen könnte?