[adrianghc]

Ich habe vor kurzem auf Build 19041 aktualisiert. Alles läuft super, abgesehen davon, dass mein Rechner jedes Mal abstürzt, dass er vom Herunterfahren oder Ruhezustand hochfährt (also immer wenn eine hiberfil.sys geladen wird). Neustart ist nicht davon betroffen.

Der Absturz kann vor oder nach dem Anmelden passieren und äußert sich in einem schwarzen Bildschirm, bis der Memory-Dump geschrieben wurde.

Der Bug Check scheint ein äußerst ungewöhnlicher zu sein:

DRIVER_VERIFIER_DMA_VIOLATION (e6)
An illegal DMA operation was attempted by a driver being verified.
Arguments:
Arg1: 0000000000000026, IOMMU detected DMA violation.
Arg2: 0000000000000010, Device Object of faulting device.
Arg3: 000000008d880000, Faulting information (usually faulting physical address).
Arg4: 0000000000000006, Fault type (hardware specific).

Argumente 1, 2 und 4 sind immer gleich, 3 variiert.

Die Absturzadresse ist immer ntoskrnl.exe+39d840.

Jetzt könnte man natürlich argumentieren, dass das sowieso eine Insider-Build ist und da solche Bugs zu erwarten sind. Allerdings ist ein solcher 100% reproduzierbarer Absturz bei etwas derart normalem wie Ruhezustand oder Herunterfahren so spät in der Entwicklung schon verwunderlich - hätte der nicht schon längst bemerkt werden müssen? Wenn wir diese Frage ohne Zynismus mit ja beantworten (ist vielleicht etwas viel verlangt ), dann liegt die Vermutung nahe, dass dieser Absturz von einem konkreten Treiber verursacht wird, der mit der neuen Version inkompatibel ist und nicht zum normalen Lieferumfang von Windows gehört und deshalb bisher vom Windows-Team nicht wahrgenommen wurde.

Falls das so ist, möchte ich gerne herausfinden, welcher Treiber das ist. Leider kenne ich mich mit WinDbg nicht genug aus, um zu wissen, wie ich jetzt weitermachen könnte, um mehr herauszufinden. Hat da jemand eine Idee? Ich kann auch Dump-Dateien schicken.

Folgendes kann ich noch teilen:

STACK_TEXT:  
fffff806`79adae98 fffff806`7dc5cee5 : 00000000`000000e6 00000000`00000026 00000000`00000010 00000000`8d880000 : nt!KeBugCheckEx
fffff806`79adaea0 fffff806`7dc8e18c : 00000000`00000f32 00000000`00000000 00000000`00000000 fffff806`7da82e5f : nt!HalpIommuReportIommuFault+0x45
fffff806`79adaee0 fffff806`7dc8696c : fffff806`7e450460 fffff806`7da20a2c 00000000`00000002 00000000`00000028 : nt!HvlpHandleIommuFaultMessage+0x88
fffff806`79adaf50 fffff806`7dba32e2 : 00000000`00000002 fffff88f`75427620 00000000`00000000 fffff806`7db9f2ea : nt!HvlSharedIsr+0x5c
fffff806`79adaf90 fffff806`7dba2ce7 : 00000000`00000006 00000000`00000000 fffffc7e`3f1f8ff8 00000000`00000003 : nt!KiHvInterruptSubDispatch+0x112
fffff88f`754275a0 fffff806`7e110d84 : fffffc80`00000000 fffff806`7da62369 fffffc7e`40000000 fffffc7e`3ffffff8 : nt!KiHvInterruptDispatch+0x37
fffff88f`75427730 fffff806`7e110a52 : 00000000`00000000 fffff806`7e450460 fffff88f`754278b0 fffff806`7e450460 : nt!PopHandleNextState+0x288
fffff88f`75427780 fffff806`7e11093e : 00000000`00000000 fffff806`7e450460 00000001`67eb8bc0 00000001`67eb8bc0 : nt!PopIssueNextState+0x1a
fffff88f`754277b0 fffff806`7e113609 : 00000000`00000001 00000000`00000000 00000000`00000000 fffff806`7da630a8 : nt!PopInvokeSystemStateHandler+0x4aa
fffff88f`754279b0 fffff806`7e11662d : ffffffff`00000000 ffffffff`ffffffff fffff88f`75427b30 00000000`00000000 : nt!PopEndMirroring+0x1e9
fffff88f`75427a70 fffff806`7e116375 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : nt!MmDuplicateMemory+0x261
fffff88f`75427b00 fffff806`7da0b1b5 : ffffe686`71c62000 ffffe686`71c62040 fffff806`7e116240 00000000`00000000 : nt!PopTransitionToSleep+0x135
fffff88f`75427b90 fffff806`7dba4e98 : ffffa881`3e680180 ffffe686`71c62040 fffff806`7da0b160 00000000`00000246 : nt!PspSystemThreadStartup+0x55
fffff88f`75427be0 00000000`00000000 : fffff88f`75428000 fffff88f`75421000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28

Das scheint ja alles Code direkt vom Kernel zu sein und nicht von einem Treiber, oder?

Dieser Beitrag wurde von adrianghc bearbeitet: 07. Januar 2020 - 01:04

[Stefan_der_held]

Wenn es bei Dingen wie StandBy/Ruhezustand/Herunterfahren ist würde ich erstmal hierarchisch hier ansetzen:

- Aktuallität des EFI/BIOS
- Aktuallität der Chipsatztreiber
- Aktuallität der Windows-Installation selbst
- Testweise ein "InPlace Upgrade" mit der 1909-ISO um defekte Systemkomponenten ausschließen zu können

[DK2000]

Du könntest die Dump Datei packen und hier anhängen.

Ansonsten gebe mal in der Konsole verifier /querysettings ein. Eventuell steht hier dann schon am Ende, welcher Treiber überprüft wurde.

Oder in Windbg nach !analyze -v mal !devobj 10 eingeben oder nur !devnode. Setzt aber meist voraus, dass die Dumpdatei vom Typ Kernel ist. Eine Minidump nützt in solchen Fällen meist nicht viel.

[adrianghc]

Zitat (Stefan_der_held: 07. Januar 2020 - 08:52)

Wenn es bei Dingen wie StandBy/Ruhezustand/Herunterfahren ist würde ich erstmal hierarchisch hier ansetzen:

- Aktuallität des EFI/BIOS
- Aktuallität der Chipsatztreiber
- Aktuallität der Windows-Installation selbst
- Testweise ein "InPlace Upgrade" mit der 1909-ISO um defekte Systemkomponenten ausschließen zu können

- Alles ist so aktuell wie es geht.
- Inplace-Upgrade mit der 1909-ISO wird nicht gehen, da ich gerade auf 2004 aktualisiert habe. Allerdings habe ich das wie gesagt auch gerade gemacht, also sollte da eher nichts defekt sein. sfc /scannow und dism blabla hab ich auch schon ausgeführt, es gab keine Feher.

Zitat (DK2000: 07. Januar 2020 - 09:22)

Du könntest die Dump Datei packen und hier anhängen.

Ansonsten gebe mal in der Konsole verifier /querysettings ein. Eventuell steht hier dann schon am Ende, welcher Treiber überprüft wurde.

Oder in Windbg nach !analyze -v mal !devobj 10 eingeben oder nur !devnode. Setzt aber meist voraus, dass die Dumpdatei vom Typ Kernel ist. Eine Minidump nützt in solchen Fällen meist nicht viel.

Ich hab vergessen zu erwähnen, dass der Driver Verifier aus ist. Das hier ist die Ausgabe von verifier /querysettings

Überprüfungskennzeichen: 0x00000000

  Standardkennzeichen:

    [ ] 0x00000001 Spezieller Pool.
    [ ] 0x00000002 IRQL-Überprüfung erzwingen.
    [ ] 0x00000008 Poolnachverfolgung.
    [ ] 0x00000010 E/A-Überprüfung.
    [ ] 0x00000020 Deadlockerkennung.
    [ ] 0x00000080 DMA-Überprüfung.
    [ ] 0x00000100 Sicherheitsüberprüfungen.
    [ ] 0x00000800 Sonstige Prüfungen.
    [ ] 0x00020000 DDI-Kompatibilitätsüberprüfung.

  Zusätzliche Kennzeichen:

    [ ] 0x00000004 Simulation geringer Ressourcen nach dem Zufallsprinzip.
    [ ] 0x00000200 Ausstehende E/A-Anforderungen erzwingen.
    [ ] 0x00000400 IRP-Protokollierung.
    [ ] 0x00002000 Invariante MDL-Überprüfung für Stapel.
    [ ] 0x00004000 Invariante MDL-Überprüfung für Treiber.
    [ ] 0x00008000 Testen der Verzögerung des Energieverwaltungsframeworks mit zufälligen Daten.
    [ ] 0x00010000 Überprüfung der Port-/Miniportschnittstelle.
    [ ] 0x00040000 Systematische Simulation geringer Ressourcen.
    [ ] 0x00080000 DDI-Kompatibilitätsüberprüfung (zusätzlich).
    [ ] 0x00200000 NDIS/WLAN-Überprüfung.
    [ ] 0x00800000 Testen der Verzögerung der Kernelsynchronisierung mit zufälligen Daten.
    [ ] 0x01000000 VM-Switchüberprüfung.
    [ ] 0x02000000 Codeintegritätsprüfungen.

    [X] gibt an, dass das Kennzeichen aktiviert ist.

  Startmodus:

    Persistent

  Regeln:

    Für alle Regeln werden Standardeinstellungen verwendet.

  Überprüfte Treiber:

    Keine

Da ich noch ein vollständiges Dump habe, konnte ich die beiden anderen Befehle noch ausführen:

!devobj 10:

00000010: Could not read device object or _DEVICE_OBJECT not found

!devnode

Dumping IopRootDeviceNode (= 0xffffe68661941cc0)
DevNode 0xffffe68661941cc0 for PDO 0xffffe686618eddf0
  Parent 0000000000   Sibling 0000000000   Child 0xffffe68661893cb0   
  InstancePath is "HTREE\ROOT\0"
  State = DeviceNodeStarted (0x308)
  Previous State = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[08] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[07] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[06] = DeviceNodeStarted (0x308)
  StateHistory[05] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[04] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[03] = DeviceNodeStarted (0x308)
  StateHistory[02] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[01] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[00] = DeviceNodeStarted (0x308)
  StateHistory[19] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[18] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[17] = DeviceNodeStarted (0x308)
  StateHistory[16] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[15] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[14] = DeviceNodeStarted (0x308)
  StateHistory[13] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[12] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[11] = DeviceNodeStarted (0x308)
  StateHistory[10] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[09] = DeviceNodeEnumeratePending (0x30c)
  Flags (0x00000131)  DNF_MADEUP, DNF_ENUMERATED, 
                      DNF_IDS_QUERIED, DNF_NO_RESOURCE_REQUIRED
  UserFlags (0x0000000a)  DNUF_DONT_SHOW_IN_UI, DNUF_NOT_DISABLEABLE
  CapabilityFlags (0x000001c0)  UniqueID, SilentInstall, 
                                RawDeviceOK
  DisableableDepends = 8 (including self)

Dieser Beitrag wurde von adrianghc bearbeitet: 07. Januar 2020 - 10:58

[DK2000]

Arg2: 0000000000000010, Device Object of faulting device.

,

!devobj 10: Could not read device object or _DEVICE_OBJECT not found

Das ist natürlich doof, aber 0x10 sieht eh ein wenig komisch aus. Die Adresse ist so niedrig.

Könntest mit !verifier noch ein wenig experimentieren:

https://docs.microso...ugger/-verifier

Da der Driver Verifier anscheinend nicht manuell aktiviert wurde, ist das jetzt schwer zu sagen, warum der anschlägt.

AMD System? Irgendetwas aktiviert, was Hyper-V benötigt?

So viel Erfahrung mit dem Driver Verifier und dessen BSODs habe ich da auch nicht. Da müsste ich selber erst einmal nachlesen, wie man da aus der Dump die Informationen erhält.

[adrianghc]

Zitat (DK2000: 07. Januar 2020 - 12:28)

Arg2: 0000000000000010, Device Object of faulting device.

,

!devobj 10: Could not read device object or _DEVICE_OBJECT not found

Das ist natürlich doof, aber 0x10 sieht eh ein wenig komisch aus. Die Adresse ist so niedrig.

Könntest mit !verifier noch ein wenig experimentieren:

https://docs.microso...ugger/-verifier

Da der Driver Verifier anscheinend nicht manuell aktiviert wurde, ist das jetzt schwer zu sagen, warum der anschlägt.

AMD System? Irgendetwas aktiviert, was Hyper-V benötigt?

So viel Erfahrung mit dem Driver Verifier und dessen BSODs habe ich da auch nicht. Da müsste ich selber erst einmal nachlesen, wie man da aus der Dump die Informationen erhält.

Das System ist Intel (ein Surface Pro 2017). Ich hab tatsächlich mehrere Dinge an, die Hyper-V benötigen: WDAG, Sandbox und WSL2. Außerdem "Speicher-Integrität", aber da hab ich bereits getestet und festgestellt, dass das keinen Unterschied macht.

Ich könnte auch einfach einen Rollback zu 18363 machen und mir den Stress sparen. Ich wollte das aber lieber vermeiden, weil

1. Ich früher oder später sowieso auf 19041 gehe und ich das Problem dann wieder haben könnte.
2. Ich nicht sicher sagen kann, ob das Problem wirklich die Build ist, da ich vor dem Upgrade unter 18363 mehrere Wochen lang weder Ruhezustand noch Herunterfahren benutzt habe und somit nicht sicher sein kann, dass das Problem unter 18363 nicht existierte.
3. Das Upgrade hab ich vor einer Woche gemacht. Wenn ich einen Rollback jetzt mache, wie viel der letzten Woche verliere ich? Wird z.B. appdata einfach vollständig zurückgerollt oder wie funktioniert das? Vergangene Rollbacks (die ich aber höchstens einen Tag nach dem Upgrade gemacht habe) gingen extrem schnell, sodass ich annahm, dass beim Rollback einfach nur die Ordner in Windows.old wieder raus geschoben werden.

[adrianghc]

Nach einigem Experimentieren bin ich mir ziemlich sicher, den Schuldigen ausgemacht zu haben, zumindest das Windows-Feature, das den Absturz verursacht: Es handelt sich um den Microsoft Defender Application Guard, und zwar dann, wenn dessen Feature "Erweiterte Grafik" (kann man unter Windows-Sicherheit -> App- & Browsersteuerung einstellen) angeschaltet ist. Weder Sandbox noch WSL2 machen ein Problem, es ist nur WDAG mit dieser Einstellung. Daher liegt auch die Vermutung nahe, dass der schuldige Treiber die Intel-Grafik ist.

Ich werde alle meine Erkenntnisse so detailliert wie möglich im Feedback-Hub mitteilen. Danach kann ja jeder Wetten abschließen, wie lange es dauert, bis der Fehler behoben wird (oder auch nicht). Ausgehend von meinen bisherigen Erfahrungen mit dem Feedback-Hub mache ich mir keine großen Hoffnungen, aber ab da sehe ich sozusagen meine Arbeit als getan und das Problem für mich persönlich auch als zufriedenstellend gelöst an. Ich übergebe nun an Microsoft und Intel.

Danke an euch beide für eure Mühe!

Dieser Beitrag wurde von adrianghc bearbeitet: 07. Januar 2020 - 20:13

[DK2000]

"Microsoft Defender Application Guard" verwendet ja auch Hyper-V. Die App läuft dann im Container. Und das Feature "Erweiterte Grafik" ist wohl so eine Art durchschleifen der verbauten GPU. Das benötigt auf jeden Fall IOMMU seitens Hardware und UEFI und Treiber der GPU. Kann also wirklich für den Fehler verantwortlich sein.