Unerklärbare Verzögerung von 40 Sekunden

[Krampfadler 0]

Hallo zusammen,

 

auf einem Windows 2008 R2-Server haben wir manchmal ein seltsames Phänomen in einem VB-Script. Das Script benötigt plötzlich 30-50x so lange wie normal (= ca. 200 statt 5 Sekunden). Hat der Server einmal diesen Zustand erreicht, bleibt diese lange Laufzeit des Scripts so lange reproduzierbar, bis der Server neu gestartet wird. Dann ist alles wieder gut bis irgendwann (typischerweise nach einigen Tagen) das Problem urplötzlich wieder auftaucht.

 

Es ist mir gelungen, das Problem auf folgende Zeilen einzugrenzen. Mit diesem Vierzeiler kann ich sofort prüfen, ob das Problem derzeit besteht oder nicht:

Set WshNetwork = CreateObject("WScript.Network")
WScript.Echo "1"
Set objLocalPrinters = WshNetwork.EnumPrinterConnections
WScript.Echo "2"

Normalerweise werden die beiden Ziffern "1" und "2" sofort hintereinander ausgegeben. Im Falles des Problems erscheinen die beiden Ziffern in einem Abstand von exakt 40 Sekunden.

 

Die CPU-Last des Servers ist auch in diesen 40 Sekunden nahezu 0, das Verbinden von Druckern von einem Printserver geschieht schnell, auf Netzlaufwerke kann ebenfalls zugegriffenen werden, die Drucker werden in der Systemsteuerung problemlos angezeigt. Neustart des Spoolerdienstes nützt nichts, wobei interessant ist, dass wenn der Spoolerdienst nicht läuft, das Script zwar eine Fehlermeldung "Laufzeitfehler in Microsoft VBScript: Der Remoteservercomputer ist existiert nicht oder ist nicht verfügbar" erzeugt, aber erst NACH dieser 40-Sekunden-Pause.

 

Hat jemand eine Idee? Die konstante Verzögerung von 40 Sekunden riecht ja stark nach einem Timeout, doch wo anfangen zu suchen?

 

(Es ist ein Citrix-Server mit XenApp 7.6, doch vermute ich mal, dass dies keine Rolle spielt.)

 

Danke für jeden Hinweis.

[Nobbyaushb 1.359]

hmmm, kniffelig.

 

Wenn es ein echtes Problem am Server gibt, solltest du zeitgleich Einträge im Eventlog finden.

 

Anderen Ansatz hätte ich auch erst mal nicht.

 

;)

[Krampfadler 0]

Klar, Eventlog habe ich natürlich durchgesehen, doch nichts in dieser Zeit gefunden. Zusätzlich bin ich auch mit Process Monitor und Process Explorer drübergegangen, doch nichts Auffälliges entdeckt. cscript.exe werkelte mit niedrigster CPU-Last vor sich hin schien gar nichts zu tun, nach 40 Sekunden war der Prozess dann weg und die nächste Zeile ausgeführt. Ich habe auch mal in einer Schleife die ermittelten Drucker ausgegeben, die waren alle korrekt, doch wie gesagt: Ich vermute, dass die Wartezeit schon vor dem eigentlichen Enumerieren der Drucker entsteht. Aber wo?

[blub 115]

löscht du die nicht mehr benötigten Objekte?

 

set wshNetwork = Nothing

set wShell = Nothing 

 

https://msdn.microsoft.com/en-us/library/f8tbc79x%28v=vs.84%29.aspx

[Krampfadler 0]

Im Originalscript ja, in diesem Demo-Vierzeiler habe ich es weggelassen. Das Phänomen existiert jedoch unabhängig davon.

[blub 115]

Bin eigentlich kein Freund von solchen Alibitipps, aber in dem Fall ist es vielleicht tatsächlich am Einfachsten und Sinnvollsten :-)

Wollt ihr vielleicht doch langsam mal auf Powershell umsteigen? Das ist nicht nur comfortabler, sondern auch die Resourcenverwaltung ist sicher besser als bei VBS.

 

"add-printer"
https://technet.microsoft.com/de-de/%5Clibrary/hh918353%28v=wps.630%29.aspx

[Krampfadler 0]

Es geht nicht um Powershell vs. VBS, möglicherweise bauen wir das Script tatsächlich mal auf Powershell um. Ich habe das Phänomen (das auch an anderen Stellen auftritt, unabhängig von dem genannten Script!) eben mit diesen paar Zeilen VBS schön reproduzieren können, und hoffte dabei, dass gleich jemand schreit: "40 Sekunden? Hatten wir auch mal, liegt an XXX". Scheint jedoch nicht der Fall zu sein :-)

 

add-printer geht im übrigen so schnell wie die entsprechende VBS-Funktion WshNetwork.AddWindowsPrinterConnection. Nur das Enumerieren dauert besagte 40 Sekunden. Ich denke auch nicht, dass es am Scripting Host liegt, sondern an irgendetwas, was tief im System vergraben liegt. Aber wo?

[NilsK 2.785]

Moin,

 

klingt nach einem Timeout. Nur wo der herkommt - keine Idee.

 

Sind andere Netzwerkzugriffe ebenfalls verzögert, wenn das Phänomen auftritt?

 

Gruß, Nils

[blub 115]

Nimm dir einen Netzwerkmonitor wie Wireshark und vergleiche was vor "Set objLocalPrinters = WshNetwork.EnumPrinterConnections" im Gutfall und Schlechtfall passiert. Wenn das nichts bringt, dann den Process Monitor

[Weingeist 157]

Bei einem Printer habe ich ein ähnliches Phänomen, wirklich nachvollziehen konnte ich es bis jetzt nicht wirklich. Allerdings habe ich das Problem, wenn ich den Printer verbinde. Es rauschen ca. 20 Printer in 0,0 nix durch. Bei einem gibts aber immer eine Pause um die 20-40 Sekunden. Dann ist er aber auch verbunden und funktioniert einwandfrei.

 

Ich habe mehrere Drucker am gleichen Anschluss auf dem gleichen Printserver definiert. Unterschied ist lediglich die unterschiedlichen Standardeinstellungen. Die anderen Drucker auf dem gleichen Anschluss rauschen einfach durch, Einer macht Probleme. Nicht mal der erste, wo man es auf die Treiberabfrage schieben könnte. Andere Fächer mit identischen Einstellungen machen wiederum keine Probleme. Sehr komisch. Seltsamerweise ist es auch nicht auf jedem Client der Fall.

 

Meine Vermutung geht in die Richtung, dass eventuell irgendwo noch Überreste von der alten Printserver-Adresse rumfliegen die ich noch nicht gefunden habe. Vielleicht wurde das nicht sauber entfernt beim trennen/löschen und nu will er zuerst diesen Kontaktieren, was aber nicht geht.

 

Der Printer-Freigabename ist bei mir gleich geblieben, der Printserver hat aber gewechselt.

[daabm 1.185]

Deaktiviere mal BiDi in den Druckereinstellungen...

[Krampfadler 0]

Nochmals zur Klarstellung: Das Verbinden der Drucker macht keine Probleme. Nur das Enumerieren (über den Aufruf von EnumPrinterConnections) erzeugt diese Verzögerung. Dasselbe gilt übrigens auch für EnumNetworkDrives - ist der Server in diesem Zustand, dauert auch der Aufruf dieser VBS-Funktion 40 Sekunden. Jedes Mal. Bis zum Reboot des Servers, danach ist alles wieder ganz normal.

 

Es hat also nichts mit dem Drucken an sich zu tun! Ich habe nur das Script solange reduziert, bis ich das Phänomen auf diesen einen Befehl festnageln konnte. Daher vermute ich ja auch, dass sich irgendwas auf Betriebssystemebene verklemmt, vielleicht irgendein Dienst nicht richtig arbeitet oder Ähnliches.

 

Diese 40 Sekunden riechen doch verdammt nach einem Timeout - irgendetwas im System geht schief und die Funktionen gehen dann einen anderen Weg, der dann letztendlich erfolgreich ist. Die Rückgabe der Funktionen ist dann auch immer korrekt, es werden alle Drucker/Netzverbindungen aufgelistet, es erscheint keine Fehlermeldung, der Fehlercode ist 0.

 

(Derzeit haben wir keinen Server in diesem Zustand, in den letzten Wochen kam dies jedoch sporadisch immer wieder vor, zu selten, um es zu reproduzieren, zu häufig, um es zu ignorieren.)