So that if the service breaks on a machine where nobody enabled logging first
(e.g. a Win7 tester), we still learn WHY:
- New always-on ServiceStore.AppendServiceEvent -> service-events.log in
ProgramData, independent of any logging toggle (like the update log).
- Service menu status-query failure now shows the actual reason IN the status
line (a screen reader reads it) AND records it to the events log, instead of a
bare 'status unavailable' whose reason only went to the off-by-default app log.
- ServiceAction (install/uninstall/start/stop) records request + outcome to the
events log.
- ServiceEntry (the elevated child) logs each verb's start, and CATCHES a
System.ServiceProcess load failure to record its reason before rethrowing (so
the crash file still gets the full stack) — this is the likely Win7 failure.
- 'View service log' falls back to the events log when no runtime diagnostic log
exists, so there's always something to view after any service interaction.
Recap of coverage: hard crashes -> crash-*.txt (always, no setup). Graceful
service failures -> now the events log + on-screen reason (no setup). Gate 35/35.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
EdnunpandClaude Opus 4.8
5129aa2a39