Beiträge von miksbl

Weder Downgrade auf 0.1.297 noch Upgrade auf 0.1.300 haben nachhaltig Abhilfe geschaffen.

Eine zuverlässige Arbeit auf und mit dem Server ist nicht möglich.

Der Netcup Support scheint das Problem nicht ernst zu nehmen. Habt ihr Ideen?

Seit dem Downgrade scheint es stabil zu laufen, zumindest mal seit den letzten 20 Stunden. Jetzt kam dann auch die Antwort vom Netcup Support:

Zitat

Das ist ein kürzlich entdeckter Fehler in den VirtIO-Treibern. Sie können eine Vorabversion mit Fix hier herunterladen:

https://fedorapeople.org/groups/virt/vi…hql-0.1-297.zip

Die offiziellen GitHub-Infos passen sehr gut zu unserem Fall:

• 0.1.285+ hatte laut Issue ein Race-Condition-Problem bei Storage-Requests.
• 0.1.271 wurde dort als letzter funktionierender Workaround genannt.
• 0.1.297 enthält den eigentlichen Fix:
  • PR #1467 viostor Fix for clobbered SRB Extension IDs
  • Issue #1466 viostor Regression
  • verwandtes Issue #1453 vioscsi / Windows Server 2025

Da es aktuell stabil läuft und 0.1.297 eine Vorabversion, nicht der normale stabile Release ist, warte ich mit dem Update auf diese neuste Version noch.

Danke für eure Hilfe!

Vielen Dank auch für die weiteren Antworten.

Downgrade auf 0.1.271 habe ich durchgeführt. Außerdem von 16 Sockets a 1 Kern auf 1 Socket mit 16 Kernen umgestellt. Ich beobachte und berichte.

Vielen Dank für deine Antwort. Downgrade probiere ich aus.

Netcup liegen schon alle Infos vor und ich habe schon um eine MIgration auf einen anderen Host/Storage-Node gebeten. Leider antworten die Seit fast 3 Wochen nicht. Außer die kurze Info, dass das Ticket an einen Bearbeiter weitergegeben wurde.

Ist ein RS 8000 G12

Hallo zusammen,

ich wende mich hier ans Forum, weil ich über den regulären netcup-Support bislang leider keine Reaktion erhalte und das Problem produktiv relevant ist.

Auf einem netcup RS/KVM-Server kommt es seit einiger Zeit wiederholt zu unerwarteten Neustarts bzw. Bluescreens unter Windows Server. Anfangs schien es so, als würden die Abstürze vor allem bei hoher RAM-Auslastung auftreten. Inzwischen gab es jedoch auch Abstürze bei deutlich unter 50% RAM-Auslastung, sodass eine reine Speicherüberlastung als Ursache nicht mehr plausibel ist.

System grob:

• netcup KVM / Root Server
• Windows Server, Build 26100
• VirtIO Storage / Red Hat VirtIO SCSI
• VirtIO-Treiber laut System: Red Hat VirtIO SCSI Controller, Version 100.101.104.28500
• Storage-Treiber im Dump u. a. viostor.sys
• Pagefile liegt auf C:\pagefile.sys

Es wurden mehrere Dumps mit den Microsoft Debugging Tools analysiert. Die auffälligsten Crashs:

25.06.2026, ca. 14:43 Uhr

• Bugcheck: IRQL_NOT_LESS_OR_EQUAL (0xA)
• Failure Bucket: AV_nt!MiCommitExistingVad
• Stack u. a.:
  • nt!MiCommitExistingVad
  • nt!MiAllocateVirtualMemory
  • nt!NtAllocateVirtualMemory
• Betroffener Prozess laut Dump: powershell.exe
• RAM war zu diesem Zeitpunkt nicht kritisch ausgelastet.

25.06.2026, ca. 14:51 Uhr

• Bugcheck: MEMORY_MANAGEMENT (0x1A)
• Parameter 1: 0x3f
• Failure Bucket: PAGE_HASH_ERRORS_0x1a_3f
• Debugger-Hinweis:
  • Memory Manager detected corruption of a pagefile page while performing an in-page operation.
  • The data read from storage does not match the original data written.
  • This indicates the data was corrupted by the storage stack, or device hardware.
• Betroffener Prozess laut Dump: SearchIndexer, aus meiner Sicht aber nur der auslösende Prozess, nicht die eigentliche Ursache.

Weitere frühere Dumps zeigten ebenfalls wiederholt Kernel-/Memory-Manager-nahe Fehler, u. a. in MiCommitExistingVad, MiUserFault, MiApplyCompressedFixups und einmal PAGE_TABLE_RESERVED_BITS_SET.

Wichtig: NTFS meldet C: als fehlerfrei, und es gibt keine klassischen, gut sichtbaren Disk-Timeout-Events unmittelbar vor jedem Crash. Der Dump selbst spricht aber sehr deutlich für beschädigte Daten beim Einlesen aus dem Pagefile bzw. entlang des Storage-Pfads. Deshalb geht mein Verdacht aktuell eher in Richtung VirtIO-/Storage-Stack, Host-Storage oder KVM-/Host-seitiges Problem, nicht in Richtung Anwendungsebene.

Meine Fragen an die Community:

1. Hat jemand ähnliche PAGE_HASH_ERRORS_0x1a_3f oder MEMORY_MANAGEMENT 0x1A / 0x3f auf netcup KVM-/Root-Servern gesehen?
2. Gibt es bekannte Probleme mit bestimmten VirtIO-Treiberständen unter Windows Server Build 26100?
3. Würdet ihr hier ebenfalls eine Host-/Storage-Node-Migration durch netcup verlangen?
4. Gibt es aus eurer Sicht noch sinnvolle lokale Gegenchecks, bevor man klar von einem Infrastrukturproblem ausgeht?

Ich möchte ausdrücklich nicht einfach „Windows ist kaputt“ behaupten. Die Debugger-Auswertung wirkt aber für mich ziemlich klar: Windows erkennt, dass eine ausgelagerte Pagefile-Seite beim Zurücklesen nicht mehr dem entspricht, was zuvor geschrieben wurde. Das ist aus meiner Sicht ein starkes Indiz für Storage-/Stack-/Host-seitige Datenkorruption.

Ticket beim Support ist offen, bisher leider ohne Reaktion. Falls ein netcup-Mitarbeiter mitliest: Ich kann Dump-Zeitpunkte, Bugcheck-Parameter und weitere Details gerne nachreichen. Öffentliche Kundennummern/IPs poste ich hier bewusst nicht.

Danke euch für jede Einschätzung.

Viele Grüße, Maik