Repository navigation
Rebuild the HUD host after failed window calls instead of retiring it - #183
Merged
Merged
Conversation
A host-window Win32 call (CreateWindowEx, GetClientRect, ClientToScreen, MonitorFromWindow, GetMonitorInfo, SetWindowLongPtr or SetWindowPos) can fail while the game attaches or the player returns from another window. After four failures 500 ms apart the HUD window's native renderer was retired for the rest of the run: the failed flag was never cleared and HUD windows are created once, so that window stayed blank until Wisp was restarted. The failure report carried E_FAIL, which every Win32Exception reports, so neither the Win32 error nor the failing call was known. Host-window failures are now named at each call site and reported once per episode with HRESULT_FROM_WIN32 of the Win32 error code, in the breadcrumb and in the renderer status text. When an episode's retries run out, the host window and its renderer are released and built again on the next attach above the game (game start or foreground return), at most once per such event. Three consecutive exhausted episodes without a presented frame fall back to the previous permanent failure. The WPF artwork stays suppressed throughout, as before. Tests cover the retry, rebuild and retirement bounds, the failure details, and a live host that is released after four failed synchronizations and presents again through a new HWND after the next attach.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Microsoft Store builds, a host-window Win32 call failed at alt-tab return or game attach four times 500 ms apart, after which
HudNativeHostlatched_failedfor the rest of the run; nothing cleared it and the HUD window stayed blank until Wisp restarted. 3 PCs on 2.7.2 and 2.7.3. Every failure was reported as E_FAIL, so the failing call was unknown.Changes
HRESULT_FROM_WIN32(NativeErrorCode)and the failing call's name (NativeHostInteropException), and one breadcrumb is recorded per episode instead of one per failed call.HudNativeHostRecovery): when the retries run out, the host is released and rebuilt on the nextAttachAboveGame, once per attach, with a bound of three failed episodes before today's permanent failure. A presented frame resets the count. The WPF artwork stays suppressed while the native host is in use, as before.Tests:
HudNativeHostRecoveryTests(four failures then success recovers on the next attach; three episodes retire; failure details carry the Win32 code and call name) and an addition toHudNativeHostTests.Tools note: renderer-host incidents now arrive once per episode and with Win32-derived codes instead of 0x80004005.
Verification
dotnet format whitespace --verify-no-changesclean.Test-AppBehavior.ps1 -BaseRevision main) on that build: Core 780, Telemetry 96, Update 184, Updater 76 and App 1295 tests passed, 0 failed.