[0.66+] App freeze on UWP resume after 5 min of suspension

[Chris-Guy]

Problem Description

Hello,

After the upgrade from 0.64 to 0.70 of the PowerApps Windows app, Windows 10 devices would experience a freeze for the application during several minutes or hours on UWP resume. It does not reproduce on the latest Windows 11 version, even if it looks like old versions of W11 might have it (to be checked)
See video (MSFT internals only) for a simple Power App: demo- At the beginning, I minimize the UWP app for suspension

• At 5:34, I resume the app. You can see that the UI is not responsive to the windows, and no button is working. Double clicking anywhere on the app expand it.
• At 9:55, the app finally come back from the freeze.

Remark: PowerApps production version has reverted the upgrade since then to 0.64, but we have some features relying on this new version. Also, the master branch is now forked due to that, reducing our release velocity there.

I am trying to get a minimal reproduction, but currently I cannot build the react-native-gallery app, so looking at fixing my issues there.

Steps To Reproduce

1. Get the latest version of the Power Apps Windows app (from App Center)
2. Open a Power App (which leverages a react-native full window control)
3. Minimize the app to go to suspension
4. Expand and resume the app after 5 minutes

Expected Results

No app freeze

CLI version

9.2.1

Environment

System:
    OS: Windows 10 10.0.19045
    CPU: (12) x64 Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
    Memory: 18.78 GB / 31.92 GB
  Binaries:
    Node: 14.21.2 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
    npm: 6.14.17 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK: Not Found
    Windows SDK:
      AllowDevelopmentWithoutDevLicense: Enabled
      Versions: 10.0.17134.0, 10.0.17763.0, 10.0.18362.0, 10.0.19041.0, 10.0.20348.0, 10.0.22000.0, 10.0.22621.0
  IDEs:
    Android Studio: Not Found
    Visual Studio: 17.4.33205.214 (Visual Studio Enterprise 2022), 16.11.33130.400 (Visual Studio Enterprise 2019)
  Languages:
    Java: Not Found
  npmPackages:
    @react-native-community/cli: 9.2.1 => 9.2.1
    react: 18.1.0 => 18.1.0
    react-native: 0.70.5 => 0.70.5
    react-native-windows: 0.70.4 => 0.70.4
  npmGlobalPackages:
    *react-native*: Not Found

Target Platform Version

10.0.19041

Target Device(s)

Desktop

Visual Studio Version

Visual Studio 2022

Build Configuration

DebugBundle

Snack, code example, screenshot, or link to a repository

No response

[chrisglein]

In your repro video it looks like you've got a yellow box warning and some redux tools running. So this is a debug build (as you say, DebugBundle)... does it show the exact same behavior in release builds? Same timing and such?

Have you broken into the debugger on this to see if there is any odd behavior on the main thread or others? For those 5 minutes, what are the main threads doing?

FWIW it looks like you're using VS2022 on version 0.70. That's only officially supported in 0.71+ (currently in preview). Probably not the issue here, but just an FYI.

It's a huge jump from 0.64 to 0.70 so it's hard to narrow down what could have happened between there (multiple years of releases). Some debugging information from your end may help narrow this down.

[Chris-Guy]

Hello, the issue was first raised by a customer with the app from the Microsoft Store, so it happens also in release builds with the same timing.

So, due to the Sev 0 on Windows my VS setup is all messed up (I am trying to repair it). I am currently trying to get as much information as possible and also a minimum repro in parallel, I'll get back to you on that.

We are using a mono repo with multiple RN apps and libraries, that is why it is not easy for us to do the upgrade, and due to that we generally perform big jumps.

I was wondering if you had any verbose logging parameter so that we can see what RNW is potentially doing during this freeze?

[Chris-Guy]

I had some time today:

• when attaching the native debugger during the freeze, it will actually "unblock" the freezing, resulting in the app working again :/
• when debugging only the Managed code, the main thread is in "External Code" (which probably means the native code).

I tried to repro on a C#-based RNW 0.70 app, effectively I don't manage to get the same issue.
Right now we are trying to downgrade RNW to close previous versions that wouldn't have this issue (0.69, 0.68, etc.), but it is tedious and requires some time for us. I'll keep you in touch!

[chrisglein]

when attaching the native debugger during the freeze, it will actually "unblock" the freezing, resulting in the app working again :/

Can you have it attached from the beginning so that you can break in at the time of the freeze rather than attaching? (disrupting the state less)

Right now we are trying to downgrade RNW to close previous versions that wouldn't have this issue (0.69, 0.68, etc.), but it is tedious and requires some time for us.

Yeah, that does sound tedious. If it does narrow down to a specific version that may help though. Let us know.

[Chris-Guy]

Can you have it attached from the beginning so that you can break in at the time of the freeze rather than attaching? (disrupting the state less)

No, probably because it might be related to UWP lifecycle events (Suspension event with debugger attached is not a real suspension).

I was able to pinpoint the regression from 0.65.14 to 0.66.25 update. I am trying to track down the commits (0.66.0 still has the issue). Do you have any idea of possible changes from this version range?