Die 32 0 KB-Dateien habe ich jetzt gelöscht. Bleiben noch 7:

09329e49-2478-456a-b3a9-99ae6dcf9583.dmp (979 KB) vom 22.06.
processdump_5376.dmp (688 KB) vom 13.06.
SetupHost.exe.3684.dmp (4.732 KB) vom 16.06.
SetupHost.exe.4784.dmp (4.708 KB) vom 16.06.
SetupHost.exe.16420.dmp (4.719 KB) vom 15.06.
SetupHost.exe.18316.dmp (4.723 KB) vom 15.06.
sidebar.exe.6420.dmp (8.799 KB) vom 15.06.

Hab zunächst versucht die Dateien mit Hilfe des Tools "Bluesreenview" zu lesen - wurde nichts angezeigt. Im Internet das Tool "WhoCrashed" gefunden - Ergebnis der Analyse:
[hr][/hr]
"[i][b]On Sun 16.06.2019 21:20:14 your computer crashed or a problem was reported[/b]
crash dump file: C:\WINDOWS\LiveKernelReports\PoW32kWatchdog-20190616-2119.dmp
This was probably caused by the following module: ntkrnlmp.exe (nt!IopLiveDumpEndMirroringCallback+0x7E)
Bugcheck code: 0x1A1 (0xFFFFDF8105021040, 0x0, 0x0, 0x0)
Error: CUSTOM_ERROR

The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.

The following dump files were found but could not be read. [b]These files may be corrupted:[/b]
09329e49-2478-456a-b3a9-99ae6dcf9583.dmp
SetupHost.exe.3684.dmp
SetupHost.exe.4784.dmp
SetupHost.exe.16420.dmp
SetupHost.exe.18316.dmp
sidebar.exe.6420.dmp
processdump_5376.dmp[/i]"
[hr][/hr]
@DK2000
--> Gibt es noch andere Möglichkeiten die dmp-Dateien auszuwerten?
--> Hilft der o.g. Bugcheck code: 0x1A1 (0xFFFFDF8105021040, 0x0, 0x0, 0x0) bei der Eingrenzung des Problems weiter?
Danke vorab!

@DK2000 Vielen Dank für die Hinweise!
Habe Laufwerk C durchsucht zunächst nach *.mdmp --> keine Dateien gefunden
Aber bei der Suche nach *.dmp --> zunächst 57 Dateien gefunden - einige noch aus dem Jahr 2018 (wahrscheinlich weil ich beim Wechsel der Laufwerke das System geclont habe. --> alle, die vor 06/2019 datiert waren, gelöscht! Jetzt sind noch 39 Dateien übrig...

Habe nämlich überwiegend im Juni die Versuche getätigt, die Builds 18912, 18917 und 18922 zu installieren inkl. mehrere Wechsel der System-SSDs/HDDs!

Die meisten Dateien (32 Stück vom 22.06.) haben die Größe 0 KB - deren Pfad ist jedoch sehr seltsam... Sie haben alle den gleichen Namen (2c6dc995-2ec7-465b-a9e5-4979605530c5.dmp), aber die Pfade unterscheiden sich immer durch einen zusätzlichen "Anwendungsdaten"-Ordner... Hier der längste Pfad:
\\?\C:\ProgramData\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten

Bin jetzt berufl. unterwegs, mache nachher weiter - mit Eure Hilfe! ;-)

2019-06-22 14:31:09, FatalError            SP     Exception handler called! Details:[gle=0x000000cb]
2019-06-22 14:31:09, FatalError            SP       Exception record: 0[gle=0x000000cb]
2019-06-22 14:31:09, FatalError            SP         Exception code: 0xc0000005[gle=0x000000cb]
2019-06-22 14:31:09, FatalError            SP         Exception flags: 0x0[gle=0x000000cb]
2019-06-22 14:31:09, FatalError            SP         Exception address: 00007FFBB36558B3[gle=0x000000cb]
2019-06-22 14:31:09, FatalError            SP         Exception parameter 0: 0000000000000000[gle=0x000000cb]
2019-06-22 14:31:09, FatalError            SP         Exception parameter 1: 0000000000000010[gle=0x000000cb]

Das ist ein sehr schwieriges Problem:

[code]2019-06-22 14:31:09, FatalError SP Exception handler called! Details:[gle=0x000000cb]
2019-06-22 14:31:09, FatalError SP Exception record: 0[gle=0x000000cb]
2019-06-22 14:31:09, FatalError SP Exception code: 0xc0000005[gle=0x000000cb]
2019-06-22 14:31:09, FatalError SP Exception flags: 0x0[gle=0x000000cb]
2019-06-22 14:31:09, FatalError SP Exception address: 00007FFBB36558B3[gle=0x000000cb]
2019-06-22 14:31:09, FatalError SP Exception parameter 0: 0000000000000000[gle=0x000000cb]
2019-06-22 14:31:09, FatalError SP Exception parameter 1: 0000000000000010[gle=0x000000cb][/code]
Das ist ein abgefangener BSOD:

0x000000CB: DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS
Grund: 0xC0000005: STATUS_ACCESS_VIOLATION

Problem ist jetzt aber, dass diese Art von Fehler vom Log nicht abgedeckt wird, Finde da auch so keine weiteren Anzeichen, welcher Treiber da quer schlägt. Dazu bräuchte man, sofern angelegt wurden, die *.mdmp oder *.dmp. Weiß jetzt aber nicht genau, wo das Setup diese Dateien versteckt. Geht auch nicht aus dem Log hervor, ob so eine Datei erstellt wurde.

Aber Microsoft entschuldigt sich wenigstens dafür: [b][i]We are sorry for the inconvenience[/i][/b].

Da ist DK2000 der Profi.

Hab gerade nochmal nachgelesen (im Feedback-Hub): Windows 10 Insider Preview Build [b]18922 [/b](20H1)

[b]General changes, improvements, and fixes for PC[/b]

[list]We fixed an issue resulting in some Insiders getting Windows Update error 0x80010105 when updating to recent builds. [/list]
[list]We fixed an issue resulting in some Insiders getting Windows [b]Update error 0xc0000005 when updating to recent builds[/b]. [/list]
...
@moinmoin
@DK2000
Irgend welche Tipps wonach ich in den log-Dateien suchen soll, um das/die Problem(e) eingrenzen zu können?

So, habe jetzt alles wieder auf "normal" gestellt (alle HW wieder angeschlossen - nur die PCIe2-Grafikkarte nicht; in msconfig alle Dienste gestartet; im 'Taskmanager die Autostarts aktiviert, usw.) - nur Win Search habe ich deaktiviert gelassen!
--> nur die SSD ist jetzt eine neue mit 512GB und mit [b]Win10 Build 18898[/b] installiert inkl. Anwender-Daten u. -Programme
--> nach Anpassung des UEFI/BIOS lief der Start sauber durch / im Gerätemanager keine Probleme...

1. Nächster Schritt: Installation des Builds [b]18922 mit ISO[/b]... --> FEHLER! Wie vorher auch schon...
Hier die setupact.log-Datei:
https://anonfile.com/LaBcy5wan0/setupact18922-3_zip

2. Weiter mit: Installation des Builds [b]18908 mit ISO[/b]... --> KEINE PROBLEME!
Nur die [b]Intel-Gerätetreiber[/b] (meist Stand 2019) wurden zurückgesetzt auf Stand 2016
--> [b]Sandbox [/b]kann direkt gestartet werden - da läuft sie jetzt auch ohne aktivierte Kernisolierung...
--> Obwohl in Win Features [u]als deaktiviert angezeigt[/u], ist Hyper-V doch irgendwie aktiviert (hab irgendwo mal gelesen es soll ein "Mini-Hyper-V" sein - was das auch heißen mag). Im Gerätemanager war auch ein "virtuelles Laufwerk" angelegt.

3. versuchte Installation der Builds [b]18912 und 18917 mit ISOs[/b]... --> FEHLER! Wie vorher auch schon...
Hier die setupact.log-Dateien:
https://anonfile.com/q5G1y1w3n6/setupact18912_zip
https://anonfile.com/3cG4yew1n2/setupact18917_zip

--> Auch in 1. und 3. war Win Search deaktiviert (bei den Builds 18912, 18917 und 18922)! Aber in 2. nicht (18908)... Auch wenn ich in 1. und 3. das Win Search aktiviere, bekomme ich den gleichen Fehler!

Habe auch versucht die o.g. Log-Dateien ein wenig zu verstehen - aber bei über 210.000 Zeilen war ich überfordert. Dann hab ich mir die setuperr.log-Dateien angesehen - da werden massenweise Fehler angezeigt, aber verstehen tue ich sie auch nicht... :(

Als Gast einfach in zip packen und hier hochladen. https://anonfile.com/
Link dann hier reinsetzen. :)

Danke für die schnelle Reaktion!!!

Wie kann man hier die log-Datei hochladen? Den gesamten Inhalt hier zu kopieren wäre ein wenig zu viel, oder? 👁

Es hat außerdem nichts mehr mit "Sandbox" zu tun... ;-)

0xC0000005 = STATUS_ACCESS_VIOLATION

Irgendetwas versucht da auf Speicherberreiche zuzugreifen, die entweder ungültig sind oder die Anwendung, die das verursacht, hat da nichts zu suchen.

Bräuche man eventuell mal eine entsprechende C:\$Windows.~BT\Sources\panther\setupact.log, um mal zz sehen, bis wohin das Setup überhaupt kommt und was da eventuell diesen Fehler auslöst.

[quote=DK2000 post_id=330149 time=1561056482 user_id=39966]
Und was den Abbruch bei 70% (Windows Update) bzw. 55% (ISO) angeht, deaktiviere den Dienst [i]"Windows Search"[/i]. Dann läuft das Upgrade durch. [/quote]
Und ich hatte schon gehofft endlich den richtigen Hinweis bekommen zu haben (danke für den Tipp), warum alle meine Update-Versuche für die Insider Previews 18912, 18917 und 18922 abbrechen... :betruebt:

Habe sogar eine alte SSD, die ich vor ca. 4 Monate ersetzt habe durch eine Größere mit etwas älterem Win10 nochmal raus gegraben... Alle Update-Versuche der o.g. 3 Previews (egal ob mit Win Update, ISO-bereitstellen und mit USB-Install.Stick) haben nicht funktioniert. Auch deaktivieren aller Dienste (außer Windows) in msconfig + deaktivieren aller Autostart-Programme änderte nichts!

Wenn ich Win10 Update verwende, kommt nach 40 Min. diese Meldung: "Windows 10 Insider Preview 18922.1000 (rs_prerelease) – Fehler 0xc0000005" (= Treiberproblem?)

Genauso wenig hat geholfen einige Geräte abzuklemmen (Lautsprecher, 2. Bildschirm, Bluetooth-Adapter, 2. Grafikkarte im PCIe2, neue programmierbare Gamingtastatur durch alte ersetzt)!

Wie vorher schon bei der neuen SSD und der alten HDD hat auch hier nur das Update 18908 funktioniert - trotz aktiviertem Win Search... Auch das Preview 18898 hatte funktioniert.

==> Irgend etwas ist ab Preview 18912 (vom 05.06.2019) jedenfalls anders als vorher mit den Updates! :o

Gibt es vielleicht noch ein Dienst, den man abschalten könnte/sollte? Bin für jeden Tipp dankbar... :thx:

Ja, das ist richtig. In der 20H1 ist der Bug mit der fehlenden Datei in der deutschen Version der Sandbox schon lange behoben worden. Nur bei der 1903 (19H1) bekommt Microsoft das nicht gebacken. Soll ja aber bald ein Update kommen.

Und was den Abbruch bei 70% (Windows Update) bzw. 55% (ISO) angeht, deaktiviere den Dienst [i]"Windows Search"[/i]. Dann läuft das Upgrade durch.

Hab jetzt auf eine alte HDD installiert, weil ich irgendwo gelesen habe, dass einer Probleme hatte beim installieren der neuesten Previews 18908 und 18912 auf SSDs.

Nun habe ich gerade das aktuellste Preview 18917 auf die frisch formatierte HDD installiert - Sandbox musste danach extra aktiviert werden. Aber da läuft sie jetzt auch [b]ohne aktivierte Kernisolierung[/b]...

Es tut sich also was...

Allerdings lassen sich die o.g. Previews bei mir weder auf SSDs noch auf HDDs mit bereits vorhandenem Win10 installieren bzw. upgraden . nur bis Version 18908 funktionieren die Upgrades (auf SSDs und HDDs). Alles was danach gekommen ist bleibt hängen bei 70% und Abbruch nach ca. 30 Min. (wenn über die normale Windows Update angestossen). Wenn man stattdessen die ISO-Dateien anwendet (im Explorer bereitstellen), dann geht es nur bis 55% und wieder nach ca. 30 Min. Abbruch...

Gerade mal getestet mit der 18362.175:

Die Sandbox kommt immer noch mit 0x80070002 oder 0x8007041d. Letztere hängt wohl damit zusammen, dass das System mit aktivierter Kenerisolierung einfach zu langsam geworden ist. Wenn der 0x8007041d kommt und ich die Sandbox sofort wieder starte, kommt dann der 0x80070002.

Und diese Kenerisolierung aktiviere ich da ungerne. Dazu ist meine Hardware einfach zu alt. Man merkt deutlich, wie träge auf einmal alles wird. In der VM kann ich das ganz vergessen. Die VM wird damit unbrauchbar, weil langsam wie Schnecke.

Und nebenbei:Die Kernelisolierung aktiviert auch Hyper-V, aber halt die Lite Variante, genauso wie die Sandbox, Application Guard usw. und zukünftig dann auch WSL2.

Aber nicht aktuell in der 18362.175 oder?

Hallo,

bei mir habe ich heraus gefunden, dass unter "Einstellungen > Update & Sicherheit > Windows-Sicherheit > Gerätesicherheit" die [b]Kernisolierung [/b]eingeschaltet sein muss, damit die Sandbox funktioniert!

Hyper-V muss dabei nicht aktiv sein... zumindest bei mir ist es so!

Mein PC habe ich selbst zusammen gebaut, deshalb hier keine Angaben über irgendein Hersteller...