Nach der Installation einer großen Anzahl von Updates wollten einige Server nicht mehr sauber herunter fahren, bzw. neu starten.
Gut 20min musste ich mir den folgenden Bildschirm anschauen.
Dabei habe ich mir die Frage gestellt – was tun? Gut, eine VM kann ich über das Hyper-V Management einfach ausschalten, einen Hyper-V Host oder anderen physikalischen Server kann ich über das ILO-Board ausschalten. Die Konsequenzen sind aber nicht immer absehbar.
Die Ursache des Problems war bei allen Systemen (3x virtuell und 1x Hyper-V Host), dass sich ein Services nicht korrekt beenden wollte.
Eine Abfrage der Services …
sc \\server queryex >c:\temp\process.txt
… welche remote noch möglich war lieferte folgendes Ergebnis.
SERVICE_NAME: TrkWks
DISPLAY_NAME: Distributed Link Tracking Client
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 12
FLAGS :
SERVICE_NAME: TrustedInstaller
DISPLAY_NAME: Windows Modules Installer
TYPE : 10 WIN32_OWN_PROCESS
STATE : 3 STOP_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x2
WAIT_HINT : 0x36ee80
PID : 4124
FLAGS :
SERVICE_NAME: UmRdpService
DISPLAY_NAME: Remote Desktop Services UserMode Port Redirector
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
Da die Ausgabe in eine Textdatei erfolgte konnte ich hier einfach eine Suche durchführen und bin dabei mehrfach auf den TrustedInstaller Service gestoßen welcher mit STOP_PENDING das Herunterfahren, bzw. den Neustart des Servers verhinderte.
Ein Beenden des Prozesses mit taskkill half sofort und das Problem war gelöst.
taskkill /S server /PID 4124
Nach dem Neustart wurden nochmals wenige ausstehende Updates installiert und der Server läuft wieder ohne Probleme.
Auf einem Hyper-V Host hatte ich das gleiche Problem, hier wollte eine VM sich nicht beenden und nach über 1h Warten habe ich mich entschlossen den Prozess der VM zu beenden.
SERVICE_NAME: vds
DISPLAY_NAME: Virtual Disk
TYPE : 10 WIN32_OWN_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 1076
FLAGS :
SERVICE_NAME: vmms
DISPLAY_NAME: Hyper-V Virtual Machine Management
TYPE : 10 WIN32_OWN_PROCESS
STATE : 3 STOP_PENDING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_PRESHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0xdcb
WAIT_HINT : 0x7d0
PID : 1112
FLAGS :
SERVICE_NAME: W32Time
DISPLAY_NAME: Windows Time
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 844
FLAGS :
Das Beenden erfolgt wiederum über taskkill.exe und der entsprechenden Prozess-ID (1112).
Nach dem Neustart des Hyper-V Hosts hat lediglich die VM einen “unexpected shutdown” gemeldet, alle anderen VMs waren davon nicht betroffen.
Generell erscheint mir diese Vorgehensweise (auch bei Hyper-V Hosts) die deutlich sinnvollere als einfach den Server aus zu schalten. Ein Power-Reset betrifft gleich immer alle darauf laufenden Systeme was auch mal einige VMs beschädigen kann.
Enjoy it, b!
Windows SBS and Essentials Blog 
MS @ it’s best. Diese Updates hängen andauernd, auf servern öfters als auf workstations.
Oft habe ich das Problem nicht, aber hin und wieder schon. Daher bin ich froh über diesen Workaround das bisher immer hinbekommen zu haben.