Files
Sylpheed/docs/re/captures/title-loader-thread-never-runs.log
Sylpheed RE agent 8b290d7012 tools+docs: the title's loader thread is created and never runs
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.
2026-08-19 10:19:06 +00:00

34 lines
1.9 KiB
Plaintext

d> F8000008 XamInputGetKeystrokeEx(701CF854(00000000), 00000003, 701CF898)
d> F8000008 XamInputGetCapabilities(00000001, 00000001, 828F38E8)
d> F8000008 XamInputGetCapabilities(00000002, 00000001, 828F3938)
d> F8000008 XamInputGetCapabilities(00000003, 00000001, 828F3988)
d> F8000070 KeReleaseSemaphore(828A3230, 00000001, 00000001, 00000000)
d> F8000008 XamUserGetXUID(00000000, 00000007, 828F40B8(0000000000000000))
d> F8000008 XamUserGetXUID(00000000, 00000007, 701CECF0(000000003F800000))
d> F8000008 NtCreateEvent(701CED80(701CEDE0), 00000000, 00000000, 00000000)
d> F8000008 Added handle:F80000B4 for N2xe6kernel7XObjectE
d> F8000008 ExCreateThread(701CEDC0(701CEE50), 00000000, 00000000, 824AFF88, 821748F0, BC369B20, 00000001)
d> F8000008 ExCreateThread Active: Thread Initially Suspended,
d> F8000008 Added handle:F80000CC for N2xe6kernel7XObjectE
i> F8000008 XThreadF80000CC (1F) Stack: 70880000-70900000
d> F8000008 NtResumeThread(F80000CC, 701CEE40(00000000))
d> F8000084 MmGetPhysicalAddress(BE07BE00)
d> F8000084 MmGetPhysicalAddress(BE07DD00)
d> F8000084 MmGetPhysicalAddress(FFCA9080)
A> F8000084 XmaContext: reset context 2
d> F8000070 KeReleaseSemaphore(828A3230, 00000001, 00000001, 00000000)
...
d> F8000090 Added handle:F80000CC for N2xe6kernel7XObjectE
d> F8000090 NtDuplicateObject(F80000CC, BC65D2C0(00000000), 00000002)
d> F8000008 NtClose(F80000CC)
d> F8000008 Removed handle:F80000CC for N2xe6kernel6XEventE
d> F8000084 Added handle:F80000CC for N2xe6kernel6XEventE
d> F8000084 NtClose(F80000CC)
d> F8000084 Removed handle:F80000CC for N2xe6kernel6XEventE
d> F8000084 Added handle:F80000CC for N2xe6kernel6XEventE
d> F8000084 NtClose(F80000CC)
d> F8000084 Removed handle:F80000CC for N2xe6kernel6XEventE
d> F8000008 Added handle:F80000CC for N2xe6kernel7XObjectE
i> F8000008 XThreadF80000CC (1F) Stack: 70880000-70900000
d> F8000008 NtResumeThread(F80000CC, 701CEE40(00000000))