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.
   
   
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:
   
   
   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: net use Z: /delete
2. Windows API: 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.


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 von Sir Rufo:

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.