• 1 Vote(s) - 2 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Workaround for machines that experience long delays
#35
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:
  • 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.
So, anytime I need reliability before a gig, I proactively restart MSP via the Task View.  I've gotten so used to this workaround that I kinda forgot about troubleshooting the underlying issue -- sorry folks!

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.
Reply


Messages In This Thread
RE: Workaround for machines that experience long delays - by Richard Berg - 08-17-2019, 05:53 PM

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


Users browsing this thread:
1 Guest(s)


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2019 MyBB Group.