Fehlende CPU Cores

Drewkev schrieb:
Also das einzige was ich einstelle
Willst du mich jetzt Trollen?
Du schlägst dem TE allen Ernstes vor nach jedem ausschalten des PC 2-3min im BIOS Setup zu verbringen anstatt einmal 5-6minuten fürs wechseln einer Batterie zu investieren?
 
Backfisch schrieb:
Um einen BIOS-seitigen Softwarefehler auszuschließen natürlich.
Wenn es in der Version einen Fehler gab dann hat er sich die Jahre über gut versteckt...

Im Ernst.
Wieso geht man nicht erstmal den Dingen nach die sich nachweislich im Laufe der Zeit verändern und Effekte auf den laufenden Betrieb haben?
Dinge die man auch einfach und billig "reparieren" kann. Vor allem immer nur eins nach dem anderen.

Das sich die BIOS Software im Flash über die Jahre selbstständig ändert höre ich jedenfalls das erste mal(Quelle?)

Zudem beschreibt MSI selbst die neuste BIOS Version als inkonsistent(BETA). Raten sogar davon ab.
 
@Tulol

Ich wüsste nicht, warum du hier in diesem Thread Anspruch darauf haben solltest über die Nützlichkeit und Priorität der Beiträge und Maßnahmen entscheiden zu dürfen. Die User haben einen Satz an Maßnahmen genannt, es liegt am Threadersteller - NICHT an dir - nun weiterzuschauen.
 
@Backfisch
Ich versuche dem TE unnötigen Ärger zu ersparen und empfehle Logik walten zu lassen.
und immer wenn ich eine Begründung für einen seltsamen "Vorschlag" erfragen kommen pöbeleien wie die deine.

Ich erhebe keinen Anspruch auf Perfektion Versuche aber nach bestem wissen und Gewissen zu handeln.
Ich hätte auch schreiben können das ich ein BIOS Update hier für blödsinnig und potenziell gefährlich halte, wollte aber wissen wieso man das hier empfiehlt, eventuell hats da was, das ich lernen kann. Aber es kam nix.
 
1pressaltf4 schrieb:
Hatte jemand schon einmal einen ähnlichen Fehler oder einen Tipp woran das Problem liegen könnte?

Das ist mal ein wirklich "interessantes" Problem. Ich kann mir eigentlich nicht so recht vorstellen, dass die hier schon in den Raum gestellten Ideen (Kühlung, RAM, CMOS-Batterie, BIOS Update) zielführend sind. Das ist wirklich nicht als Kritik gemeint, es ist halt so eines der Probleme wo man echt "blind im Nebel" stochert.

Ich versuche mal "laut zu denken":

Die Konfiguration der CPU (Anzahl Kerne, Threads, usw.) wird eigentlich nicht im Betrieb dynamisch ermittelt und verändert. Sie wird vom BIOS/UEFI in Form von Konfigurationstabellen wie ACPI bereitgestellt und vom Betriebssystem ganz früh während der Bootphase ausgelesen und damit z.B. die Tabellen des Kernel Schedulers initialisiert. Wie das aussieht sieht man z.b. im Windows Gerätemanager in der Ansicht "nach Verbindung":
1645812190553.png


Programme wie HWInfo64 zeigen das ähnlich an, nur ausführlicher und manchmal aufbereitet.
An meinem Beispiel siehst Du wie das bei einer 4 Kern/ 8 Core CPU aussieht, jeder logische Prozessor (Thread) gibt einen Eintrag.

Mir sind keine Möglichkeiten bekannt, wie das im Betrieb verändert werden sollte. Würde der Prozessor einen Hardwareschaden haben (Defekter Kern z.B.) würde er nicht im Task manager verschwinden, sondern das System wurde abstürzen oder hängen, denn der Scheduler würde ja weiter Threads an diesen Kern zuweisen. Würde durch z.B. einen RAM Defekt die Scheduler-Tabellen im Kernel kaputt gehen, müsste man eigentlich auch eher von einem Absturz ausgehen.
Man muss dazu sagen: Die gesamte Verwaltung von Prozessen/Threads wird nicht von der Hardware gemacht, sondern ist eine Softwarefunktion des Betriebssystems.

Falls, wie in Deinem Fall von HWINFO64 kolportiert, Hyper-V aktiv ist, werden diese Aufgaben vom Hypervisor anstatt vom "normalen" Kernel ausgeführt, aber das ist auch eigentlich egal.


Der Hypervisor wäre aber ein möglicher Ansatzpunkt, denn der kann den unter ihm laufenden Gastsystemen eine beliebige andere Anzahl CPU Kerne melden. Das passiert z.b. wenn man einer virtuellen Maschine sagt, sie soll nur eine bestimme Anzahl vCPUs nutzen, da sind dann auch "krumme" Zahlen wie 3 oder 7 möglich.
Mit ist aber nicht bekannt, dass der in Windows integrierte Hypervisor sowas mit dem "Host"-Windows tut.

Eine mögliche andere Erklärung wäre, dass der Taskmanager kompromitiert wurde. Es gibt z.B. Trojaner die den Taskmanager manipulieren um ihre eigenen Prozesse zu verbergen. Hätte so ein Code einen Bug (z.B. weil der Patch sich mit einem Windows Update nicht verträgt) könnte er auch andere Störungen im Taskmanager verursachen. Aber das ist wirklich auch sehr weit hergeholt.

Du hast gesagt, Du hast schon alternativ ein Linux gebootet, aber da das Problem nicht immer reproduzierbar ist, war das nicht aussagekräftig. Eine Möglichkeit wäre natürlich das Linux mal länger laufen zu lassen, vielleicht auch irgendwie Last erzeugen um zu schauen ob es doch erzwungen werden kann.
Passiert es dort auch, muss es irgendwo doch an der Hardware liegen (auch wenn mir wie gesagt nicht einfällt wie...).
Passiert es unter Linux nicht, sagt es halt leider umgekehrt gar nichts aus...

Lange Rede kurzer Sinn: Ich würde das Problem eher in einer kaputten Windows Installation suchen als bei der Hardware.
 
Zurück
Oben