Fix NullReferenceException when launching UWP apps (e.g. Codex) via PowerToys Run

[Copilot]

Summary of the Pull Request

MethodBase.GetCurrentMethod() returns null inside compiler-generated closures under .NET 9+ JIT inlining. In UWPApplication.Launch, the catch block called .DeclaringType on that potentially-null return value, producing a NullReferenceException whenever a UWP app failed to activate — masking the real activation error and preventing the error dialog from appearing.

PR Checklist

• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end-user-facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Root cause: Inside Task.Run(() => { ... }), the JIT can inline the closure method. When that happens, MethodBase.GetCurrentMethod() returns null, and .DeclaringType throws. The compiler-generated class visible in the stack trace (<>c__DisplayClass64_0) is precisely this closure.

Fix: Capture the type before entering the lambda so the closure holds a reliable reference:

// Before
await Task.Run(() =>
{
    catch (Exception ex)
    {
        ProgramLogger.Exception(..., MethodBase.GetCurrentMethod().DeclaringType, ...);
    }
});

// After
var type = GetType();
await Task.Run(() =>
{
    catch (Exception ex)
    {
        ProgramLogger.Exception(..., type, ...);
    }
});

GetType() on this always resolves correctly regardless of JIT inlining. The remaining uses of MethodBase.GetCurrentMethod() in this file are in ordinary (non-lambda) methods and are unaffected.

Validation Steps Performed

• Code review: no issues flagged.
• Confirmed the only lambda-context use of MethodBase.GetCurrentMethod() in UWPApplication.cs is the one fixed here; all other call sites are in regular methods.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• o3svsblobprodcus318.vsblob.vsassets.io
  • Triggering command: /usr/bin/dotnet dotnet build (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)