Fix Windows launch crash since v0.5: noexcept LocateFile (issue #58)

[JRickey]

Summary

• Replace Ship::Context::LocateFileAcrossAppDirs at the three port call sites with a port-side PortLocateFile that uses the noexcept std::filesystem::exists(p, ec) overload — fixes immediate-launch crash on Windows reproduced across Win10 19042 (Immediately Crashing on v0.5 (Windows) #58, Girtana1), Win10 22H2 (Immediately Crashing on v0.5 (Windows) #58 comment, DanKorell), and Win11 (today's report).
• Decode MSVC C++ throws (0xE06D7363) in the vectored handler so future bugs of this shape print a readable type name + what() instead of an opaque exception code.

Diagnosis

User crash logs (Win11, today) show a first-chance 0xC0000374 (STATUS_HEAP_CORRUPTION) immediately after the SSB64: locating f3d.o2r ... checkpoint, with the second-chance arriving as a 0xE06D7363 MSVC C++ throw. The only code between the checkpoint and the crash is Ship::Context::LocateFileAcrossAppDirs("f3d.o2r"), which uses the throwing overload of std::filesystem::exists.

Under NON_PORTABLE on Windows the first probed path is <%APPDATA%>\BattleShip\ (backslash-terminated from SDL_GetPrefPath) joined with a literal "/" — yielding mixed separators like C:\Users\u\AppData\Roaming\BattleShip\/f3d.o2r. On at least three different Windows builds, GetFileAttributesExW returns an error severe enough to throw filesystem_error, the unwind trips heap-corruption detection, and the process fast-fails before any user-level catch can run.

The fix:

1. PortLocateFile (new helper) uses exists(p, ec) — false is the right answer for any "does this file exist?" probing failure. It also probes the bundle directory via ssb64::RealAppBundlePath() (real exe dir on Windows portable-zip) instead of Ship::Context::GetAppBundlePath(), which under NON_PORTABLE returns the literal CMAKE_INSTALL_PREFIX ("BattleShip") and is wrong for the portable distribution. The same defensive shape is applied to the inline std::filesystem::exists on the BattleShip.o2r post-extract probe.

2. Vectored handler now decodes the MSVC C++ throw ABI for code 0xE06D7363 — primary CatchableType → std::type_info::name() and, for std::exception derivatives, what(). Logs cap at 8 per process. Still returns EXCEPTION_CONTINUE_SEARCH so SEH catch handlers run normally; this is purely diagnostic. what() decode is wrapped in __try/__except so the handler never triggers a secondary fault.

Backstory

This commit (42ad2d6) was authored on May 1 against #58 but was never opened as a PR — issue #58 was closed when the diagnostic-logging commit (edf1440) shipped in v0.5.2-beta, but the actual fix never landed. v0.5/0.6/0.7/0.7.1 all carry the same crash.

Test plan

• macOS Debug build green (cherry-picked onto main, all 688 TUs compile + link).
• Windows CI artifact boots without 0xC0000374.
• Reporters confirm the launch crash is gone (Girtana1, DanKorell, today's reporter).
• If the fix doesn't fully resolve it, the new C++ throw decoder in the vectored handler should log a precise next-step diagnosis on the next crash.

🤖 Generated with Claude Code