Samsung S10 stützt immer wieder ab

[DreamGamer]

Hallo, ich habe ein starkes Problem mit meinem Smartphone. Seit knapp 1 Monat stürzt es fast täglich ab. Es hängt sich plötzlich auf und geht wenige Sekunden später aus. Sobald es aus ist, startet es meistens direkt neu und stürzt beim neu starten wieder ab. Manchmal, wie auch heute, bleibt das Gerät komplett aus und lässt sich auch nicht mehr starten. Es reagiert auf keine Eingabe, auch nicht auf leiser Taste + Power.

Sobald das aber passiert, stürzt das Handy jedes Mal wieder ab, nachdem es gestartet ist und so habe ich heute den Log ausgelesen, während es nach einigen Minuten neu gestartet ist. Ich bin mir unschlüssig, was es genau ist. Könnt ihr vielleicht mehr mit dem Log anfangen?

Der Log aus Flipper befindet sich im Anhang und kann über die FBFlipper Software (https://fbflipper.com/) geöffnet und eingesehen werden. Unten Links ist ein Einstellungsrad, wenn man da drauf klickt, kann man log Importieren drücken.

Spoiler: Diese Meldung war kurz vor dem absturz

Load: 36.53 / 26.56 / 15.02
------ Current CPU Core Info ------

• offline :
• online : 0-7
• AP Temp = 369

0 1 2 3 4 5 6 7
------------------------------------------------------------------------------------------------------------------
scaling_cur_freq 1950000 1950000 1950000 1950000 1404000 1404000 1378000 1378000
scaling_governor schedutil schedutil schedutil schedutil schedutil schedutil schedutil schedutil
scaling_max_freq 1950000 1950000 1950000 1950000 2314000 2314000 2730000 2730000
------------------------------------------------------------------------------------------------------------------
CPU usage from 1140354ms to 0ms ago (2023-06-04 20:19:51.380 to 2023-06-04 20:38:51.734):
23% 960/system_server: 15% user + 7.5% kernel / faults: 1989307 minor 8969 major
2.8% 129/kswapd0: 0% user + 2.8% kernel
2.3% 623/surfaceflinger: 1.3% user + 0.9% kernel / faults: 25121 minor 948 major
0.9% 226/sugov:4: 0% user + 0.9% kernel
0.8% 414/lmkd: 0% user + 0.7% kernel / faults: 63 minor
0.8% 413/logd: 0.2% user + 0.5% kernel / faults: 19865 minor 756 major
0.7% 227/sugov:6: 0% user + 0.7% kernel
0.6% 532/statsd: 0.5% user + 0.1% kernel / faults: 9467 minor 277 major
0.5% 380/dhd_rpm_state_t: 0% user + 0.5% kernel
0.4% 225/sugov:0: 0% user + 0.4% kernel
0.4% 737/installd: 0.1% user + 0.3% kernel / faults: 2636 minor 360 major
0.4% 386/ueventd: 0.3% user + 0% kernel / faults: 3209 minor 11 major
0.4% 415/servicemanager: 0.1% user + 0.2% kernel / faults: 1421 minor 25 major
0.3% 534/zygote64: 0% user + 0.3% kernel / faults: 22219 minor 1 major
0.3% 475/keystore2: 0.1% user + 0.1% kernel / faults: 6664 minor 559 major
0.3% 551/android.hardware.graphics.composer@2.2-service: 0.1% user + 0.2% kernel / faults: 2158 minor 75 major
0.3% 20/ksoftirqd/1: 0% user + 0.3% kernel
0.2% 438/jbd2/sda31-8: 0% user + 0.2% kernel
0.2% 476/android.hardware.keymaster@4.0-service: 0% user + 0.2% kernel / faults: 1208 minor 29 major
0.2% 703/kworker/u17:3: 0% user + 0.2% kernel
0.2% 74/kworker/u17:0: 0% user + 0.2% kernel
0.2% 130/kworker/u18:0: 0% user + 0.2% kernel
0.2% 1/init: 0% user + 0.1% kernel / faults: 6903 minor 75 major
0.2% 90/kworker/u17:1: 0% user + 0.2% kernel
0.2% 178/kworker/u16:1: 0% user + 0.2% kernel / faults: 16 minor
0.2% 8/rcu_preempt: 0% user + 0.2% kernel
0.2% 561/android.hardware.sensors@2.0-service.multihal: 0% user + 0.1% kernel / faults: 1134 minor 145 major
0.1% 758/argosd: 0.1% user + 0% kernel / faults: 153 minor
0.1% 359/kworker/u16:8: 0% user + 0.1% kernel / faults: 7 minor
0.1% 53/tz_worker_threa: 0% user + 0.1% kernel
0.1% 27/ksoftirqd/2: 0% user + 0.1% kernel
0.1% 752/wificond: 0% user + 0.1% kernel / faults: 639 minor 83 major
0.1% 533/netd: 0% user + 0% kernel / faults: 8185 minor 179 major
0.1% 331/decon0: 0% user + 0.1% kernel
0.1% 32/tz_worker_threa: 0% user + 0.1% kernel
0.1% 617/audioserver: 0% user + 0% kernel / faults: 12396 minor 635 major
0.1% 7/ksoftirqd/0: 0% user + 0.1% kernel
0.1% 563/android.hardware.wifi@1.0-service: 0% user + 0.1% kernel / faults: 1314 minor 13 major
0.1% 557/android.hardware.memtrack@1.0-service: 0% user + 0% kernel / faults: 620 minor 88 major
0.1% 69/kworker/2:1: 0% user + 0.1% kernel
0% 535/zygote: 0% user + 0% kernel / faults: 22425 minor 457 major
0% 427/vold: 0% user + 0% kernel / faults: 10606 minor 23 major
0% 795/rild: 0% user + 0% kernel / faults: 13289 minor 601 major
0% 34/ksoftirqd/3: 0% user + 0% kernel
0% 325/devfreq_change: 0% user + 0% kernel
0% 384/init: 0% user + 0% kernel / faults: 1 minor
0% 21/kworker/1:0: 0% user + 0% kernel
0% 724/incidentd: 0% user + 0% kernel / faults: 5539 minor
0% 60/tz_worker_threa: 0% user + 0% kernel
0% 766/lhd: 0% user + 0% kernel / faults: 288 minor

Mit freundlichen Grüßen
DreamGamer

 

[conglom-o]

Passiert das auch, wenn Du es am Kabel (=Laden) hast?

 

[DreamGamer]

@conglom-o Ja, es passiert sogar öfter, wenn es am Laden ist und der Akku macht bis heute keine Probleme und ist immernoch in einem guten Zustand. Es passiert bei 20% Akku, sowie bei 100%, aber auch bei 50%.

Als der Log über Flipper aufgenommen wurde, war das Handy ebenfalls am PC am Laden.

 

[siggi%%44]

Das Log (Spiler) sagt gar nichts darüber aus, was der Grund ist. Die Software kann ich jetzt nicht installieren. Kannst du es nicht als Textdatei posten?

 

[DreamGamer]

@siggi%%44 Nicht direkt, Flipper gibt den Log als JSON aus. Aber hierdrüber kannst du es lesen: https://jsonformatter.org/json-viewer

Die JSON-Datei ist in der ZIP-Datei, da die Datei leider zu groß ist für pastebin und co.

Ergänzung (4. Juni 2023)

@siggi%%44 Hier wäre die JSON-Datei ansonsten nochmal als externer einzelner Download :=)
https://we.tl/t-bKEx8ol1AS

 

[siggi%%44]

@DreamGamer So toll die App auch sein mag, aber sie kann nicht mehr als andere Apps. Das liegt daran, dass Android (ebenso wie Linux) mit Zugriffsrechten arbeitet und deine App gleich viele Zugriffsrechte hat wie z.B. ein Taschenrechner - nämlich so gut wie gar keine. Ich spreche nicht von Runtime Permissions wie Speicherzugriff, sondern davon, welche UID sie hat. In der Hierachie sind Benutzerapps jeglicher Art ganz unten angesiedelt. Ganz oben steht Root.
Ich spreche das an, weil du irgendwo dazwischen mit ADB (Entwicklertool, um Apps zu "debuggen") ansetzen kannst. Mit ADB hast du jedenfalls mehr Rechte als eine Benutzerapp, da ADB als User "Shell" angemeldet ist und somit zumindest das Systemlog lesen darf. Das blöde an den Logs bei Android ist, dass sie im RAM liegen und ohne Strom arbeitet dein RAM nicht. Ist dein Handy aus, sind die Logs weg. Du musst also mit ADB das Systemlog (logcat) fortlaufend auslesen, bis sich dein Handy verabschiedet. Dann kannst du dir die letzten Zeilen ansehen und (hoffentlich) den Grund finden. Wie das alles funktioniert, siehst du jetzt (falls du es noch nicht kennst):

---

ADB aktivieren (USB-Debugging):
Um USB-Debugging (Schnittstelle für ADB) zu aktivieren, müssen sie sog. "Entwickler Optionen" freigeschaltet werden. Dabei handelt es sich um ein verstecktes Untermenü deiner Geräteeinstellungen, das es bei jedem Android gibt. Laut Samsung funktioniert das wie hier beschrieben.

ADB-Tool für Windows/Linux/MAC: Für den PC (ich gehe von Windows aus) brauchst du das entsprechende Tool, um über die Eingabeaufforderung (cmd.exe) deine Befehle an dein Handy zu senden. Den Download findest du hier.

Log erstellen:

1.) ADB Tool runterladen, entpacken und Ordner + Unterverzeichnisse öffnen, bis du einzelne Dateien vorfindest. Dann im Explorer oben in die Adressleiste "cmd" eingeben und Enter drücken -> cmd.exe öffnet sich.

2.) Verbinde dein Handy über USB mit deinem PC, entsperre das Display und halte es griffbereit.

3.) Am PC gibst du in die cmd.exe folgenden Befehl ein, um zuerst die Verbindung zu prüfen:

adb devices

ADB wird daraufhin initialisiert und währenddessen wird auf dem Display deines Handys eine Zugriffsbestätigung verlangt. Diese bestätigen und dann sollte am PC folgeder Output zu sehen sein, der die korrekte Verbindung bestätigt:

C:\ADB_Fastboot>adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
<SERIENNR.>     device

4.) Gibst du nun den folgenden Befehl ein, siehst du ein richtiges Systemlog von Android :

adb logcat

Der Befehl endet nicht selbstständig. Mit STRG+C kannst du ihn stoppen.

5.) Um den Output in einer Datei zu speichern:

adb logcat > log.txt

=> Dort, wo du vorhin "cmd" in die Adressleiste eingegeben hast, findest du nun die Datei "log.txt", die solange gefüllt wird, wie der Befehl läuft oder dein Speicher es verkraftet. Jetzt heißt es warten, bis dein Handy wieder ausgeht. Viel Erfolg!

 

[DreamGamer]

@siggi%%44 Das ist keine Android App :=) Facebook Flipper ist eine Grafische oberfläche, die über die Android SDK, also adb den Log Speichert und Grafisch ausgibt. Ich nutze dies für App Entwicklung. Die JSON-Datei ist also ein vollständiger log, nur leider etwas umständlicher zum öffnen, es ist aber genau dasselbe, wie logcat als txt zu speichern. Ich kann sobald ich wieder Zuhause bin probieren die JSON zu einer Textdatei zu formatieren, falls dir das hilft? :=)

 

[siggi%%44]

Ein logcat ist ausführlicher und würde ein breiteres Spektrum bieten. Ein Fehler, der zum Shutdown/Reboot führt, wäre ausführlicher beschrieben. Der Shutdown des Systems würde alleine schon 200-300 Zeilen umfassen, weil etliche Receiver sofort reagieren würden und alle möglichen Dienste beenden. Zusätzlich wäre noch der Fehler selber viel detaillierter dokumentiert. Entweder wird logcat durch das Tool mithilfe von Befehlsoptionen massiv eingeschränkt (s. dazu "adb logcat --help") oder das Tool bedient sich anderer Methoden.

Ergänzung (5. Juni 2023)

Ich habe mittlerweile dein Tool installiert und die *.flipper Datei darin geöffnet. Deshalb sage ich ja...

Ergänzung (5. Juni 2023)

Der Befehl "adb bugreport" zeigt das volle Spektrum, was ADB an Logs im System zusammenstellen kann. Damit kommst du auf min. 20 MB reinen Text und alles voll mit nützlichen Infos.

 

[DreamGamer]

@siggi%%44 Normal müsste FB Flipper ebenfalls alles speichern, oben Links kann man auswählen, was für Meldungen alle angezeigt werden sollen. Aber ich werde dann heute im laufe des Tages versuchen das ganze per logcat direkt abzuspeichern :=) Also vorausgesetzt, das Handy stürzt in dem Zeitraum wieder ab :=)

 

[siggi%%44]

Es gibt auch die Option "Wireless ADB". Dann hast du dir wenigstens während der Wartezeit die Kabelverbindung und die damit verbundenen Einschränkungen gespart.

 

[DreamGamer]

@siggi%%44 Gut 1 Woche später gibt es endlich ein Update!
Das Handy ist zwar mehrfach täglich gecrasht, aber leider immer, als ich aus dem Haus war, oder als es kurz abgesteckt war.

Heute hat es sich am 10.06.2023 um 21:50 für ca. 1 - 2 Minuten aufgehangen. Bedeutet, es hat nichts mehr reagiert, weder die Apps, noch das Sperren des Handys, während logcat wireless lief. Abgestürzt ist es aber zu diesem Zeitpunkt nicht. Der Log dazu liegt als "HandyLaggtExtrem.txt" dabei.

Dann eben um 00:08 ist während der normalen Nutzung des Handys auf dem Homebildschirm das Handy einfach ohne Vorwarnung ausgegangen und bliebt auch aus. Sprich, bis jetzt 00:24, also 16 Minuten später, startet das Handy weiterhin nicht mehr und bleibt schwarz. Es startet sich in aller Regel nach 30 Minuten - 1 Stunde automatisch selber wieder, also ohne, dass ich es manuell einschalten muss. Der Log dazu bringt für mich keinen Aufschluss, wurde aber bis zum plötzlichen ausgehen des Handys übertragen und liegt als "crash0uhr8_11_06_2023.txt" bei.

Ich hoffe, mit diesen Logs kann vielleicht jemand mehr anfangen und mir helfen :=)

Ergänzung (11. Juni 2023)

Update 1 Stunde später: Das Handy startet weiterhin nicht, es wirkt immer noch wie tot. Es reagiert nicht auf Laden, es gibt also kein Ladesymbol, wie, wenn das Gerät ausgeschalten ist. Und Einschalten funktioniert ebenfalls nicht, genauso wie die leise Taste + den Powerknopf gedrückt zu halten bewirkt nichts. Nach ca. 30 Minuten ist es von selber neu gestartet, ganze 8x und ist jedes Mal beim Neustarten, während das Samsung Symbol kam wieder ausgegangen. Logcat ließ sich zu diesem Zeitpunkt nicht auslesen.

 

[DreamGamer]

10 Minuten später ist das Handy wieder gestartet und gecrasht. Dieses Mal kam kein Samsung Logo, sondern nur die Vibration vom Starten 2x. Beim 3. Mal ist das Handy gestartet, bis zur Pin Eingabe. Nach dem ersten Antippen auf das Display, ist das Handy wieder direkt ausgegangen, aber direkt neugestartet. Beim 4. Start, ging dann alles problemlos und jetzt läuft es wieder. Ich habe noch den Log direkt nach dem Start gespeichert, vielleicht hilft dieser noch :=)

 

[siggi%%44]

@DreamGamer Bis auf die Tatsache, dass dein Speicher sehr voll ist und nur noch 1.3GB frei sind, gibt es nix auffälliges in den Logs. Es gibt auch verhältnismäßig wenig Errors. Eigentlich alles normal und kann dir nicht sagen, woran es liegt. Was mir noch einfallen würde, wäre nach einem Neustart einen Fehlerbericht zu erstellen:
adb bugreport

Da ist alles drin. Manchmal gibt es kleine Logs, die einen Absturz protokollieren und über den Neustart hinaus gespeichert werden.

 

[DreamGamer]

@siggi%%44 Danke für das Überprüfen, aber komisch, dass im Log nichts dazu steht. Liegt das vielleicht daran, dass ADB wireless verbunden war und nicht über das Handy? Und das Handy ist mittlerweile 2 weitere Male abgestürzt, ging aber beide Male direkt wieder an.

Ich habe eben ein Bugreport erstellt, wie du sagtest, vielleicht bringt sehr mehr aufschluss :=)

 

[siggi%%44]

Nimm den Link bitte wieder raus. In diesem Bugreport steht alles drin, u.a. auch Daten, die du nicht teilen solltest wie z.B. die Mailadresse deines Google Kontos.

ich hab den Bugreport auch nicht runtergeladen.

 

[DreamGamer]

@siggi%%44 Danke für den Hinweis! Das wusste ich garnicht!

Ergänzung (11. Juni 2023)

@siggi%%44 Hast du den Bugreport bereits gedownloadet? Oder soll ich dir den Privat schicken?

 

[siggi%%44]

Ich hab ihn nicht runtergeladen. Es wird auch nicht viel bringen, weil zu 99% keine Infos über die Abstürze drin sein werden.

Ergänzung (11. Juni 2023)

Mach die ZIP mal auf und schau dir die einzelnen Logs in den verschiedenen Ordnern an, ob z.B. irgendwo ein "last_kernel.log" drin ist. Oder irgendein Log, das darauf schließen lässt, dass Infos vor dem letzten Neustart drin sein könnten.

 

[DreamGamer]

@siggi%%44 Der Bugreport wurde 3 Minuten nach dem Crash erstellt, also müsste dieser ja eig. drin stehen. Einen last_kernal log gibt es, aber ich kann damit leider nicht soviel anfangen. Kann ich diesen hier posten, oder enthält der auch sensible daten?

 

[siggi%%44]

Es spielt keine Rolle wie lange der Crash zurückliegt. Für die Logs ist es wichtig, dass es zu keinem Neustart kam. Die relevanten Systemlogs liegen im RAM. Schaltet sich dein Handy aus und der RAM bekommt keinen Strom mehr, wird der Speicher des RAMs gelöscht. Der RAM ist ein sog. flüchtiger (nicht-persistenter) Datenspeicher, der Daten nur speichert, solange er mit Strom versorgt wird.

Machst du ZIP auf, sind dort Ordner zu sehen. In /FS/cache/recovery ist nichts brauchbares drin. Der Inhalt bezieht sich nur auf die Recovery, die einen eigenen Kernel und eine eigene Umgebung hat und unabhängig vom System läuft, wenn sie gestartet wird.
In /FS/data ebenso. Aber weitere in /FS, die ich nicht genannt habe, könnten interessant sein.

Gibt es zufällig /FS/sys?

Die riesige Textdatei in der ZIP (außerhalb von FS) bezieht sich auch nur auf Infos seit Neustart. Das ist nur eine Zusammenfassung aller Logs, die es im System gibt.

 

[DreamGamer]

@siggi%%44 Danke für ausführliche Aufzählung. /FS/sys gibt es, dort sind aber in /FS/sys/fs/cgroup 225 verschiedene Ordner und 7 Dateien. Und dann gibt es noch /FS/proc mit 113 verschiedenen Ordner.