iPhone 15 烈日下錄影黑屏重開：一份 Kernel Panic 的解讀

📌 一句話結論

這不是 app 寫壞、也不是手機壞掉。log 顯示這是一次 watchdog timeout 觸發的 kernel panic：系統在「關機 / 重開的過程中卡住」，硬體看門狗（watchdog）等了 95 秒等不到回應，為了保護硬體，直接切斷電源強制重開。最可能的觸發原因是 正午高溫 + 滿載錄影 把手機逼到極限——簡單說，你的 iPhone 昨天「中暑」了。

📌 TL;DR

This wasn't a buggy app, and your phone isn't broken. The log shows a watchdog-timeout kernel panic: the system stalled during a shutdown/reboot, the hardware watchdog waited 95 seconds for a response that never came, and to protect the hardware it cut power and forced a reboot. The most likely trigger was extreme heat plus a fully-loaded camera pushing the phone past its limit — in short, your iPhone got heatstroke.

☀️ 當時的情境

事發時間是正午 12:00，地點在大太陽底下用 iPhone 15 錄影。錄影前後手機已經反覆跳出過熱警告，接著畫面突然全黑、無法操作，幾秒後自己重新開機。重開後一切正常。

這個情境很關鍵：正午陽光直射 + 持續錄影，是 iPhone 負載最重的場景之一——相機感測器、影像處理器（ISP）、CPU、GPU 同時滿載，加上環境高溫，機身內部溫度會飆得非常快。

☀️ The Situation

It happened at noon, filming with an iPhone 15 in direct sunlight. The phone had already been throwing overheating warnings repeatedly; then the screen went completely black and unresponsive, and a few seconds later it rebooted on its own. Everything was fine afterward.

The context matters: noon sun plus continuous video is one of the heaviest loads an iPhone can take — camera sensor, image signal processor (ISP), CPU and GPU all maxed out at once, with high ambient heat driving the internal temperature up fast.

🔍 這份 log 在說什麼

① bug_type 210 = Kernel Panic

檔案開頭 "bug_type":"210" 就是 iOS 的「核心層崩潰（Kernel Panic）」代碼。這跟一般 app 閃退（用戶層 crash）是完全不同的層級——是整個作業系統核心出問題，才會走到強制重開。

② 關鍵那一行：watchdog timeout

panic(...): watchdog timeout: no checkins from watchdogd in 95 seconds ... shutdown in progress, vfs shutdown not yet started

翻成白話：當下「關機程序已經開始」（shutdown in progress），但卡住了——連檔案系統都還沒開始收尾（vfs shutdown not yet started）。負責監看系統有沒有正常運作的看門狗，等了 95 秒都收不到 watchdogd 的回報，判定系統徹底鎖死。

③ 是誰按下重開鍵：AppleARMWatchdogTimer

backtrace 裡出現的兩個 kernel extension 講得很清楚：AppleARMWatchdogTimer（硬體看門狗計時器）和 AppleInterruptControllerV2（中斷控制器）。也就是說，最後動手切斷電源、強制重開的，是硬體層的安全機制，不是任何一支 app。

補充：log 裡 product: iPhone15,5 對應 iPhone 15 Plus、T8120 / socId 8120 是 A16 晶片。整份 panic 的指向一致——核心在等一個硬體訊號，等到看門狗失去耐心。

🔍 What the Log Actually Says

① bug_type 210 = Kernel Panic

The very first line, "bug_type":"210", is iOS's code for a kernel panic — a crash in the OS core itself. That's a completely different level from an ordinary app crash (user-space). Only a core-level failure ends in a forced reboot like this.

② The key line: watchdog timeout

panic(...): watchdog timeout: no checkins from watchdogd in 95 seconds ... shutdown in progress, vfs shutdown not yet started

In plain terms: a shutdown had already begun, but it got stuck — the filesystem hadn't even started winding down (vfs shutdown not yet started). The watchdog that monitors whether the system is alive waited 95 seconds for watchdogd to check in, got nothing, and concluded the system was fully locked up.

③ Who hit the reset: AppleARMWatchdogTimer

The two kernel extensions in the backtrace say it plainly: AppleARMWatchdogTimer (the hardware watchdog) and AppleInterruptControllerV2 (the interrupt controller). The thing that ultimately cut power and forced the reboot was a hardware-level safety mechanism — not any app.

For reference: product: iPhone15,5 is the iPhone 15 Plus, and T8120 / socId 8120 is the A16 chip. The whole panic points one direction — the core was waiting on a hardware signal until the watchdog ran out of patience.

🌡️ 為什麼會發生（三個層面）

主因：高溫錄影把硬體逼到極限

這是這次當機的元兇。當手機頻繁跳過熱警告，代表系統已經在做極限降頻保護。在極端高溫下，主機板上某些元件或感測器通訊（例如 log 底層涉及的匯流排、中斷控制器）可能出現短暫的「訊號無回應」或電壓不穩。CPU 在等硬體訊號時卡死，看門狗發現系統鎖死，為了不讓硬體燒毀，就觸發 kernel panic 切斷電源重開。

幾乎可排除：app 開發

iOS 有非常嚴格的沙盒（Sandbox）機制。就算你開發中的 app 寫出死迴圈或嚴重的 memory leak，最多也只會在「用戶層」被系統強制閃退，不太可能引發這種核心層級的 watchdog timeout。這份 log 的指向跟 app 無關。

推波助瀾：兩年多的電池老化

iPhone 15 用了兩年多，電池通常已有一定老化。老化電池在「高溫 + 高負載」的極端環境下，瞬間穩定輸出電壓的能力會明顯下降。這也解釋了為什麼前兩年沒遇到、現在才發生——電池的耐受度已經不如新機時期。

🌡️ Why It Happened (Three Layers)

Main cause: heat pushing hardware to its limit

This is the culprit. Repeated overheating warnings mean the system was already aggressively throttling to protect itself. Under extreme heat, some board components or sensor buses (like the interrupt controller seen at the bottom of this log) can briefly stop responding or see unstable voltage. The CPU stalls waiting on a hardware signal, the watchdog detects the lockup, and to avoid frying the hardware it triggers a kernel panic and cuts power.

Nearly ruled out: app development

iOS has a very strict sandbox. Even a dev app with an infinite loop or a serious memory leak would, at worst, be force-quit in user space — it's very unlikely to cause a core-level watchdog timeout like this. The log points away from any app.

Contributing factor: a 2-year-old battery

After two-plus years, the battery has some aging. An aged battery's ability to deliver stable instantaneous voltage drops noticeably under "heat + heavy load." That's why this didn't happen in the first two years — the battery's tolerance isn't what it was when new.

🛠️ 該怎麼處理

✅ 四個建議

1. 當成單一「熱當機」看待：只要回到室內常溫後手機一切正常、沒有再無故黑屏重開，就代表主機板硬體沒有實質損壞，只是系統自我保護的重開，不用過度焦慮。

2. 留意過熱警告：未來再跳溫度警告，那是系統在求救。請立刻停止錄影，絕對不要在此時插行動電源充電，並把手機移到陰涼處（但不要丟冰箱，溫差會導致內部結露損壞硬體）。

3. 檢查電池健康度：「設定 → 電池 → 電池健康度與充電」。若已低於 80%，代表峰值效能衰退，極端氣候下更容易觸發這類保護機制，可考慮更換電池。

4. 高溫場景的小習慣：烈日下長時間錄影時，拿掉厚手機殼幫助散熱、降低螢幕亮度、必要時讓手機先休息降溫再繼續。

🛠️ What To Do

✅ Four suggestions

1. Treat it as a one-off heat shutdown: if the phone works normally back at room temperature with no further random reboots, the board hardware is fine — it was just self-protection. No need to panic.

2. Respect overheating warnings: next time one appears, that's the system asking for help. Stop filming immediately, do not plug in a power bank to charge at that moment, and move the phone somewhere cool (but not the fridge — condensation from the temperature swing can damage internals).

3. Check battery health: Settings → Battery → Battery Health & Charging. If it's below 80%, peak performance has degraded and extreme conditions will trigger these protections more easily — consider a battery replacement.

4. Hot-weather habits: for long shoots in the sun, remove a thick case to help cooling, lower screen brightness, and let the phone rest and cool down when needed.

📄 Crash log（關鍵段落 · 已遮蔽）

以下是這次 panic 的關鍵段落（panic header + panicString）。為了隱私，已遮蔽 incident_id、incident、crashReporterKey 以及所有 UUID（Kernel / Boot session / TXM / SPTM / Kernelcache / kext UUID）。後面上萬行的 thread dump 與本次原因無關，已省略。

Below is the key section of the panic (panic header + panicString). For privacy, incident_id, incident, crashReporterKey and every UUID (Kernel / Boot session / TXM / SPTM / Kernelcache / kext UUIDs) have been redacted. The tens of thousands of lines of thread dump that follow are unrelated to the cause and have been omitted.

{"bug_type":"210","timestamp":"2026-06-22 12:00:20.00 +0800","os_version":"iPhone OS 26.5 (23F77)","roots_installed":0,"incident_id":"████████-████-████-████-████████████"}
{
  "crashReporterKey" : "████████████████████████████████████████",
  "panicProcessingFlags" : "0x0",
  "product" : "iPhone15,5",
  "kernel" : "Darwin Kernel Version 25.5.0: Thu Apr 23 20:41:30 PDT 2026; root:xnu-12377.122.4~1/RELEASE_ARM64_T8120",
  "socRevision" : "11",
  "panicString" : "panic(cpu 0 caller 0xfffffff0355707b8): watchdog timeout: no checkins from watchdogd in 95 seconds (167 totalcheckins since monitoring last enabled), shutdown in progress, vfs shutdown not yet started
Debugger message: panic
Memory ID: 0xff
OS release type: User
OS version: 23F77
Kernel version: Darwin Kernel Version 25.5.0: Thu Apr 23 20:41:30 PDT 2026; root:xnu-12377.122.4~1/RELEASE_ARM64_T8120
Fileset Kernelcache UUID: ████████████████████████████████
Kernel UUID: ████████-████-████-████-████████████
Boot session UUID: ████████-████-████-████-████████████
iBoot version: mBoot-18000.120.36
iBoot Stage 2 version: 
secure boot?: YES
roots installed: 0
Paniclog version: 15
Debug Header address: 0xfffffff014401000
Debug Header entry count: 3
TXM load address: 0xfffffff024368000
TXM UUID: ████████-████-████-████-████████████
Debug Header kernelcache load address: 0xfffffff034368000
Debug Header kernelcache UUID: ████████-████-████-████-████████████
SPTM load address: 0xfffffff014368000
SPTM UUID: ████████-████-████-████-████████████
KernelCache slide: 0x000000002d364000
KernelCache base:  0xfffffff034368000
Kernel slide:      0x000000002d36c000
Kernel text base:  0xfffffff034370000
Kernel text exec slide: 0x0000000030250000
Kernel text exec base:  0xfffffff037254000
mach_absolute_time: 0x18c341d7e637
Epoch Time:        sec       usec
  Boot    : 0x6a1fc081 0x000c1bec
  Sleep   : 0x6a38ac54 0x000bf28b
  Wake    : 0x6a38ac5c 0x000f24ae
  Calendar: 0x6a38b33b 0x000f0168

CORE 0 [EACC0] recently retired instr at 0xfffffff037408a84
CORE 1 [EACC0] recently retired instr at 0xfffffff037409f9c
CORE 2 [EACC0] recently retired instr at 0xfffffff037409f9c
CORE 3 [EACC0] recently retired instr at 0xfffffff037409f9c
CORE 4 [PACC1] recently retired instr at 0xfffffff037409f9c
CORE 5 [PACC1] recently retired instr at 0xfffffff037409f9c
CORE 0 is the one that panicked. Check the full backtrace for details.
Panicked task 0xffffffe09e08aba0: 0 pages, 556 threads: pid 0: kernel_task
Panicked thread: 0xffffffe4356c54b0, backtrace: 0xffffffec5f5eb750, tid: 403
		  lr: 0xfffffff0355707b8  fp: 0xffffffec5f5ebed0
		  lr: 0xfffffff0355705d4  fp: 0xffffffec5f5ebf10
		  lr: 0xfffffff03556db60  fp: 0xffffffec5f5ebf30
		  lr: 0xfffffff035dec76c  fp: 0xffffffec5f5ebfc0
      Kernel Extensions in backtrace:
         com.apple.driver.AppleInterruptControllerV2(1.0d1)[████████-████-████-████-████████████]@0xfffffff035deae30->0xfffffff035ded52f
            dependency: com.apple.driver.AppleARMPlatform(1.0.2)[████████-████-████-████-████████████]@0xfffffff03551abf0->0xfffffff03556c4bf
         com.apple.driver.AppleARMWatchdogTimer(1.0)[████████-████-████-████-████████████]@0xfffffff03556c4c0->0xfffffff03557183f
            dependency: com.apple.driver.AppleARMPlatform(1.0.2)[████████-████-████-████-████████████]@0xfffffff03551abf0->0xfffffff03556c4bf

last started kext at 422993057: com.apple.driver.AppleIDAMInterface	1 (addr 0xfffffff0347f80d0, size 3279)
loaded kexts: (skipped, see boot kernelcache)
",
  "socId" : "8120",
  "date" : "2026-06-22 12:00:20.19 +0800",
  "panicFlags" : "0x802",
  "codeSigningMonitor" : 2,
  "incident" : "████████-████-████-████-████████████",
  "build" : "iPhone OS 26.5 (23F77)",
  "bug_type" : "210",
  "roots_installed" : 0,
  "trmStatus" : 1,
  "memoryStatus" : { "memoryPressure" : false, "compressions" : 121449978, "pageSize" : 16384 },

  ... (processByPid 完整 thread dump 共上萬行，與本次原因無關，此處省略 / full thread dump omitted) ...
}

iPhone 15 烈日下錄影黑屏重開：一份 Kernel Panic 的解讀

iPhone 15 Black-Screen Reboot While Filming in the Sun: Reading a Kernel Panic

📌 一句話結論

📌 TL;DR

☀️ 當時的情境

☀️ The Situation

🔍 這份 log 在說什麼

① bug_type 210 = Kernel Panic

② 關鍵那一行：watchdog timeout

③ 是誰按下重開鍵：AppleARMWatchdogTimer

🔍 What the Log Actually Says

① bug_type 210 = Kernel Panic

② The key line: watchdog timeout

③ Who hit the reset: AppleARMWatchdogTimer

🌡️ 為什麼會發生（三個層面）

主因：高溫錄影把硬體逼到極限

幾乎可排除：app 開發

推波助瀾：兩年多的電池老化

🌡️ Why It Happened (Three Layers)

Main cause: heat pushing hardware to its limit

Nearly ruled out: app development

Contributing factor: a 2-year-old battery

🛠️ 該怎麼處理

✅ 四個建議

🛠️ What To Do

✅ Four suggestions

📄 Crash log（關鍵段落 · 已遮蔽）

📄 Crash Log (Key Section · Redacted)