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.

[CodeX]

Zitat von Sir Rufo:

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

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

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

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 von 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.

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?