4.3.36: Sharlayan 9.2.1, Screen Capture and App Control crash fixes, providers report start-up failures

[logicallysynced]

Covers v4.3.32 through v4.3.36 on top of the 4.3.31 release. Nine Sentry issues fixed across two triage rounds.

Sharlayan 9.2.1

The first stable release carrying the FFXIV 7.55 reader work: corrected inventory slot-array pointer reads with an FCS-derived item stride, chat-log index clamps for torn reads, hoisted hotbar chain resolution, direct status parsing, and bulk enmity and condition reads. No public API moved, so the upgrade is the package reference in both projects plus NLog moving to 6.2.0 to meet the new floor.

Screen Capture layer stopped working after the title screen (CHROMATICS-1D)

634 events across 2 users on 4.3.31.

GameController disposes the layer processors every time the player returns to the title or character-select screen, and disposal nulls each processor's cached surface. Every processor clears its _instance on dispose so the factory rebuilds it, except ScreenCaptureProcessor, whose instance was a static readonly field that could never be replaced. The factory handed the disposed object back for the rest of the session and Attach threw against the null surface on every tick. RGB.NET's Attach extension has no null guard and inlines, which is why the stack pointed at Process with no RGB.NET frame.

For the user that meant picking Screen Capture as the base layer, logging out to character select once, and losing lighting until restart. The processor now follows the same lazy-singleton pattern as its 33 siblings, and Process reads the surface once per tick so shutdown disposal on the UI thread cannot null it mid-tick.

Windows App Control crashes (CHROMATICS-1F/1G/1H/1K/1M/1N)

Six issues, three users, one cause: App Control blocks the unsigned RGB.NET assemblies by file, while the signed executable runs fine.

Two were real crashes, both from the JIT-load trap behind CHROMATICS-17 and 19. FirstRunDialog.OnContinue named LogitechDeviceProvider in the handler's own body, so the assembly resolved while the handler was being JIT-compiled - before any try inside it existed - and took the Continue button down. DeviceToggleItem starts its work fire-and-forget from a property setter, so a blocked DLL faulted a task nobody observed and the finalizer rethrew it. The probe now runs inside a guard lambda, and the toggle task catches, reports, and returns the toggle to its previous position.

The other four were the guard working correctly and reporting to Sentry anyway. App Control blocks now reach the console tab only, since they are the machine's policy rather than a fault here. Load failures from any other cause still report, because those could be a packaging mistake. Every toggle now gives the same guidance: the classification moved into AssemblyLoadGuard.TryReportLoadFailure, called from the toggle catch, so the hand-built toggles (Logitech, OpenRGB, Hue, LIFX and the rest) no longer show a raw loader message. It walks the exception chain, since the fault arrives wrapped in a TargetInvocationException from an event handler or an AggregateException from an unobserved task.

Providers report what went wrong

RGB.NET's Load initializes with throwExceptions: false, and its Throw() raises an event and returns rather than rethrowing. A provider whose native SDK was missing or refused to start reported success: the HID scan still listed the hardware, so devices appeared in the Mapping tab and never lit, with nothing in the console tab and nothing returned to the caller. This is what made a Logitech provider with no x64 natives look like a toggle that did nothing.

LoadProviderWithDiagnostics replaces the surface.Load call. It initializes with throwExceptions: true and attaches a probe that decides per exception: critical ones abort that provider and return to the caller, non-critical ones name the skipped device and let the load continue, matching what RGB.NET intends when one device of several fails to add. Everything is caught inside the helper, so a failing provider never stops the ones after it. A provider that loads and returns zero devices now says so too.

One visible change: with a genuinely dead SDK, devices no longer appear in the Mapping tab, because a critical failure resets the provider instead of leaving a half-initialized one. A listed device that cannot light is what sent us down this path.

Smaller fixes

• Lights that are switched off or off the network at startup (Yeelight, LIFX, Nanoleaf, Alienware) log as device notices instead of errors, through a shared NetworkFailureHelper. The Yeelight and LIFX discovery sweeps use the same classification, where a firewall blocking broadcast produced identical noise.
• A Hue bridge answering with HTML instead of JSON reports to the console tab only (CHROMATICS-1J). That address points at a router page, a captive portal, or a reassigned lease.
• The console tab names the running version at startup, so a pasted log identifies its build without being asked.
• The first-run wizard no longer saves a provider as enabled when App Control blocked its library.

Notes

• 192/192 xUnit tests pass, with 16 added across update-notes trimming, the unreachable classification, the processor-rebuild contract, toggle recovery, and the load-failure classifier.
• Reviewed twice with parallel finder agents, at 4.3.33 and again at 4.3.36. Both rounds' findings are fixed in dd0a0e15 and 445282b6 - among them the probe reporting working providers as failed, the first-run wizard persisting a blocked provider, and a changelog heading I dropped in 795bd238.
• Separately, publish.py now signs the six RGB.NET assemblies built from our own fork, on the same attestation as Sharlayan.dll. That should reduce App Control blocks over time as the signing identity earns reputation.

🤖 Generated with Claude Code