26
Server fährt um 22:04 einfach runter
Hi,
ich habe seit drei Tagen das Problem das sich das Blech einfach runter fährt, ohne jeglichen Grund.
Dachte erst es liegt an den Updates, aber auch nach dem deaktivieren fährt er runter.
Starte ich ihn dann, kommt der Hinweis "Updates werden installiert schalten sie die........."
Seltsam?!
Auch die Fehlersuche mit der Ereignisanzeige brachte kein Erfolg.
Hat einer einen Tipp wie ich weiter vorgehen soll ?
Trojaner, Viren etc sind auch nicht der Grund.
VG
ich habe seit drei Tagen das Problem das sich das Blech einfach runter fährt, ohne jeglichen Grund.
Dachte erst es liegt an den Updates, aber auch nach dem deaktivieren fährt er runter.
Starte ich ihn dann, kommt der Hinweis "Updates werden installiert schalten sie die........."
Seltsam?!
Auch die Fehlersuche mit der Ereignisanzeige brachte kein Erfolg.
Hat einer einen Tipp wie ich weiter vorgehen soll ?
Trojaner, Viren etc sind auch nicht der Grund.
VG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667510
Url: https://administrator.de/contentid/667510
Ausgedruckt am: 25.11.2024 um 06:11 Uhr
26 Kommentare
Neuester Kommentar
Servus,
läuft da vielleicht ein Update nicht durch und du hast als Nutzungsdauer einen Zeitraum XX.XX bis 22:00 Uhr angegeben, nach dem das System automatisch neu starten darf?
läuft da vielleicht ein Update nicht durch und du hast als Nutzungsdauer einen Zeitraum XX.XX bis 22:00 Uhr angegeben, nach dem das System automatisch neu starten darf?
Ist der Server durch eine USV abgesichert? Gibt es produzierendes Gewerbe in deiner Umgebung? Hat der Energieversorger oder die Haustechnik eventuell Wartungsarbeiten angekündigt?
Ja ist er. Daran kann es nicht liegen. Strom ist durchgehend vorhanden
Sieht eigentlich gut aus, was die Updates angeht. Aber wenn es Probleme geben sollte sollte das nicht im Log stehen ?
Nutzungsdauer einen Zeitraum......
Das könnte das Problem sein, habe es jetzt mal in der Gruppenrichtlinien deaktiviert. Mal schauen was heute Abend passiert.
Kann ich den Server nicht so loggen lassen das er jede Kleinigkeit aufzeichnet ?
Das könnte das Problem sein, habe es jetzt mal in der Gruppenrichtlinien deaktiviert. Mal schauen was heute Abend passiert.
Kann ich den Server nicht so loggen lassen das er jede Kleinigkeit aufzeichnet ?
Moin,
guck mal in die Aufgabenplanung, was denn so um die Zeit gestartet wird. Bei mir war es mal ein wildgewordener Backup-Prozess, der den Server immer zur selben Zeit sporadisch hat neustarten lassen.
Liebe Grüße
Erik
guck mal in die Aufgabenplanung, was denn so um die Zeit gestartet wird. Bei mir war es mal ein wildgewordener Backup-Prozess, der den Server immer zur selben Zeit sporadisch hat neustarten lassen.
Liebe Grüße
Erik
Das System wurde neu gestartet ohne, dass es zuvor ordnungsgemäß heruntergefahren wurde
und
Das System wurde am ... um ... unerwartet heruntergefahren
sprechen dafür, dass der Server abstürzt oder einfach mal der Strom weg ist.
Du hast ja eine USV dran. Kann es sein, dass die gegen 22:00 einen Akkutest fährt und weil die Akkus defekt sind dann ausgangsseitig abschaltet? 45 Minuten später war dann der Strom wieder da. Vielleicht weil dann die Akkus wieder (teilweise) geladen waren und die USV den Ausgangskreis wieder eingeschaltet hat?!
Manuel
Ne die USV ist das nicht. Ich habe den dann nach 45 Minuten wieder angeschaltet.
Jetzt gerade eben wieder, aus !
Jetzt gerade eben wieder, aus !
Ist der Server eventuell einfach nicht aktiviert oder wird nicht lizenzkonform verwendet? Erkennt man häufig nur daran, dass irgendwo ein Eintrag vom Typ Information auf einen Lizenzverstoß hinweist.
Bin mir nicht sicher, aber ich meine es könnte eher unter Anwendung als unter System zu finden sein.
Bin mir nicht sicher, aber ich meine es könnte eher unter Anwendung als unter System zu finden sein.
sieh auch alles gut aus..... ich hasse solche Fehler....
Moin,
auf der Kiste läuft zwar der Defender, aber gibt es eine AV-Lösung, die (warum auch immer) eine falsche Policy abbekommen hat und lautet "schalte nach einem AV-Scan den Server aus"?
Wobei das jedoch gegen "unerwartet heruntergefahren" sprechen täte.
Einen BSOD kannst du auch ausschließen?
Ggf. mal einen Monitor anschließen und per Kamera filmen, was da so passiert!?
Du schreibst ja im Ausgangspost
Welche Dienste (=Anwendungen) laufen auf dem System?
Gruß
em-pie
auf der Kiste läuft zwar der Defender, aber gibt es eine AV-Lösung, die (warum auch immer) eine falsche Policy abbekommen hat und lautet "schalte nach einem AV-Scan den Server aus"?
Wobei das jedoch gegen "unerwartet heruntergefahren" sprechen täte.
Einen BSOD kannst du auch ausschließen?
Ggf. mal einen Monitor anschließen und per Kamera filmen, was da so passiert!?
Du schreibst ja im Ausgangspost
... das Problem das sich das Blech einfach runter fährt ...
Daher ghe ich mal davon aus, dass dein Windows direkt auf dem Server läuft und keine VM ist, richtig?Welche Dienste (=Anwendungen) laufen auf dem System?
Gruß
em-pie
Daher ghe ich mal davon aus, dass dein Windows direkt auf dem Server läuft und keine VM ist, richtig?
Im Screenshot siehst du, dass es eine VM ist. Blech würde sich nicht mit einem "Common KVM Processor" melden.Zitat von @tikayevent:
Das ist mir auch aufgefallen, war mir aber nicht sicher. Daher meine Frage.Daher ghe ich mal davon aus, dass dein Windows direkt auf dem Server läuft und keine VM ist, richtig?
Im Screenshot siehst du, dass es eine VM ist. Blech würde sich nicht mit einem "Common KVM Processor" melden.Wenn das wirklich eine VM ist, sind die Ursachen womöglich anders gelagert.
Laut Eventlog fährt der Server ja nicht runter. Zumindest nicht ordentlich. Sonst würde ja beim wieder hoch fahren nicht im Eventlog stehen, dass er zuletzt nicht ordnungsgemäß heruntergefahren wurde.
Bleibt eigentlich nur noch ein Bluescreen wenn es die USV nicht ist.
Ich würde mir mal alle Einträge vor dem "Crash" ansehen (auch auf dem Host). Auf einer VM könnte bspw auch plötzlich die vHD weg sein, weil der Hypervisor ein Problem hat. Oder wenn es ein SAN/NAS ist könnte das Device kurzzeitig weg sein.
Möglichkeiten gibt es da viele...
Manuel
PS: Das mit dem Herunterfahren bei Lizenzverletzung haben doch nur die SmallBusiness-Server gemacht. Oder irre ich mich?
Bleibt eigentlich nur noch ein Bluescreen wenn es die USV nicht ist.
Ich würde mir mal alle Einträge vor dem "Crash" ansehen (auch auf dem Host). Auf einer VM könnte bspw auch plötzlich die vHD weg sein, weil der Hypervisor ein Problem hat. Oder wenn es ein SAN/NAS ist könnte das Device kurzzeitig weg sein.
Möglichkeiten gibt es da viele...
Manuel
PS: Das mit dem Herunterfahren bei Lizenzverletzung haben doch nur die SmallBusiness-Server gemacht. Oder irre ich mich?
PS: Das mit dem Herunterfahren bei Lizenzverletzung haben doch nur die SmallBusiness-Server gemacht. Oder irre ich mich?
Machen auch die Essential-Server. Hat ein Essential-Server nicht die FSMO-Rollen => ShutdownAber ich habe es auch schon bei nicht aktivierten normalen Windows Servern gesehen.
Daher die Frage und daher sollte der TO auch ins Eventlog schauen, ob da was steht. Es kann ja auch andere Gründe für Lizenzverstöße geben, nicht nur eine fehlende Aktivierung.
Hi,
vielleicht kommst du über das kleine Speicherabbild weiter.
Ist zwar ein Bild aus W10, aber das ist beim Server identisch. Dann das Speicherabbild mit einem Dump-Analyzer durchgehen. Hilfestellung:
MS - Lesen der kleinen Speicherabbilddatei
Download Debugging-Tools for Windows
Gruß NV
vielleicht kommst du über das kleine Speicherabbild weiter.
Ist zwar ein Bild aus W10, aber das ist beim Server identisch. Dann das Speicherabbild mit einem Dump-Analyzer durchgehen. Hilfestellung:
MS - Lesen der kleinen Speicherabbilddatei
Download Debugging-Tools for Windows
Gruß NV
Sieht für mich nach Update-Problem aus. Alle auf dem Updateverlauf-Screenshot gezeigten Updates sind vom 9.6.2021. Sind die wirklich alle aktuell oder versucht der Rechner (sogar erfolgreiche) Updates immer wieder nachzuinstallieren? Evtl. steigt er bei einem der Updates aus und macht einen Neustart. Der angezeigte Verlauf sieht ja so aus, als ob alles klappt. Die Kombi "viele Updates zum selben Zeitpunkt" und "Neustart" legen den Verdacht aber immerhin nahe. Wie sah der Updateverlauf am Folgetag aus? Wie heute?
Guck unbedingt aber auch auf dem Host, was da um die Uhrzeit passiert. Ich hatte vor kurzem (Windows Server 2019 auf Debian-KVM-Host) wiederholte Abbrüche größerer Datensicherungen, weil auf dem Host der OOM-Killer eingriff. Vielleicht kann das auch bei Updates passieren? (Ursache war übrigens keine Überbuchung sondern das Zusammenwirken von Windows-VSS mit dem Hypervisor. Vielleicht setzt Windows-Update auch VSS ein? Wäre ja nicht ganz fernliegend).
Hast Du ein Monitoring für Host und Server? RAM, Festplatte und Prozessor auf Host und VM zu betrachten hilft manchmal auch bei der Ursachenfindung.
Gruß commodity
Guck unbedingt aber auch auf dem Host, was da um die Uhrzeit passiert. Ich hatte vor kurzem (Windows Server 2019 auf Debian-KVM-Host) wiederholte Abbrüche größerer Datensicherungen, weil auf dem Host der OOM-Killer eingriff. Vielleicht kann das auch bei Updates passieren? (Ursache war übrigens keine Überbuchung sondern das Zusammenwirken von Windows-VSS mit dem Hypervisor. Vielleicht setzt Windows-Update auch VSS ein? Wäre ja nicht ganz fernliegend).
Hast Du ein Monitoring für Host und Server? RAM, Festplatte und Prozessor auf Host und VM zu betrachten hilft manchmal auch bei der Ursachenfindung.
Gruß commodity
Der Windows Gast läuft unter Proxmox schon mehrer Jahre problemlos.
Unter anderem laufen da auch noch 10 andere Gäste.
Dachte auch erst das der Proxmox da ein Problem hat aber keinen Eintrag in den Logs.
Und warum auch sollte er nur eine VM runterfahren?
Nach dem ich das letzt Update unter Windows rausgeschmissen habe lief die Kiste jetzt 4 Tage problemlos durch.
Die Updates habe ich deaktiviert, so das ich das auch ausschließen kann.
Gestern Abend ging es wieder los.
Ich hänge mal ein paar Ereignisse an, die kurz vor dem Absturz entstanden.
Diese Fehler sollten sich jedoch nicht negativ auf die Funktionalität ausüben.
Unter anderem laufen da auch noch 10 andere Gäste.
Dachte auch erst das der Proxmox da ein Problem hat aber keinen Eintrag in den Logs.
Und warum auch sollte er nur eine VM runterfahren?
Nach dem ich das letzt Update unter Windows rausgeschmissen habe lief die Kiste jetzt 4 Tage problemlos durch.
Die Updates habe ich deaktiviert, so das ich das auch ausschließen kann.
Gestern Abend ging es wieder los.
Ich hänge mal ein paar Ereignisse an, die kurz vor dem Absturz entstanden.
Diese Fehler sollten sich jedoch nicht negativ auf die Funktionalität ausüben.
Zitat von @achim22:
Der Windows Gast läuft unter Proxmox schon mehrer Jahre problemlos.
Unter anderem laufen da auch noch 10 andere Gäste.
Der Windows Gast läuft unter Proxmox schon mehrer Jahre problemlos.
Unter anderem laufen da auch noch 10 andere Gäste.
Der OOM-Killer killt nur den Prozess, der für das Speicherleck ursächlich ist. In diesem Falle wäre es völlig natürlich, dass nur die betroffene VM gestoppt wird. Die These Speicherleck war natürlich nur ein Schuss ins Blaue und wenn Du ins Syslog des Hosts geschaut und dazu nichts gefunden hast, wird es das nicht sein.
Deine paar Fehlerchen im Windows-Log sind es eher nicht. Wenn um 23 Uhr herunter gefahren wird, sind es kaum die Fehler von 21 oder 18 Uhr. Vielleicht denkbar, aber unwahrscheinlich.
Ich würde bei diesem Erscheinungsbild jedenfalls zuerst sicher ausschließen, ob das Linux die Maschine killt, was Du im Syslog ja unschwer findest, wenn die Uhrzeiten abgeglichen sind.
Gruß commodity
Ich habe gerade noch einmal geschaut. Finde das alles normal aussieht.
Werde die VM aber heute mal auf einen anderen Host schieben.
Werde die VM aber heute mal auf einen anderen Host schieben.
Jun 15 21:00:29 pve systemd[6838]: gpg-agent.socket: Succeeded.
Jun 15 21:00:29 pve systemd[6838]: Closed GnuPG cryptographic agent and passphrase cache.
Jun 15 21:00:29 pve systemd[6838]: gpg-agent-extra.socket: Succeeded.
Jun 15 21:00:29 pve systemd[6838]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Jun 15 21:00:29 pve systemd[6838]: dirmngr.socket: Succeeded.
Jun 15 21:00:29 pve systemd[6838]: Closed GnuPG network certificate management daemon.
Jun 15 21:00:29 pve systemd[6838]: gpg-agent-ssh.socket: Succeeded.
Jun 15 21:00:29 pve systemd[6838]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Jun 15 21:00:29 pve systemd[6838]: gpg-agent-browser.socket: Succeeded.
Jun 15 21:00:29 pve systemd[6838]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Jun 15 21:00:29 pve systemd[6838]: Reached target Shutdown.
Jun 15 21:00:29 pve systemd[6838]: systemd-exit.service: Succeeded.
Jun 15 21:00:29 pve systemd[6838]: Started Exit the Session.
Jun 15 21:00:29 pve systemd[6838]: Reached target Exit the Session.
Jun 15 21:00:29 pve systemd[1]: user@0.service: Succeeded.
Jun 15 21:00:29 pve systemd[1]: Stopped User Manager for UID 0.
Jun 15 21:00:29 pve systemd[1]: Stopping User Runtime Directory /run/user/0...
Jun 15 21:00:29 pve systemd[1]: run-user-0.mount: Succeeded.
Jun 15 21:00:29 pve systemd[1]: user-runtime-dir@0.service: Succeeded.
Jun 15 21:00:29 pve systemd[1]: Stopped User Runtime Directory /run/user/0.
Jun 15 21:00:29 pve systemd[1]: Removed slice User Slice of UID 0.
Jun 15 21:01:00 pve systemd[1]: Starting Proxmox VE replication runner...
Jun 15 21:01:01 pve systemd[1]: pvesr.service: Succeeded.
Jun 15 21:01:01 pve systemd[1]: Started Proxmox VE replication runner.
Jun 15 21:01:05 pve smartd[3056]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 60 to 62
Jun 15 21:02:00 pve systemd[1]: Starting Proxmox VE replication runner...
Jun 15 21:02:01 pve systemd[1]: pvesr.service: Succeeded.
Jun 15 21:02:01 pve systemd[1]: Started Proxmox VE replication runner.
Jun 15 21:03:00 pve systemd[1]: Starting Proxmox VE replication runner...
Jun 15 21:03:01 pve systemd[1]: pvesr.service: Succeeded.
Jun 15 21:03:01 pve systemd[1]: Started Proxmox VE replication runner.
Jun 15 21:04:00 pve systemd[1]: Starting Proxmox VE replication runner...
Jun 15 21:04:01 pve systemd[1]: pvesr.service: Succeeded.
Jun 15 21:04:01 pve systemd[1]: Started Proxmox VE replication runner.
Jun 15 21:05:00 pve systemd[1]: Starting Proxmox VE replication runner...
Jun 15 21:05:01 pve systemd[1]: pvesr.service: Succeeded.
Jun 15 21:05:01 pve systemd[1]: Started Proxmox VE replication runner.
Jun 15 21:06:00 pve systemd[1]: Starting Proxmox VE replication runner...
Jun 15 21:06:01 pve systemd[1]: pvesr.service: Succeeded.
Jun 15 21:06:01 pve systemd[1]: Started Proxmox VE replication runner.
Jun 15 21:07:00 pve systemd[1]: Starting Proxmox VE replication runner...
Jun 15 21:07:01 pve systemd[1]: pvesr.service: Succeeded.
Jun 15 21:07:01 pve systemd[1]: Started Proxmox VE replication runner.
Jun 15 21:08:00 pve systemd[1]: Starting Proxmox VE replication runner...
Jun 15 21:08:01 pve systemd[1]: pvesr.service: Succeeded.
Jun 15 21:08:01 pve systemd[1]: Started Proxmox VE replication runner.
Jun 15 21:09:00 pve systemd[1]: Starting Proxmox VE replication runner...
Jun 15 21:09:01 pve systemd[1]: pvesr.service: Succeeded.
Jun 15 21:09:01 pve systemd[1]: Started Proxmox VE replication runner.
Jun 15 21:10:00 pve systemd[1]: Starting Proxmox VE replication runner...
Jun 15 21:10:01 pve systemd[1]: pvesr.service: Succeeded.
Jun 15 21:10:01 pve systemd[1]: Started Proxmox VE replication runner.
Sieht für mich nicht nach der Herunterfahr-Zeit aus. Die Kernel-Power-Meldung war doch um 23:09:30 h.
Zitat von @commodity:
Sieht für mich nicht nach der Herunterfahr-Zeit aus. Die Kernel-Power-Meldung war doch um 23:09:30 h.
Da hat er den Server ja auch wieder gestartet.Sieht für mich nicht nach der Herunterfahr-Zeit aus. Die Kernel-Power-Meldung war doch um 23:09:30 h.
Wenn du am Server den Stecker ziehst, hat Windows (oder auch jedes andere OS) ja gar keine Chance noch ein Eventlog abzusetzen.
Folglich findet der Eventlog-Eintrag erst mit dem Start des Systems statt.
Ich würde die VM auch mal auf einen anderen Host verschieben. Wenn das Problem weiterhin besteht, ist der PROXMOX schon mal raus (fürs erste jedenfalls). Dann kann das (harte) herunterfahren nur von extern oder aus der VM selbst heraus kommen.
Gruß
em-pie
Verstanden. Die Meldung wird erst beim Neustart protokolliert - und der war um 23:09 h.
Dann ist das Syslog raus. Wenn Proxmox das Problem wäre, würde das Syslog das mitbekommen, denke ich. Dann eher das Windows-System selbst.
Kurze Google-Recherche: Absturz mit ID 41 könnte auf Treiberfehler hinweisen. Wäre das ein Ansatz? Veraltete Virtio-Treiber?
Dann ist das Syslog raus. Wenn Proxmox das Problem wäre, würde das Syslog das mitbekommen, denke ich. Dann eher das Windows-System selbst.
Kurze Google-Recherche: Absturz mit ID 41 könnte auf Treiberfehler hinweisen. Wäre das ein Ansatz? Veraltete Virtio-Treiber?
Moin,
Hast Du das mal gemacht?
Liebe Grüße
Erik
Zitat von @erikro:
guck mal in die Aufgabenplanung, was denn so um die Zeit gestartet wird. Bei mir war es mal ein wildgewordener Backup-Prozess, der den Server immer zur selben Zeit sporadisch hat neustarten lassen.
guck mal in die Aufgabenplanung, was denn so um die Zeit gestartet wird. Bei mir war es mal ein wildgewordener Backup-Prozess, der den Server immer zur selben Zeit sporadisch hat neustarten lassen.
Hast Du das mal gemacht?
Liebe Grüße
Erik
Zitat von @erikro:
Moin,
Hast Du das mal gemacht?
Liebe Grüße
Erik
Moin,
Zitat von @erikro:
guck mal in die Aufgabenplanung, was denn so um die Zeit gestartet wird. Bei mir war es mal ein wildgewordener Backup-Prozess, der den Server immer zur selben Zeit sporadisch hat neustarten lassen.
guck mal in die Aufgabenplanung, was denn so um die Zeit gestartet wird. Bei mir war es mal ein wildgewordener Backup-Prozess, der den Server immer zur selben Zeit sporadisch hat neustarten lassen.
Hast Du das mal gemacht?
Liebe Grüße
Erik
Ja habe ich. Mittlerweile hält er sich nicht mehr an Zeiten und fährt auch sporadisch runter.
VG
Zitat von @commodity:
Verstanden. Die Meldung wird erst beim Neustart protokolliert - und der war um 23:09 h.
Dann ist das Syslog raus. Wenn Proxmox das Problem wäre, würde das Syslog das mitbekommen, denke ich. Dann eher das Windows-System selbst.
Kurze Google-Recherche: Absturz mit ID 41 könnte auf Treiberfehler hinweisen. Wäre das ein Ansatz? Veraltete Virtio-Treiber?
Verstanden. Die Meldung wird erst beim Neustart protokolliert - und der war um 23:09 h.
Dann ist das Syslog raus. Wenn Proxmox das Problem wäre, würde das Syslog das mitbekommen, denke ich. Dann eher das Windows-System selbst.
Kurze Google-Recherche: Absturz mit ID 41 könnte auf Treiberfehler hinweisen. Wäre das ein Ansatz? Veraltete Virtio-Treiber?
Das wäre noch eine Idee. Werde mal schauen auf welchem stand der ist.
