Anzeige

Am Puls von Microsoft

Anzeige

System Bluescreens von ntoskrnl.exe nach Upgrade auf Win 8.1

Du kannst es versuchen, Kaspersky neu zu installieren. Ich denke aber, dass dann die Probleme wieder kommen.
Auf alle Fälle weißt du jetzt, wenn die Probleme wieder kommen, woran es liegt.
Dann gibt es zwei Möglichkeiten:
-> entweder sich mit den Problemen abfinden => ist aber keine gute Lösung
-> oder auf Drittanbieter-AV-Software zu verzichten => 20 € eingebüßt

Eine weitere Möglichkeit wäre, dass du dich bei Kaspersky meldest. Schließlich hast du für das Programm bezahlt.
 
Anzeige
@Ari45
Ich werde mich auf jeden Fall mal an den Support direkt wenden. Erste Google Suchen haben mich zumindest schonmal in die Richtung der "Secure Connection" - Funktion von Kaspersky gebracht.

Bis ich dazu Ergebnisse vorliegen habe, würde ich den Thread noch offen lassen, aber mich an der Stelle schonmal für euer Aller Hilfe bedanken! Bis Kaspersky läuft kann ich wenigstens den Laptop wieder benutzen, ohne mir Sorgen machen zu müssen.
 
Dann lass Kaspersky doch einfach weg! Wäre für die Stabilität, Performance und Sicherheit nur positiv, stattdessen auf die Windows Bordmittel zurückzugreifen.

An sich könntest du jetzt dann auch Windows 10 neu installieren, dann wärst du auf dem aktuellen Stand. An Windows 10 hat es ja wohl auch ursprünglich nicht gelegen, wenn nach der 8.1 Neuinstallation ebenfalls die Probleme auftraten.

Für ein Gerät mit Core i der 4. Generation gibt es alle Treiber auch für Windows 10. Fast alles dürfte automatisch via Windows Update kommen. Den Rest kannst du über die Intel Webseite laden.
 
@IngoBingo
Nein danke, alleine auf den Defender werde ich nicht vertrauen. Kaspersky muss drauf, und wenn ich nochmal zwei Wochen rein stecken muss. Nicht nur meines Geizes wegen, sondern weil ich bis jetzt keinen Test gefunden habe, der den Defender Leistungstechnisch auf das Niveau von Kaspersky betitelt, sondern immer nur als "ausreichende Alternative".

Windows 10 hat noch ganz andere BSOD's verursacht. Der Hersteller (Clevo) hat keine Treiber mehr für das Mainboard unter Win10 rausgebracht. Seit 8.1 waren es immerhin nur noch ntoskrnl.exe-bezogene Bluescreens.
 
Hmm...die Tests zu finden ist doch nicht schwer. Und auch wenn sie weiterhin irgendwie nur Labortests sind, ist selbst da der Defender mittlerweile "Top Produkt" und im gleichen Bereich oder sogar besser als andere.
https://www.av-test.org/de/antivirus/privat-windows/

Dass zusätzliche Software zuerst mal die Angriffsfläche vergrößert und damit das Sicherheitsniveau senkt, solltest du auch betrachten. Der Kaspersky müsste also um Längen besser sein, um die vergrößerte Angriffsfläche wieder zu kompensieren. Und selbst dann fehlen noch die Vorteile.

Und was Vertrauen angeht: du sollst gar keinem Virenscanner vertrauen! Virenscanner sind grundsätzlich nichts, was tatsächlich irgendeine Form von Sicherheit schafft. Sie können im Ernstfall möglicherweise ein Problem verhindern oder verringern. Aber Sicherheit erreichst du durch andere Dinge wie eine sichere Konfiguration, aktuelle Software und weiteres. Wenn du eine "Sicherheitssoftware" installierst, dieser dann vertraust und dich dadurch sicher fühlst, ist das genau der falsche Weg. Aber dann hat die Werbung der Hersteller gut gewirkt...
 
Nur zu deiner Info, ich habe schon unter Win7 Pro dem internen Schutz von Microsoft vertraut. Nachdem ich nur Ärger mit Norton hatte, Abo für 5 Rechner €150,-/Jahr, bin ich auf Microsoft Securety Essentials umgestiegen und zwar mitten im Abo. Ich wollte endlich mal wieder in Ruhe die Rechner nutzen.
 
Hallo nochmal an alle,
ich hatte gerade ca. 3 Minuten nach dem Hochfahren wiedermal einen Bluescreen. Wieder ntoskrnl.exe.

Kurz vorher ist mir ein Firefox Tab abgestürzt (youtube, falls die Info was hilft)

Kaspersky ist jetzt seit 4 Tagen deinstalliert und seitdem kamen auch keine Bluescreens mehr, bis gerade.
Minidump ist im Anhang.

Anhang anzeigen DMP 21.01.2020.zip
 
In der neuen Dumpfile gibt es wieder Speicher Fehler.
Es wurde versucht, auf eine pageable oder vollständig ungültige Adresse zuzugreifen.
IRQL (Interrupt Request Level) ist zu hoch. Das wird normalerweise verursacht durch Treiber, die falsche Adressen verwenden.
STACK_TEXT:
ffffd000`36218538 fffff801`99558769 : 00000000`0000000a ffffe001`d07d9530 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
ffffd000`36218540 fffff801`99555ca8 : fffff6bf`fc33c628 fffff580`10804000 00000000`0000c000 fffff801`9947845e : nt!KiBugCheckDispatch+0x69
ffffd000`36218680 fffff801`994fcdff : ffffe001`ef53e558 fffffa80`088b8970 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x428
ffffd000`36218810 fffff801`995dbfd6 : 00007ff8`6724b8e0 00007ff8`6724b8e0 ffffd000`36218a88 00000000`00000030 : nt!MiImagePageOk+0x63
ffffd000`36218840 fffff801`995d7b47 : 00000000`00000000 00007ff8`6724b8e0 fffff6bf`fc339258 ffffe001`ef53e558 : nt!MiResolveProtoPteFault+0x166
ffffd000`362188e0 fffff801`99453291 : 00000000`00000100 00000000`00000100 ffffd000`00000100 ffffd000`36218a40 : nt!MiDispatchFault+0x8c3
ffffd000`36218a00 fffff801`99555b9d : 00007ff8`6a64eae0 00000000`00000400 00000000`00000001 ffffe001`ef5477e0 : nt!MmAccessFault+0x4f1
ffffd000`36218b00 00007ff8`6724b8e0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x31d
000000af`95af48d8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`6724b8e0


SYMBOL_NAME: nt!MiImagePageOk+63

MODULE_NAME: nt

IMAGE_VERSION: 6.3.9600.19538

STACK_COMMAND: .thread ; .cxr ; kb

IMAGE_NAME: memory_corruption

BUCKET_ID_FUNC_OFFSET: 63

FAILURE_BUCKET_ID: AV_nt!MiImagePageOk

OS_VERSION: 8.1.9600.19538

BUILDLAB_STR: winblue_ltsb_escrow
Ich habe Dir schon geschrieben das es an Deiner Testversion von Windows liegen wird.
Also noch mal, hole Dir ein aktuelles Windows mit einem gültigen Lizenzschlüssel.
Dann eine komplette Neuinstallation. Danach wird der Fehler weg sein.
 
Mit The Ultimate Pid checker kannst du deinen Windows Key prüfen, und nach unkenntlich machen deines Key`s , unbedingt die zwei Stellen im Bild beachten, kannst du einen Screenshot davon hier zum auswerten einstellen. Danke
Win 81 Retail Key.png
 
BUILDLAB_STR: winblue_ltsb_escrow[/SPOILER]
Ich habe Dir schon geschrieben das es an Deiner Testversion von Windows liegen wird.

Das ist allerdings völliger Unsinn.

Hier läuft ein ganz normal installiertes Windows 8.1 Pro und das trägt exakt den selben Buildstring - und das ist definitiv keine Testversion und da war auch nie eine Beta nur in der Nähe des Gerätes.

Wenn das Gerät bluescreent, das mittlerweile unter zwei verschiedenen Windows Versionen und das auch noch immer mal wieder, dann hat vermutlich die Hardware einen Knacks. Möglicherweise ist es irgendein Treiber. Alles mögliche kommt in Frage.

Aber der Unsinn von der "Testversion", der ist mit absoluter Sicherheit NICHT der Auslöser.
 
Was sind Escrow-Builds?
(Update vom 10. Januar 2010)

Manchmal hat Microsoft Builds veröffentlicht, die als "Escrow" bezeichnet werden. Escrow bedeutet, dass die Entwicklung eines Zweigs gestoppt wird und der Code getestet wird. Wenn Microsoft oder seine Tester keine schwerwiegenden Fehler ("Showstopper") entdecken, wird der aktuelle Build zum letzten Meilenstein (normalerweise RC oder RTM, aber manchmal gibt es auch Beta-Escrow-Builds). Escrow-Builds werden normalerweise an TAP-Tester (Technology Adoption Program), ISVs, IHVs usw. ausgegeben.

Gelesen auf dieser Seite https://translate.google.de/transla...-mean-and-what-are-escrow-builds/&prev=search
 
Ja, so kenne ich das auch. Ist aber in der Realität zehn Jahre später tatsächlich anders. Ich kann von einem aktuellen VLSC Image ein Windows 8.1 installieren und es hat exakt den selben Build-String. Es handelt sich dort also nicht um eine Testversion.

Mal abgesehen davon, dass man das auch an der Buildnummer sehen kann. Windows 8.1 Preview Builds wären ja schon uralt und ließen sich auch nicht auf einen aktuellen Stand updaten.

Das ist eine ganz normale Windows 8.1 Installation, keine Testversion.
 
Hallo zusammen! :)
Debuggen ist ja bekanntlich eine Frage der Interpredation. Und ich interprediere dieses Mal das Debugger-Log etwas anders, als @Silver Server.
Meiner Meinung nach ist diese Zeile irreführend
FAILURE_BUCKET_ID: AV_nt!MiImagePageOk
Wie ich beweisen werde, ist der Fehler viel früher eingetreten.
Hier der letzte Thread und der zugehörige Stack
Code:
!thread
THREAD ffffe001ea92a880  Cid 0a68.1f6c  Teb: 00007ff75cffe000 Win32Thread: fffff90144f31b50 RUNNING on processor 4
Not impersonating
GetUlongFromAddress: unable to read from fffff801996a3b70
Owning Process            ffffe001ef53e080      [COLOR="#FF0000"] Image:         firefox.exe[/COLOR]
[COLOR="#008000"]// der FireFox legt für eines seiner Module einen Thread an[/COLOR]
Attached Process          N/A            Image:         N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount      6587727      
Context Switch Count      1297           IdealProcessor: 3             
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address 0x00007ff75d7d63a0
Stack Init ffffd00036218c90 Current ffffd000362188f0
Base ffffd00036219000 Limit ffffd00036213000 Call 0000000000000000
Priority 9 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5 
[COLOR="#008000"]// zu dem Thread gehört der folgende Stack[/COLOR]
# Child-SP          RetAddr           Call Site
00 ffffd000`36218538 fffff801`99558769 nt!KeBugCheckEx
01 ffffd000`36218540 fffff801`99555ca8 nt!KiBugCheckDispatch+0x69
02 ffffd000`36218680 fffff801`994fcdff nt!KiPageFault+0x428
03 ffffd000`36218810 fffff801`995dbfd6 nt!MiImagePageOk+0x63
04 ffffd000`36218840 fffff801`995d7b47 nt!MiResolveProtoPteFault+0x166
05 ffffd000`362188e0 fffff801`99453291 nt!MiDispatchFault+0x8c3
06 ffffd000`36218a00 fffff801`99555b9d nt!MmAccessFault+0x4f1
07 ffffd000`36218b00 00007ff8`6724b8e0 [COLOR="#FF0000"]nt!KiPageFault+0x31d[/COLOR]
08 000000af`95af48d8 00000000`00000000 0x00007ff8`6724b8e0
Und hier meine Interpredation:
Bei Stack #08 wird der Stack für den Thread angelegt
Bereits bei Stack #07 kommt es zum Speicherseitenfehler
In den Stack #05 bis #03 wurde versucht, den Seitenfehler abzufangen, um eventuell wenigstens Windows weiter zu benutzen.
Bei Stack #02 kommt es trotzdem zum Seitenfehler und anschließend zum BugCheckEx.

Ich denke, es ist einzusehen, dass der Debugger Stack#03 als Fehlerursache ansah, weil danach der Seitenfehler kam.
Allerdings hat der Debugger nicht berücksichtigt, dass der Seitenfehler bereits viel früher auftrat und bis zu #03 nur versucht wurde, den Fehler abzufangen.

Also ist nach meiner Meinung der FireFox oder eines seiner Module die wirkliche Ursache.
Bitte im FireFox die HardwareBeschleunigung deaktivieren und testen.
Wenn der Stopfehler trotzdem wieder kommt, mal einen anderen Browser, zB den IE benutzen.

Nachtrag:
Bitte streitet euch nicht um dieses "escrow". Wir hatten hier schon manchmal beim Debuggen Builds mit diesem Zusatz, nur dass wir es meist übersehen haben.
Und die Systeme laufen heute meist noch, sofern nicht zwischenzeitlich auf Windows 10 updated wurde.
 
Zuletzt bearbeitet:
@Ari45
Ich wünschte, ich hätte so einen Einblick in die Technik wie Du. Echt beneidenswert!

Ich werde die Hardwarebeschleunigung direkt abschalten.
 
Ich möchte aber zu bedenken geben das nicht bei allen hier hoch geladenen Dumpfiles der Firefox der letzte Besitzer war.
Da muss was übergeordnetes die eigentliche Ursache sein.
 
Moin Moin,
ich glaub da hatte ich mich vor ein paar Tagen zu früh gefreut. Neuer Absturz, wieder 3-5Minuten nach dem Hochfahren.

Wieder Firefox mit youtube offen, diesmal allerdings auch noch War Thunder geöffnet. War Thunder ist nicht weiter als bis zum Splashscreen gekommen.

Komischerweise war es diesmal der hal.dll, macht das Sinn?

Anhang anzeigen DMP 22.01.2020.zip
 
PROCESS_NAME: firefox.exe

STACK_TEXT:
ffffd000`24d54538 fffff801`8305cf04 : 00000000`0000001a 00000000`00000403 fffff680`09ac60a0 8cc00002`3414e867 : nt!KeBugCheckEx
ffffd000`24d54540 fffff801`82f66fda : fffff680`09ac6ff8 fffff680`09ac6ff8 fffff680`09ac6000 00000000`00000000 : nt!MiDeletePteRun+0x794
ffffd000`24d54710 fffff801`82eb8e57 : ffffe000`472eb480 ffffe000`4c246180 00000000`00000005 00000000`00000000 : nt!MiDeleteVirtualAddresses+0x51a
ffffd000`24d548c0 fffff801`82ebb519 : ffffe000`4b0e36f0 00000000`00000010 00000000`00000000 00000013`00000000 : nt!MiDeleteVad+0x2c7
ffffd000`24d549a0 fffff801`82fc33e3 : ffffe000`47449880 ffffe000`476bd880 00000000`00001680 00000000`00000b40 : nt!NtFreeVirtualMemory+0x879
ffffd000`24d54b00 00007ffe`6e53093a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000013`51cffb08 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`6e53093a


SYMBOL_NAME: nt!MiDeletePteRun+794

MODULE_NAME: nt

IMAGE_VERSION: 6.3.9600.19538

STACK_COMMAND: .thread ; .cxr ; kb

IMAGE_NAME: memory_corruption

BUCKET_ID_FUNC_OFFSET: 794

FAILURE_BUCKET_ID: 0x1a_403_nt!MiDeletePteRun
Wieder ein Speicherfehler. Der letzte Besitzer war hier auch der Firefox.
 
Anzeige
Oben