08-17-2019, 05:53 PM
(This post was last modified: 08-17-2019, 05:57 PM by Richard Berg.)
Rod: I have the Surface Pro 5 (2017 model) with i5-7300U and 8GB.
I'm still convinced it has to do with the UWP suspend/resume cycle. I know the special build with logging in the OnActivated / OnLeavingBackground handlers didn't shed any light, nor did the debug trace, but I've done more extensive testing since then. For me, freezing is 100% correlated with Windows force-suspending the MSP app.
In the past, I would let MSP run for days or weeks at a time, only restarting when it crashed. This made the freeze behavior seem more random. Now that I'm in the habit of restarting MSP frequently, I can confirm:
I will say that the severity of the freezes has gotten better in recent builds. Usually more like 5-10sec now instead of the 30-40+ seen in the video linked earlier.
By chance do you use Extended Execution? I remember thinking that this warning in the docs sounded similar (though not identical) to the freeze behavior:
https://docs.microsoft.com/en-gb/windows...ta-locally
Extended Execution would also explain why MSP does not enter the Suspended state when minimized (prior to forceful suspend, at least).
Note: I'm not completely sure what the doc means by "new" instance here. When a UWP app is rehydrated, it retains the same PID; its kernel resources may or may not have been reclaimed while it was suspended, depending what else the OS was up to, but the app shouldn't be able to tell the difference.
I'm still convinced it has to do with the UWP suspend/resume cycle. I know the special build with logging in the OnActivated / OnLeavingBackground handlers didn't shed any light, nor did the debug trace, but I've done more extensive testing since then. For me, freezing is 100% correlated with Windows force-suspending the MSP app.
In the past, I would let MSP run for days or weeks at a time, only restarting when it crashed. This made the freeze behavior seem more random. Now that I'm in the habit of restarting MSP frequently, I can confirm:
- It ONLY repros after I've hibernated the machine (or used the PLMDebug utility to force it). Once this happens, MSP will continue to freeze every time it's minimized or loses focus -- not just on sleep -- until I quit the app. I can reliably predict when the bad behavior will resurface by checking whether Task Manager shows MSP as Suspended.
- However, when the app is freshly started (current PID has never been suspended), I can freely switch to/from other apps and come back to MSP without finding it's frozen. Similarly, I can see in Task Manager that Windows has not put MSP in the Suspended state, despite being minimized.
I will say that the severity of the freezes has gotten better in recent builds. Usually more like 5-10sec now instead of the 30-40+ seen in the video linked earlier.
By chance do you use Extended Execution? I remember thinking that this warning in the docs sounded similar (though not identical) to the freeze behavior:
Quote:If an extended execution session is requested while in the [b]Suspending[/b] state, and the user requests the app be launched again, it may appear to take a long time to launch. This is because the extended execution session time period must complete before the old instance of the app can be closed and a new instance of the app can be launched.
https://docs.microsoft.com/en-gb/windows...ta-locally
Extended Execution would also explain why MSP does not enter the Suspended state when minimized (prior to forceful suspend, at least).
Note: I'm not completely sure what the doc means by "new" instance here. When a UWP app is rehydrated, it retains the same PID; its kernel resources may or may not have been reclaimed while it was suspended, depending what else the OS was up to, but the app shouldn't be able to tell the difference.