[Vineeth Thomas Alex (vineeththomasalex)]

What

Adds a bounded retry (5s budget, 50ms poll interval) around OpenEventW in the two PackageManager
test apps (PackageManager.Test.M.Black.msix, PackageManager.Test.M.Blacker.msix) before falling
back to the existing failure behavior (RETURN_LAST_ERROR_IF_NULL, immediate exit).

Why

Follow-up to the investigation into the residual PackageDeploymentManagerTests_IsPackageRegistrationPending
failures (IsPackageRegistrationPending_Pending / IsPackageRegistrationPendingForUser_Pending),
which fail deterministically on every CI config where InteractiveExperiences is built from source
in the monobuild (they pass on stub IXP builds).

Exhaustive local investigation ruled out every code-level and timing-level hypothesis:

• The raw PackageManagement_IsPackageRegistrationPending FrameworkUdk export — correct in both
  stub and source-built DLL variants (direct P/Invoke, single-call and same-process-ordering tests).
• The compiled Microsoft.WindowsAppRuntime.dll WinRT wrapper — correct (direct
  DllGetActivationFactory harness, both DLL variants).
• A timing race between ActivateApplication and the deferred install — correct with zero
  artificial delay, tested via both PowerShell and a fully-native C++ harness replicating the real
  test's exact call sequence.
• PackageDeploymentManagerTests_Register's ClassSetup cascade polluting this class — ruled out:
  the failure occurs on Windows.10.Enterprise.LTSC.2021 (a config with zero _Register
  cascade failures), and _IsPackageRegistrationPending's tests run and complete before any
  _Register test starts.
• The real, completely unmodified TAEF test itself — built the actual PackageManagerTests.dll
  • its full dependency chain (Framework/DataStore/LifetimeManager/Singleton MSIX packages) from
    source and ran it via real te.exe on an IXPTools VM. Passed 4/4 consecutive runs, zero
    modifications to any test file.

The one concrete fragility found: this app's WinMain parses its activation argument as an event
name and calls OpenEventW exactly once. If that ever transiently fails to see the caller's
CreateEventW-created event (e.g. a broker/activation-scheduling timing variance specific to some
CI execution contexts, not reproduced in this investigation's VM), the app exits almost instantly
instead of holding the package "in use" — producing exactly the observed symptom: no exception, no
error, IsPackageRegistrationPending() correctly (from the OS's perspective) reports nothing
pending because the deferred upgrade already silently completed.

Honest scope of this change

This is defensive hardening for an identified robustness gap, not a proven fix for a fully
confirmed root cause. The CI-specific trigger mechanism could not be force-reproduced locally
despite exhausting every constructible hypothesis. If a CI run with this change still fails the
same way, that's meaningful evidence the real cause lies elsewhere (e.g. a CloudTest-infrastructure
scheduling/session issue outside this app's control) — this change should still stand on its own
merits as a legitimate improvement to test-app robustness.

Test-infrastructure only

Only the two MSIX test app winmain.cpp files change (identical diff in both, 15 lines added each).
No product code changes.

Local verification

• Rebuilt both hardened MSIX packages — compiles cleanly.
• Ran the full PackageDeploymentManagerTests_IsPackageRegistrationPending class (8 methods,
  including both _Pending variants) via real te.exe against the real, unmodified test binary and
  real MSIX/Framework/Bootstrap infrastructure on an IXPTools VM: 8/8 Passed, 0 Failed, no
  regression from the added retry loop in the already-passing case.

Separate from #6693 (the cascading ERROR_PACKAGES_IN_USE fix, out of scope here per that PR's own
"no need to fix it in this PR" guidance for these residual tests).

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Vineeth Thomas Alex (vineeththomasalex)]

Combined-fix CI validation (this hardening + #6693 cascade fix) — real pipeline, real source-built IXP

Validated this hardening together with #6693''s cascade fix via the monobuild''s targeted rebuild-stage
mechanism (see #6693 for the full mechanism writeup), which lets Foundation be rebuilt from a topic
branch against real, already-source-built InteractiveExperiences (LiftedIXP/FrameworkUdk) artifacts
without triggering a full monobuild.

Producer: build 155179455 — Foundation rebuilt from user/vithoma/combined-cascade-fix-and-hardening (this branch merged with #6693''s).

Test-Foundation: build 155187907 (def 192441).

Result: 228 → 14 total individual test failures across all 12 configs — identical to #6693''s
standalone validation, confirming this hardening introduces no regression when combined with the
cascade fix. All 14 remaining failures are the pre-existing, known IsPackageRegistrationPending_Pending
/ ...ForUser_Pending product-behavior issue (explicitly out of scope for the original task). Zero
0x80073D02 / Register::ClassSetup failures anywhere.

To be clear about what this hardening is and isn''t: this change addresses the most concrete candidate
mechanism found during an exhaustive local-VM investigation into those 2 residual _Pending failures
(a non-retrying OpenEventW in the test app''s winmain.cpp), but that CI-specific trigger was never
force-reproduced locally despite building and running every layer (raw FrameworkUdk export, compiled
WinRT wrapper, native harness replicating the real test''s call sequence, and finally the actual
unmodified TAEF test binary end-to-end) — all passed reliably on a local VM. This PR is defensive
hardening, not a proven fix for the _Pending issue; see the linked investigation tracking for full
detail if useful context for future work on that separate, real, known issue.

[Vineeth Thomas Alex (vineeththomasalex)]

Closing this in favor of #6693, which now contains both this hardening commit and the cascade fix as a single consolidated PR/branch (merged user/vithoma/harden-pkgmgr-test-app-event-wait into user/vithoma/fix-packagedeploymentmanager-test-isolation, pushed as commit 2569dde). All validation results (local VM, Foundation-PR CI, and the real Test-Foundation rebuild-stage CI run showing 228 to 14) are documented there.