Kategorie: Windows

Wie unter „https://www.nicht-trivial.de/index.php/2018/09/13/druckwarteschlange-stuerzt-unregelmaessig-ab/“ bereits angemerkt, stürzt auf einem Windows Server Betriebssystem unregelmäßig, aber häufig, die Druckwarteschlange ab. Und zwar sowas von „ab“, dass selbst Windows den Dienst selbsttätig nicht mehr startet. In einigen Fällen war sogar der Befehl „net stop Druckwarteschlange“ wirkungslos und produzierte nur den Ereigniseintrag (Eventlog) mit EventID: 7011 „Das Zeitlimit (30000 ms) wurde beim Warten auf eine Transaktionsrückmeldung von Dienst Spooler erreicht.“

Weiterhin sind gehäuft Meldungen mit EventID 1530 aufgetaucht:
„Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß. “ betreffend \Device\HarddiskVolume1\Windows\System32\spoolsv.exe .

Bisher hatte ich die UTAX Druckertreiber in Verdacht. Der Verdacht hat sich nun erhärtet, als ich den Tipp bekam, den virtuellen Druckeranschluss (Standard TCP/IP Port) von RAW auf LPR umzustellen. Seither läuft die Druckwarteschlange stabil.

 

Ein neuer Druckertreiber bringt offensichtlich den Spoolerprozess alias Druckwarteschlange unter Windows Server zum Absturz. Oder genauer gesagt wird die Druckwarteschlange in einen Zustand gebracht, in der sie nicht mehr reagiert, aber nicht ordentlich beendet wird. Das hat zu Folge, dass die Druckwarteschlange von Windows nicht als nichtfunktionierend erkannt und der Dienst neu gestartet wird. Supportanrufe diesbezüglich und manuelles Starten des Dienstes  lassen schnell nach Wegen suchen, die Sache automatisiert aus der Welt zu schaffen.

Die Lösung besteht derzeit daraus, ein Batch-Skript in Endlosschlaufe laufen zu lassen. Das Skript prüft auf Existenz eines vorhandenen Druckers. Wenn dieser nicht auffindbar ist, wird die Druckerwarteschlange neu gestartet.  Da rundll32 keinen auswertbaren Errorlevel zurück gibt, muss man über den Parameter /f eine Datei anlegen, welche als Indikator für den Fehlerfall dient. Bei jedem Neuaufruf der Skriptschleife wird die Datei (bei Existenz) wieder gelöscht.
Die Verzögerung wird über Pings an’s eigene System realisiert.
Ich setze zusätzlich noch eine „1“ per zabbix_sender an mein unabhängiges Monitoring-System Zabbix ab, um die Häufigkeit des Eingriffs mitzuloggen.

das Skript chkPrter.cmd:

@echo off
cls

SET PrinterName=Rechnungsdrucker
SET TESTfile=%TEMP%\PrtExist.txt

:start

REM Delete %TESTfile% to avoid false positives
IF EXIST „%TESTfile%“ (
DEL %TESTfile% /F /Q
)

REM Try to get the printer settings into a file
RUNDLL32.EXE PRINTUI.DLL,PrintUIEntry /Xg /n „%PrinterName%“ /f „%TESTfile%“ /q

IF EXIST „%TESTfile%“ (
REM ECHO Drucker %PrinterName% existiert
REM „C:\Program Files\zabbix\zabbix_sender.exe“ -z zabbixserver.local -s ServerXYZ -k serverZYX.printer.spooler -o 1 > NUL
) ELSE (
REM ECHO Drucker %PrinterName% existiert NICHT!
NET START Druckwarteschlange
REM „C:\Program Files\zabbix\zabbix_sender.exe“ -z zabbixserver.local -s ServerXYZ -k serverZYX.printer.spooler -o 0
)

ping -n 30 localhost > NUL

goto start