Tabs verlieren Laufwerk / Verzeichnis

[BOst]

So, Freitag und heute morgen hatten wir jeweils eines dieser "Ereignisse" die wir auch mit dem ProcessMonitor aufzeichnen konnten.
Merkwürdigerweise sind dort _KEINE_ Share-Zugriffe zu sehen, sondern nur die Zugriffe auf C:.
Vielleicht haben wir jetzt ein Laptop, welches den Fehler reproduzierbar mit laufendem ProcessMonitor erzeugen kann.
Hier der Ausschnitt der Wincmd.ini _VOR_ dem TC Start:

[left]
path=M:\IT\CIM\Delphi\Arbeit\Transfer\
ShowAllDetails=1
show=3
sortorder=3
negative Sortorder=1
SpecialView=0
userspec=*.*

[right]
path=M:\userdata\xxx\CimSapTransferEmpfaenger\
ShowAllDetails=1
show=1
sortorder=3
negative Sortorder=1
SpecialView=0
userspec=*.dcu

[lefttabs]
0_path=P:\arbeiten\Start Bg\
0_options=1|3|1|0|0|1|0
1_path=M:\IT\CIM\Delphi\Arbeit\
1_caption=Prg-Arbeit
1_options=1|3|1|0|0|1|0
activetab=2
[righttabs]
0_path=P:\#01muell\
0_options=1|3|1|0|0|1|0
1_path=P:\arbeiten\SQLs\
1_options=1|3|1|0|0|0|0
2_path=P:\#01muell\mailserver\
2_options=1|3|1|0|0|1|0
3_path=M:\userdata\xxx\
3_options=1|3|1|0|0|1|0
activetab=4

Dann unter Beobachtung des ProcessMonitors den TC gestartet und beide Seiten der aktiven Tabs stehen auf C.
Im gesamten PM Trace finden sich KEINE Netzwerk-Zugriffe; auffällig sind ca. zwei Dutzend Fehler FileSystemControl/"Invalid Device Request" (jetzt nur die Filesystemcontrol Ereignisse gefiltert):
07:43:50,4035432 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,4054792 TOTALCMD.EXE 5392 FileSystemControl C:\totalcmd INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7800222 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7804204 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7807324 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7810822 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7812230 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7819484 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7821027 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7825128 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7826832 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7828412 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7831992 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7834792 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7836188 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7837579 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7839230 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7884124 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7889296 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7900278 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7906789 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7909580 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7911899 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7913989 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7916095 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7918226 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7932023 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7934552 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7936646 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7939031 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7941157 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7943009 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7944749 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,7946724 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8338017 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8342631 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8346503 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8352541 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8358342 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8365050 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8369639 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8655027 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8659272 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8664958 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8670225 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8676415 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
07:43:50,8679728 TOTALCMD.EXE 5392 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO


Diese gibt es bei normalen TC aufrufen nur 2 mal, dann gefolgt erfolgreichen von Share-Zugriffen:
08:03:10,3514749 TOTALCMD.EXE 6600 FileSystemControl C:\ INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
08:03:10,3700300 TOTALCMD.EXE 6600 FileSystemControl C:\totalcmd INVALID DEVICE REQUEST Control: FSCTL_LMR_QUERY_DEBUG_INFO
08:03:11,5126371 TOTALCMD.EXE 6600 FileSystemControl \\wshd51\home\bost SUCCESS Control: FSCTL_LMR_QUERY_DEBUG_INFO
08:03:11,5666174 TOTALCMD.EXE 6600 FileSystemControl \\wshd51\home\bost SUCCESS Control: FSCTL_LMR_QUERY_DEBUG_INFO
08:03:11,5852341 TOTALCMD.EXE 6600 FileSystemControl \\wshd51\home\bost SUCCESS Control: FSCTL_LMR_QUERY_DEBUG_INFO
08:03:11,6213666 TOTALCMD.EXE 6600 FileSystemControl \\wshd51\home\bost SUCCESS Control: FSCTL_LMR_QUERY_DEBUG_INFO
08:03:11,6552822 TOTALCMD.EXE 6600 FileSystemControl \\wshd51\home\bost SUCCESS Control: FSCTL_LMR_QUERY_DEBUG_INFO
08:03:11,6893642 TOTALCMD.EXE 6600 FileSystemControl \\wshd51\home\bost SUCCESS Control: FSCTL_LMR_QUERY_DEBUG_INFO
08:03:11,7167450 TOTALCMD.EXE 6600 FileSystemControl \\wshd51\home\bost SUCCESS Control: FSCTL_LMR_QUERY_DEBUG_INFO
08:03:11,7515236 TOTALCMD.EXE 6600 FileSystemControl \\wshd51\home\bost SUCCESS Control: FSCTL_LMR_QUERY_DEBUG_INFO

[BOst]

Bei mir verliert der TC auch den gesperrten aktuellen Tab wenn beim Schließen das NAS aktiv war. Mein TC ist auf super schnell eingestellt und ist beim Start einfach nicht in der Lage die Verbindung herzustellen.

Ist der NAS Tab nicht aktiv, bleibt er erhalten. Ich kann das bei jedem Start reproduzieren.

Das klingt eigentlich genauso wie unser Problem. Nur die aktiven Tabs sind betroffen, egal ob gesperrt oder nicht.

Was meinst Du mit "TC ist auf super schnell eingestellt"?

Momentan können wir das Problem auch am besten mit dem Starten des TC reproduzieren. Es tritt aber auch auf, wenn man von einem anderen Programm zurück auf den bereits laufenden TC wechselt.

[ghisler(Author)]

Hmm, kein Hinweis bisher. Könnten Sie mir vielleicht einen kompletten Trace vom Start des TC zur Verfügung stellen, wo das Problem auftritt? Damit der Trace nicht 1000e fremde Einträge enthält, bitte folgenden Filter setzen:
"Process name" "contains" "totalcmd" "include"

[BOst]

Genauso mit dem Filter haben wir die Traces auch aufgezeichnet.
Kann ich die Trace irgendwo hochladen oder per Mail schicken (eventuell per persönlicher Nachricht)?
Falls eine totalcmd.exe mit Debug-Code existiert (nur 32-bit), kann ich die gerne auf dem Test-Laptop mal ausführen.

[ghisler(Author)]

Wenn die Datei gepackt kleiner als 1 MB ist, bitte an support at ghisler dot com schicken. Ansonsten schreiben Sie mir ein Mail, und ich sende Ihnen eine andere Mailadresse für die Datei.

Debug-Code kann ich leider erst einbauen, wenn ich ungefähr weiss, wo es Probleme gibt - an SetCurrentDirectory scheint es ja offenbar nicht zu liegen. Der Trace des Process Monitors ist das Nützlichste, was ich für die Analyse verwenden könnte.

[BOst]

Ja, der Trace des Laptops ist gezipped 343kb groß. Kommt gleich per Mail.

[BOst]

Der Trace ist bei Herrn Ghisler inzwischen angekommen und er analysiert das.
Da wir ja einen Laptop haben mit dem sich der Fehler gut reproduzieren läßt, haben wir noch mal einen Test mit einem anderen Netzwerklaufwerk gemacht. Dort tritt der Fehler nicht auf. Einen Trace davon haben wir auch gezogen und kann ich bei Bedarf gerne übermitteln.
Also betroffen ist scheinbar nur unsere Share von M:, nicht die Share von P:
Beide Shares liegen auf dem gleichen Server (EMC VNX 5400).
Der Tab-Fehler trat aber bereits auf dem Server-Vorgänger (einer NetApp) in gleicher Weise auf. Laufwerk M: war betroffen, mit den zwei oder drei anderen Shares trat der Fehler auch dort nicht auf. M: ist aber unser Laufwerk mit dem 90% aller Arbeiten ausgeführt werden.
Deshalb schließen wir einen Konfigurationsfehler der CIFS Server eigentlich aus.

Anmerkung: Wir verwenden "Access-based Enumeration" für die Anzeige der Verzeichnisse in den Shares (sowohl auf der VNX, als auch früher auf der NetApp), d.h. der Anwender sieht nur die für ihn berechtigen Verzeichnisse. Das ähnelt dann sehr dem Verhalten der alten Novell Server.
Das normale NTFS Verhalten zeigt ja sonst alle Verzeichnisse an und erst bei einem Zugriffsversuch erhält der Benutzer dann eine Meldung "nicht berechtigt".

[BOst]

Was wir eben noch mal getestet haben:
1. net use G: \\server\share <- G: auf die gleiche Share wie M: -> Fehler tritt auch auf G: auf
2. Das Problem tritt auch auf völlig ohne definierte Tabs; einfach das aktuelle angezeigte Laufwerk ist betroffen
3. wir haben noch mal einen Test mit einer minimalen wincmd.ini (direkt aus einer neuen Installation abgegriffen) ausprobiert -> Problem bleibt bestehen; also schließe ich einen Einfluss durch unsere, teils >10Jahre in Benutzung befindliche, wincmd.ini aus

[Dalai]

Für mich liest sich das so, als ob die Clients irgendeine Art Timeout für die Freigaben/Netzlaufwerke haben, der zu kurz ist, was dazu führt, dass TC gar nicht erst versucht, darauf zuzugreifen.

MfG Dalai

[BOst]

Das greift zu kurz.
Wenn das eine Fehlkonfiguration der Clients wäre, würde sich das über alle Shares erstrecken, nicht nur über m:
In der Traces die wir angefertigt haben, finden sich in den Fällen dieses Fehler überhaupt kein Zugriff auf das Netzwerk. Also auch keine fehlgeschlagenen Zugriffe.
Außerdem wären auch andere Applikationen bestimmt durch ähnliche Fehler schon aufgefallen, was sie nicht sind.
Es gibt einzelne Berichte, das selbst im Hintergrund laufende TCs (also noch bevor sie aktiviert werden) selten auf C: zurück schalten.
Also die Ursache ist noch nicht eingekreist ...

[BOst]

Eine neue Beta-Version vom TC ist bei uns jetzt im Einsatz und es sieht ganz gut aus.
Genaueres berichte ich in der nächsten Woche, wenn mehr Erfahrungen auch aus einem größeren Anwenderkreis vorliegen.
Dann sollte die Programmänderung in die nächste freigegebene TC Version wohl mit einfließen.

[ghisler(Author)]

Ja, wenn die Änderung hilft, wird sie in die nächste öffentliche Version mit einfliessen.

[BOst]

Einen Punkt haben wir ja noch gefunden (meine Mails + Desktop-Video und Trace haben Sie hoffentlich erhalten):
Am einigen Plätzen reproduzierbar springt die Anzeige auf C: bei Einstecken eines USB-Stick oder CDROM einlegen.

[ghisler(Author)]

Ja, da testet TC mit einer ähnlichen Funktion, ob das Laufwerk noch erreichbar ist, wenn Windows die WM_DEVICECHANGE-Meldung schickt.

[BOst]

Der Punkt mit den Umspringenden Anzeigen von M: auf C: bei Datei oder Verzeichnisereignissen ist ja noch offen.
Auf einigen Plätzen ist das reproduzierbar z.B. durch einstecken eines USB Sticks oder einlegen einer CDROM. Es tritt aber auch völlig unvermittelt auf, während der TC im Hintergrund läuft. Man sieht dann plötzlich wie der TC seine Laufwerke verliert und auf C: wechselt.
Wahrscheinlich sind das Dateisystem-Update-Notifies wie sie auch bei Erzeugen von neuen Verzeichnissen an die Applikation verschickt wird.
Können wir das noch mal untersuchen und eventuell den gleichen Prüfcode einsetzen, welcher das Problem beim Programmstart bereits gelöst hat?