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

[einbeliebigername]

Zitat von CodeX:

Zitat von einbeliebigername:

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 von CodeX:

Zitat von einbeliebigername:

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 von Dalai:

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 von CodeX:

Zitat von einbeliebigername:

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 von CodeX:

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 von einbeliebigername:

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

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

Zitat von einbeliebigername:

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 von einbeliebigername:

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 von einbeliebigername:

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: 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