Windows 10: Reboot unvollständig? – Merkwürdigkeit I

Zum ‘kurz vor’ Wochenende kippe ich noch ein paar Merkwürdigkeiten hier im Blog rein – in der Hoffnung, dass über Schwarm-Intelligenz Erklärungen, offizielle Fundstellen gefunden, oder Leute aufgeschreckt werden. In Merkwürdigkeit I geht es um Windows 10 und den Umstand, dass ein Neustart wohl unvollständig ist.


Anzeige

Auf das Ganze hat mich Michael Bormann bei Google+ aufmerksam gemacht. Weil Michael immer recht kurz und knackig formuliert, drösele ich es einfach mal ein wenig auf.

Ein wenig Hintergrundgeplänkel

Normalerweise sollte es so sein, dass man bei kumulativen Updates oder anderen Geschichten Windows 10 neu starten lässt. Wird per Windows Update angeboten und man kann ja auch die Schaltfläche Ein/Aus anwählen und Neu starten wählen.

Windows neu starten

Als normal denkender Mensch würde man annehmen, dass dann Schicht im Schacht ist und Windows 10 richtig heruntergefahren und denn wieder “vom Scratch” gebootet wird. Aber das ist falsch gedacht, da der Schnellstart da dazwischen funkt.

Kluge Menschen halten daher die Umschalt-Taste bei Anwahl des Befehls Neu starten gedrückt, um einen sauberen Neustart einzuleiten. Der führt dann zu Windows PE, wo man Fortsetzen wählt und Windows 10 wieder booten lässt. Und es gibt Leute, die den Schnellstart standardmäßig deaktivieren, um sich viel Ärger zu ersparen (siehe Windows 10: Schnellstart abschalten).

Neustart, aber Windows 10 ‘lebt’ als als Zombie weiter?

Kommen wir nun zur Beobachtung die Michael Bormann hier dokumentiert hat. Bei ihm laufen mehrere reale Maschinen. Auf denen kam auch das Dezember-Update für Windows 10 sowie ein Office-Update. Deren Installationen erforderten jeweils einen Neustart des Systems. Soweit so gut – nun gab es aber plötzlich Probleme und Ungereimtheiten auf den Maschinen.

  • Outlook hing gelegentlich auf den Maschinen
  • Anwendungen starteten nicht beim ersten Mal

Eine Kontrolle der Systemparameter ergab dann unglaubliches. Mit dem PowerShell-Befehl:

(get-date) – (gcim Win32_OperatingSystem).LastBootUpTime


Werbung

lässt sich abfragen, wie lange die Maschine bereits gelaufen ist. Hier ist die Angabe für eine virtuelle Maschine, in der Windows 10 läuft.

BootUp-Time

Gut, das arme Windows 10 Enterprise habe ich die letzten Stunden arg traktiert, in BlueScreens geschickt, abgewürgt etc., weil ich das in einem Buchprojekt zu W10 Insides brauche. Die UpTime des Betriebssystems ist mit 1 Stunde angegeben, nachdem ich die VM reaktiviert habe.

Und hier nun die Boot-UpTime eines Systems, welches Michael Bormann betreut. Man erinnere sich: Es gab den Dezember Patchday und die Maschinen waren (im Rahmen der Update-Installation) mehrfach neu gestartet worden.

Da ist er, der Windows 10-Zombie, lebt er, trotz mehrfachem Re-Boot doch schon 21 Tage und 17 Stunden. Michael schreibt:

Manchmal läuft Win, in diesem Fall win10 nicht so richtig gut, man hat aber keine Ahnung warum.

Updates drin, keine Fehler und dennoch läuft es anders.

Grund ist wahrscheinlich ein nicht kompletter Reboot aus welchen Gründen auch immer, sieht man z.B. an der Systemlaufzeit die munter weiterläuft obwohl reboot…?

Bei Home & Pro bei 5! Maschinen aufgetreten, wirklich mal runterfahren & ausschalten und nicht den üblichen Neustart und dann passt es wieder, einen tieferen Hintergrund habe ich dann nicht mehr entdecken können, aber dann lief alles wieder.

Dinge die man nicht logisch erklären kann

Auf meine Nachfrage hat er noch angegeben, dass es reale Maschinen waren, die mit “typischer Reboot nach Dezember Update, danach kam Office, wieder reboot” jeweils neu gestartet wurden. Aber die BootUp-Zeit lief munter weiter. Erst das komplette Ausschalten der Maschinen behob das Problem (neben Ungereimtheiten von Outlook (hing), manche Anwendungen starteten nicht beim ersten Mal., Zeit läuft weiter) final. Und es gab diesen Nachtrag von ihm:

Danke, das ist auch noch nie passiert bisher, erstmalig seit dem Dez16 Update der bei mir am 14.12. eingespielt wurde und ab dann lief die Laufzeit hoch; eben nicht nur auf einer Maschine und alle sind sogar unterschiedlich bestückt.

Irgend jemand von Euch mit ähnlichen Beobachtungen oder gar jemand, der sich einen Reim darauf machen kann?

Ergänzung: Ein MVP-Kollege hat sich mit einer ähnlichen Beobachtung bei Facebook gemeldet. Schnellstart ist ausgeschaltet, trotzdem tauchen Symbole geöffneter Anwendungen nach dem Neustart in der Taskleiste auf. Irgend etwas ist an Windows 10 seit Dezember sauer.

Artikelreihe
Windows 10: Reboot unvollständig? – Merkwürdigkeit I
Office 2010: Telefonaktivierung eingestellt? – Merkwürdigkeit II
Windows 7/8.1: Treiberaktualisierung killt System – Merkwürdigkeit III

Ähnliche Artikel:
Windows 10 Wiki/FAQ
Windows 10 Upgrade-Troubleshooting FAQ – Teil 1
Anmeldung fehlt bei Windows 10 Version 1607
Windows 10-Fix: Store startet / funktioniert nicht mehr
Windows 10: Schnellstart abschalten


Anzeige
Dieser Beitrag wurde unter Windows 10 abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

15 Responses to Windows 10: Reboot unvollständig? – Merkwürdigkeit I

  1. Grisu_1968 sagt:

    Solch ein bzw. ähnliches Problem hab ich auch schon festgestellt, aber schon im Oktober. Der PC braucht zum starten sehr lange und beim Herunterfahren dauert es auch sehr lange und eine Meldung kommt das auf gpsvc gewartet wird. Das habe ich aber nur bei deaktiviertem Schnellstart. Ist der PC mit Schnellstart eingerichtet kommt es nicht vor. Mit Schnellstart hab ich zumindest bei mir an 1 PC weniger Probleme. So kann ich nicht der Empfehlung folgen denn Schnellstart zu deaktivieren wie es oft in Foren empfohlen wird.

  2. Peter sagt:

    Was gibt denn bei solchen Fällen der Befehl “systeminfo” in einer Command Line (cmd.exe) für eine “System Boot Time” aus?

  3. Werbung

  4. Nils sagt:

    Wieso merkwürdig? Ich dachte es ist normal, dass Windows 10 beim normalen Herunterfahren und beim Neustart über die GUI nicht vollständig herunterfährt…. Stichwort Hybridmodus (Schnellstart).

    Nur bei shutdown.exe /r fährt der Rechner wirklich vollständig runter und startet neu.

    • Dem ist bei Neustarts i.d.R. eben nicht so – und ich bin mal davon ausgegangen, dass der Neustart beim Update auch das vollständige Herunterfahren verwendet.

      • Nils sagt:

        Na, da wäre nicht mir aber nicht so sicher. Die Beispiele hier sprechen auch eine andere Sprache.

        Ich bin der Meinung, wenn der Hybridmodus (Schnellstart) aktiviert ist, dann Verhält sich der Neustart über das Startmenü eben anders als wenn der Schnellstart nicht aktiviert ist.

  5. Peter sagt:

    Ist denn auch probiert worden, mit der rechten Maustaste auf das Logo und dort “Neustart” zu wählen.

    Meines Wissens ist das ein Unterschied.

  6. Potrimpo sagt:

    Übersehe ich da etwas? Das letzte Windows 10 Update bei mir, also das Dez. Update, war am 14.12. – also so ungefähr die 20 Tage. Bei mir wurden 21 Tage Laufzeit angezeigt, so ziemlich genau der Zeitraum seit dem letzten Update (mit dort erforderlichem Reboot). Gerade hab ich spaßeshalber einen Neustart mittels “Neu starten” durchgeführt – Systemzeit beginnt wieder bei 0.00.00.00. Bei mir ist übrigens der Schnellstart aktiviert.

  7. Tim sagt:

    Interessant…

    Ich kann das Phänomen auch insofern bestätigen (hatte aber keine Probleme),
    dass der Rechner an dem der “Schnellstart” standardmäßig nicht deaktiviert ist, ist hier angeblich seit 12 Tagen am laufen gewesen ist, obwohl er in dieser Zeit mehrfach neugestartet worden sein sollte/ müsste…

    Direkt nach einem bewussten “neu starten” übers Startmenü wurde der Zähler aber jetzt zurückgesetzt.

    Werden durch/mit Schnellstart und die “neue” Swapfile.sys (nicht Pagefile) vielleicht grundsätzlich nicht mehr alle Neustarts, zum Beispiel nach Installationen, als voller Reboot durchgeführt, außer man wählt diesen direkt im Startmenü per neu starten oder per shutdown /r direkt aus? Würde erklären warum Daten erhalten bleiben können.

    • Potrimpo sagt:

      Wenn der Ruhezustand – auch ohne Schnellstart – aktiviert ist, löst das “Herunterfahren” kein vollständiges Herunterfahren aus. Sämtliche Daten werden in der hiberfile.sys gespeichert. Ist der Schnellstart aktiviert, werden weniger Daten in der hiberfile.sys gespeichert, der Start funktioniert noch schneller.

      Lediglich ein “vollständiges Herunterfahren” (Shift und Herunterfahren) bzw.
      shutdown /r oder! “Neu starten” führt dann zu einem echten Reboot.

      Wenn also der Ruhezustand aktiviert ist oder gar der Schnellstart, ist das Verhalten mithin völlig normal. Im o.g. Beispiel wurden Updates Mitte des Monats installiert und dadurch mehrere (echte) Reboots per Neustart durchgeführt. Anschließend sind die Rechner offensichtlich regelmäßig in den “klassischen” Ruhezustand gegangen bzw., wenn Schnellstart aktiviert war, in den “erweiterten” Ruhezustand (Hybridmodus).

      Da die letzten “echten” Reboots anlässlich der Updates gegen Mitte Dezember erfolgten, wurde seitdem die Betriebszeit fortgeschrieben. Ruhezustand oder Hybridmodus resetten die Betriebszeit nicht.

      Ich kann insoweit die Aussage nicht nachvollziehen: “Systemzeit munter weiterläuft, trotz reboot”. Updates inkl. angeblich nicht durchgeführter Reboots erfolgten ja ungefähr 15.12., 20 Tage später ist der 5.1. – also genau wie erwartet und auch angezeigt.

      • Tim sagt:

        “Ich kann insoweit die Aussage nicht nachvollziehen: „Systemzeit munter weiterläuft, trotz reboot“.”

        Das kommt nun halt drauf an, woher Windows die Systemzeit bezieht… Wenn Daten in Hiberfile, Swapfile und Pagefile abgelegt und ausgelesen werden und das Bios/ UEFI nicht durch einen echten Reboot zurückgesetzt werden, ergibt sich durchaus eine Möglichkeit, wie Windows auf eine kontinuierlich weiterlaufende “Laufzeit” kommen kann, ohne das ein System tatsächlich durchgelaufen ist. Wie genau ist denn diese Angabe der Laufzeit überhaupt? Ein Systemstart ist nicht gleichzeitig ein Reset. Der Reset der Daten erfolgt halt nur noch, wie Du auch schreibst, bei einem gewollten Neustart.

  8. Werbung

  9. Andreas B. sagt:

    Mir scheint es, dass nur die echten Komplett-Reboots mit dem Windows-Startsound kommen, die Zombies sind lautlos. – Ich weiß, Windows-Startsound ist total überflüssig, aber jetzt fiel es auf, nachdem ich mit (Admin-Konsole) “powercfg/h off” das böse Spiel mit den Pseudo-Starts definitiv beendet habe.
    Das Allerübelste war, dass das Dezember-Update (KB3206632) mit holprigem Reboot (Sekundenbruchteils-Bluescreen! – lt. Ereignisanzeige: “Kritisch; Kernel-Power: Ereignis-ID 41”) bei mir die Energieoptionen trotz abgeschaltetem Schnellstart komplett vergurkt hat und seither nach “Herunterfahren” die Akkus dann im Tiefschlaf komplett geleert wurden. Das ist wohl übrigens genau das, was ja auch im oben verlinkten Blog-Artikel Windows 10: Schnellstart abschalten als eines der worst-case-Szenarien beschrieben wird. (Meine Schilderung hier ff.)
    Wäre vielleicht interessant, ob andere bei diesem Dezember-Update in der Ereignisanzeige auch diesen Fehler finden können, der Bluescreen selbst war ja wie gesagt kaum zu sehen.

  10. Diejenigen die hier glauben es besser zu wissen ohne genau zu lesen

    im Rahmen des Updates der Reboot der bis zu diesem Zeitpunkt die Uptime auf 0 gesetzt hatte, ab dem Tag ging es durch schlichten Neustart nicht mehr, bei 5 Maschinen.

    Wer sich die Mühe gemacht hätte, der findet auch den Shot vom Uptime.exe das nach wie vor unter Win10 noch läuft (mit einer kleinen Ausnahme, /s läuft auf ein Problemchen beim Traverse der lokalen Ereignisanzeige)

    Da die Zeitausgaben bei allen drei Methoden gleich sind seit mindestens WinNT! , liegt der zu lesende Schlüssel logisch in der Registry, nix Page- oder sonstige File^^ dessen Strukturen sich ja verändert haben.

    Evtl. hat ja einer der Antworter gerade etwas Zeit den Key rauszufummeln, sonst werde ich das mal irgendwann nachschieben.

    • Tim sagt:

      “Da die Zeitausgaben bei allen drei Methoden gleich sind seit mindestens WinNT! , liegt der zu lesende Schlüssel logisch in der Registry”

      Wirklich?

      War Uptime nicht schon immer auch nur ein Schätzeisen?

      “This tool is most accurate when run with administrator privileges, however, even without administrator privileges, the tool attempts to make a best estimate based on available information. In all cases, the results should be considered estimates.”

      https://support.microsoft.com/en-us/kb/232243

      • Andreas B. sagt:

        Bleibt immer noch die Frage, warum das passiert. Und bei mir ist es passiert, trotz deaktiertem Schnellstart. Irgendwas ist beim Reboot vom Dezember-Update oberfaul. (In der Powershell – als Admin – bekam ich so ziemlich das gleiche zu sehen wie hier oben auf den Screenshots.)

      • @Tim,

        die Zeitangaben stimmen mit PS und WMIC auf den Bruchteil einer Sekunde überein.

        Sowohl auf Servern als auch Workstations.

        Was du mit deinem Einwand bezwecken möchtest entzieht sich mir.
        Arbeite doch lieber an dem Feature mit als es unreflektiert gleich zu negieren, so lese ich dich in der Vergangenheit eher nicht, also begebe dich in die Tiefen und lamentiere weniger^^

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.