Wiederholte Windows-Server-Abstürze auf RS/KVM: MEMORY_MANAGEMENT 0x1A / PAGE_HASH_ERRORS_0x1a_3f / Verdacht auf Storage-/VirtIO-/Host-Problem

    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

    Quote from miksbl

    Meine Fragen an die Community: ...

    Damit dir eventuell auch einer aus dem Forum helfen kann:
    Auf welchen Server Type bzw. Produktbezeichnung (z.B. RS 4000, G 12) tritt dieses Problem auf? Denn einfach RS/KVM reicht leider nicht aus, da der Provider Netcup mehrere verschiedene Produktvarianten auf diesen Hypervisor betreibt.

    Da es wahrscheinlich ein VirtIO-Storage-Treiberproblem mit der Version 0.1.285 / 100.101.104.28500 geben wird, würde ich an deiner Stelle mal folgendes ausprobieren:

    • Backup/Snapshot erstellen
    • VirtIO Storage-Treiber auf 0.1.271 downgraden

    Wenn nach der Systembeobachtung weiterhin solche oder auch ähnliche Fehler wie PAGE_HASH_ERRORS_0x1a_3f auftreten, würde ich an deiner Stelle netcup mit Dumps, Treiberversionen und Zeitstempeln kontaktieren und Host-/Storage-Node-Migration verlangen.

    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. :(

    Das kommt mir irgendwie bekannt vor. Es gab hier ja schon mehrere Meldungen, dass Windows Server mit der neuen G12 Hardware (AMD Genoa) Probleme machen. So aus dem Bauch heraus würde ich da auf den Virtio Treiber für Windows tippen.

    Schau doch mal hier hier, ob dir da etwas bekannt vor kommt: https://github.com/virtio-win/kvm…-windows/issues

    Vor allem das hier scheint auch in die Richtung zu gehen: https://github.com/virtio-win/kvm…ows/issues/1582

    Und in diesem Issue kommt ebenfalls eine Genoa CPU im Einsatz. Das klingt schon mehr als nur nach einem Zufall.

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

    Quote

    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:

    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!