fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

tools+docs: the title's loader thread is created and never runs

Browse Source 
Two findings, the second only visible because of the first.

1. The harness has always had kernel logging switched off. log_mask DISABLES
   categories (Kernel=1, Apu=2, Cpu=4, Gpu=8), so the long-standing --log_mask=13
   meant Kernel+Cpu+Gpu off; kernel calls also log at Debug while log_level
   defaults to Info. Seeing one needs BOTH LOG_MASK=12 and LOG_LEVEL=3, and no
   boot log this project has taken ever contained a kernel call. boot_menu.sh now
   takes LOG_MASK / LOG_LEVEL / EXTRA_FLAGS. A whole boot at Debug with Kernel on
   is 23 MB, so the default was costing far more than it saved.

2. With that on, a captured failure shows the (A) handler doing everything right:

     XamUserGetXUID(0, 7, ...)
     NtCreateEvent(...)
     ExCreateThread(..., entry=821748F0, ..., 00000001)
     ExCreateThread Active: Thread Initially Suspended,
     XThreadF80000CC (1F) Stack: 70880000-70900000
     NtResumeThread(F80000CC, ...)

   and the thread then never executing. Measured two independent ways: it makes
   ZERO kernel calls - it appears 13 times in the log and every one is as an
   ARGUMENT, never as the calling thread, while five other threads make 31905
   calls after the resume - and its host thread has 00:00:00 CPU time while the
   process sits at 546% and has burned 37 minutes of CPU in 6:46 wall.

   A spinning thread burns CPU. This one has not run at all.

So the chain is: press delivered -> handler runs -> thread created suspended ->
resumed -> never scheduled. Input, the cache-flush crash and the game's own logic
are all excluded. A lost resume is a race, which is the first explanation that
fits the ~1-in-3 success rate.

Not settled: where the resume is lost, and no successful boot has been captured
with kernel logging to compare against.
This commit is contained in:
Sylpheed RE agent
2026-08-19 10:19:06 +00:00
parent 723022f15c
commit 24c1c940e6
4 changed files with 129 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/re/BACKLOG.md
View File

@@ -151,8 +151,19 @@ See [`structures/ui-composable-bundles.md`](structures/ui-composable-bundles.md)
ever**. So "the title ignores Ⓐ" is **withdrawn** — the loader stalls.
🔴 Refuted as the cause: the cache-flush crash. All four of today's runs have
**zero** `GUEST-THROW`, `CRASH DUMP` and `Access Violation`; the guest stays
alive and polling. **Next probe:** what the `(1F)` thread waits on — an event
or file-system trace on that thread, not input, not the crash.
alive and polling.
✅ **And now measured to the bottom:** with kernel logging finally on
(`LOG_MASK=12 LOG_LEVEL=3` — the scripts' `log_mask=13` had Kernel *disabled*,
which is why no boot log ever held a kernel call), a captured failure shows the
handler doing everything right — `XamUserGetXUID`, `NtCreateEvent`,
`ExCreateThread(entry=0x821748F0, CREATE_SUSPENDED)`, `NtResumeThread` — and
the thread then **never executing**: zero kernel calls of its own, and
**`00:00:00` host CPU time** while the process runs at 546 %. A spinning thread
burns CPU; this one never ran. A lost resume is a race, which is the first
explanation that fits the ~1-in-3 success rate.
**Next probe:** Xenia's `XThread` create/resume pair — can a resume land before
the host thread starts waiting? And capture one *successful* boot with kernel
logging, to say whether the guest sequence differs at all.
See [`canary-scripted-input-traps.md`](canary-scripted-input-traps.md).
* ❔ **Blend mode.** Everything is straight alpha-over. The near-white flash
quads (`0xf0ffffff`) and coloured ones (`0x60ff0000`) may be additive. The