Seit Bluescreen "System"-Prozess mit 10% CPU-Auslastung

Status
Für weitere Antworten geschlossen.
Kurt Blahovec schrieb:
Nicht böse sein. :schluck:
Screenshot von bluescreenview wär eine sache von 4 Minuten gewesen für alles inkl. Bild upload hier und das ohne irgendwelche persönlichen Daten -.-
 
Gibt's das überhaupt - einen Nicht-Fullscreen-Bluescreen??

Wäre mir jedenfalls SEHR neu!

Irgendwas ist da merkwürdig!
 
@Kurt Blahovec der Rechner schreibt gerade ein vollständiges Dump, es reicht aber normalerweise ein Minidump, das ist nur wenige KB groß und nicht mehrere hundert MB wie jetzt.

Dazu WIN+X und System, da rechts die 'Erweiterten Systemeinstellungen' und 'Starten und Wiederherstellen'. Unter 'Systemfehler' den Haken beim automatischen Neustart entfernen und im Dropdown auf 'Kleines Speicherabbild (256 KB)' umstellen. Die DMPs sind dann unter c:\windows\minidump.

Dann werden nur die wichtigsten BSOD-bezogenen Infos geloggt und keinerlei personenbezogene daten :).
 
hasenbein schrieb:
Gibt's das überhaupt - einen Nicht-Fullscreen-Bluescreen??

Wäre mir jedenfalls SEHR neu!

Irgendwas ist da merkwürdig!
Auch Mal überlegt das der Monitor bei der Auflösung des bluescreens diesen nicht auf das volle Bild "hochziehen muss"... Und somit halt Ränder entstehen.
 
  • Gefällt mir
Reaktionen: rg88
Kurt Blahovec schrieb:
Ich hatte heute plötzlich 1-2 Minuten nach dem Einschalten des PCs im Leerlauf am Desktop einen Bluescreen
Die Informationen zum blue screen befinden sich im Ordner
C:/Windows/Minidump
Die letzten fünf Files auf den Desktop kopieren.
Mit rar oder zip verpacken.
Hier im Forum hoch laden.
 
Hallo.
Im Mindump-Ordner gibts nur eine Datei:
Code:
Microsoft (R) Windows Debugger Version 10.0.25200.1003 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\???Zensur???\Desktop\120422-5968-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available


************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff805`5c200000 PsLoadedModuleList = 0xfffff805`5ce2a2b0
Debug session time: Sun Dec  4 22:29:57.882 2022 (UTC + 1:00)
System Uptime: 0 days 0:02:04.502
Loading Kernel Symbols
...............................................................
................................................................
.......................................................
Loading User Symbols
Loading unloaded module list
........
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff805`5c5f92d0 48894c2408      mov     qword ptr [rsp+8],rcx ss:0018:ffffba06`15bc4b70=0000000000000005
1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

INVALID_PROCESS_ATTACH_ATTEMPT (5)
Arguments:
Arg1: ffffe40c7ac85080
Arg2: ffffe40c815b2080
Arg3: 0000000000000001
Arg4: ffffe40c7ad37080

Debugging Details:
------------------


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 2702

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 9218

    Key  : Analysis.IO.Other.Mb
    Value: 0

    Key  : Analysis.IO.Read.Mb
    Value: 0

    Key  : Analysis.IO.Write.Mb
    Value: 0

    Key  : Analysis.Init.CPU.mSec
    Value: 312

    Key  : Analysis.Init.Elapsed.mSec
    Value: 25125

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 84

    Key  : Bugcheck.Code.DumpHeader
    Value: 0x5

    Key  : Bugcheck.Code.Register
    Value: 0x5

    Key  : WER.OS.Branch
    Value: vb_release

    Key  : WER.OS.Timestamp
    Value: 2019-12-06T14:06:00Z

    Key  : WER.OS.Version
    Value: 10.0.19041.1


FILE_IN_CAB:  120422-5968-01.dmp

BUGCHECK_CODE:  5

BUGCHECK_P1: ffffe40c7ac85080

BUGCHECK_P2: ffffe40c815b2080

BUGCHECK_P3: 1

BUGCHECK_P4: ffffe40c7ad37080

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  csrss.exe

STACK_TEXT: 
ffffba06`15bc4b68 fffff805`5c631f7e     : 00000000`00000005 ffffe40c`7ac85080 ffffe40c`815b2080 00000000`00000001 : nt!KeBugCheckEx
ffffba06`15bc4b70 fffff805`5c471d25     : ffffe40c`7ad37080 00000000`00000080 ffffe40c`7ac85080 00000000`00000000 : nt!ExpWorkerThread+0x1df51e
ffffba06`15bc4c10 fffff805`5c601f08     : ffffcd01`1e782180 ffffe40c`7ad37080 fffff805`5c471cd0 00000000`00000000 : nt!PspSystemThreadStartup+0x55
ffffba06`15bc4c60 00000000`00000000     : ffffba06`15bc5000 ffffba06`15bbf000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28


SYMBOL_NAME:  nt!KiStartSystemThread+28

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

IMAGE_VERSION:  10.0.19041.2251

STACK_COMMAND:  .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET:  28

FAILURE_BUCKET_ID:  0x5_nt!KiStartSystemThread

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {b8765eff-c5d2-550e-d4cc-d739ee7dbafd}

Followup:     MachineOwner
---------

1: kd> !blackboxbsd
Version: 0xb0
Product type: 1

Auto advanced boot: FALSE
Advanced boot menu timeout: 30
Last boot succeeded: TRUE
Last boot shutdown: FALSE
Sleep in progress: FALSE

Power button timestamp: 0x0
System running: TRUE
Connected standby in progress: FALSE
User shutdown in progress: FALSE
System shutdown in progress: FALSE
Sleep in progress: 0
Connected standby scenario instance id: 0
Connected standby entry reason: 0
Connected standby exit reason: 0
System sleep transitions to on: 0
Last reference time: 0x1d9082746031c99
    2022-12-04T21:27:55.549Z
Last reference time checksum: 0xb0bfd1b1
Last update boot id: 204

Boot attempt count: 1
Last boot checkpoint: FALSE
Checksum: 0x44
Last boot id: 204
Last successful shutdown boot id: 203
Last reported abnormal shutdown boot id: 203

Error info boot id: 0
Error info repeat count: 0
Error info other error count: 0
Error info code: 0
Error info status: 0x0

Power button last press time: 0x0
Power button cumulative press count: 0
Power button last press boot id: 0
Power button last power watchdog stage: 0
Power button watchdog armed: FALSE
Power button shutdown in progress: FALSE
Power button last release time: 0x0
Power button cumulative release count: 0
Power button last release boot id: 0
Power button error count: 0
Power button current connected standby phase: 0
Power button transition latest checkpoint id: 0
Power button transition latest checkpoint type: 0
Power button transition latest checkpoint sequence number: 0

Power transition Shutdown Device Type: 0
Power transition Setup In Progress: FALSE
Power transition OOBE In Progress: FALSE
Power transition Sleep Checkpoint Source: 0
Power transition Sleep Checkpoint: 0
Power transition Connected Standby Entry Reason Category: 0
Power transition Connected Standby Exit Reason Category: 0
Power transition Connected Standby Entry Scenario Instance Id: 0x0

Feature Configuration State : Uninitialized

1: kd> !blackboxntfs

NTFS Blackbox Data

0 Slow I/O Timeout Records Found
0 Oplock Break Timeout Records Found

Bitte melden, wenn zu wenig/viel Info.
Danke und mfg
 
Wollte die große .dmp und die Minidump gerade nochmals auf den Desktop kopieren, um sie zu zippen und raufzuladen. Beide sind nicht mehr im Windows-Ordner oder sonst wo zu finden. Ich habe sie aber zu 100% nicht verschoben oder manuell gelöscht ... :confused_alt:
Aber sind Zeile 38-149 aus meiner WinDbg Bugcheck Analysis nicht das, was auch Bluescreenview ausgespuckt hätte? Kann man da keinen Grund für den Bluescreen herauslesen ?

mfg
 
Zuletzt bearbeitet:
Seit geraumer Zeit habe ich auch das ~10% Last Problem mit Win10.

Also PC Idle, keine Programme auf, aber 10% Last durch Prozess "System" laut Taskmanager. Kann mir wer sagen, wo diese 10% Last herkommen? Ohne Maus/Keyboardeingabe startet "System" nach ca. 2 Minuten...
 
Mr.Seymour Buds schrieb:
Seit geraumer Zeit habe ich auch das ~10% Last Problem mit Win10.
Mach einen eigenen Thread auf.

Und nimm processExplorer um zu schauen, was die Last erzeugt.
 
Mr.Seymour Buds schrieb:
Seit geraumer Zeit habe ich auch das ~10% Last Problem mit Win10.

Also PC Idle, keine Programme auf, aber 10% Last durch Prozess "System" laut Taskmanager. Kann mir wer sagen, wo diese 10% Last herkommen? Ohne Maus/Keyboardeingabe startet "System" nach ca. 2 Minuten...

Habe ich hier auch.

Abhilfe: https://www.computerbase.de/downloads/systemtools/autohotkey/ in der 1.1er-Version downloaden, und folgendes Skript laufen lassen

#InstallMouseHook SetDefaultMouseSpeed, 0 SetMouseDelay, 0 CoordMode, Mouse, Screen #Persistent SetTimer, MoveMouse, 60000 MoveMouse: If ( A_TimeIdle > 150000 ) { MouseMove, 1, 0, 0, R MouseMove, -1, 0, 0, R } Return

Dadurch wird jede Minute geprüft, ob seit der letzte Nutzeraktion 150s vergangen sind. Wenn ja wird die Maus einen Pixel verschoben und wieder zurückgesetzt, und somit eine Benutzerinteraktion "vorgetäuscht".

Funktioniert, und verhindert den von dir beschriebenen idle-Fehler.
 
  • Gefällt mir
Reaktionen: Mr.Seymour Buds und SPB
Der Script war eigentlich mal vor Ewigkeiten dafür gedacht, dass der Bildschirmschoner nicht angeht wo z.B. per Richtlinie das fest eingestellt ist.

Hatten das selbst, mehr angepasst unter XP und W7, als EXE im Autostart ausgewählter Geräte.
 
  • Gefällt mir
Reaktionen: Mr.Seymour Buds
Es hilft auch bei Spielen, in denen man bei längerer Abwesenheit automatisch "ausgeloggt" wird. ;)
 
  • Gefällt mir
Reaktionen: Mr.Seymour Buds
nach 2 Minuten wird der Idle Maintenance Task sein, der dann ngen ausführt und auch den RAM auf Fehler testet etc.
 
  • Gefällt mir
Reaktionen: Mr.Seymour Buds
Mag alles sein. @Corpus Delicti
Grundproblem ist nur, dass solch Art Script durchaus in der Lage ist Wartungsarbeiten des OS an sich selbst zu killen weil das Teil meint man arbeitet pausenlos. Dann kann die Warung irgendwann mal heftig reingreifen und der Nutzer schreit das seine "Kiste endlos auf den Datentraegern rum rattert".

Anyway.
Der TE sollte mal mit etwas anderem als den Taskmanager schauen wer als Sytem da was macht.
Ich bin da wirklich bei der regulaeren Wartung.
 
Sehr wahrscheinlich ist es ein Wartungsprozess. Aber was wird da so lange gemacht mit 10% Last? Schüft MS da Crypto auf der Stromrechnung der OS Kunden?
 
  • Gefällt mir
Reaktionen: Kurt Blahovec
Hinterfragen und Auszutesten beim eigenen System ware waere hier die bessere Alternativie gewesen.
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Zurück
Oben