Since the release of one of my UWP apps, the top crash was hang_quiesce.
Clicking on this failure, I was in confronted by a sea of nothing. I.E. nothing meaningful from my app and all Windows code.
I did a little survey among other UWP developers and some of them also confessed that this crash was quite common. It is good practice to fix crashes because if you have a high number of crashes, it affects the search ranking in the Microsoft Store.
I reached out to my friends at Microsoft. Stefan Wick was kind enough to tell me the possible causes: the app is hung or it forgot to release the deferral. Also, Brandon Paddock suggested a solution to the deferral issue: add the notion of duration of the App.OnSuspending event to force quit the execution after X time.
Note: I don’t know exactly how long the OS gives to the deferral before it takes the execution as hanging. This is probably not a good idea to do tons of database operations for example.
My simple solution was to introduce a delay task of 2 seconds and used Task.WhenAny to make sure that that either the Delay or Suspend method finishes before 2 seconds. For my app, it is not crucial if the Suspend method does not finish.
After one month, I was pleased to see this crash at 1.44% instead of 22%!
I don’t guarantee that your “hang_quiesce” issue will be the same as mine, but it is definitely worth a try.
Update: There has been a bit of misunderstanding on how this works. The broadFileSystemAccess is a restricted capability that an application could be granted, it is not an API. As a developer as well, I have to opt-in to using the capability. Any application in the store with the capability goes through extra verification by the Store team before any user gets it and the user is aware they are granting the application the permission to use the capability as well.
Users of the application can turn off this ability at any time via their Privacy settings, a dev should check that it has the permission to access files since a user can turn on / off as shown on my screenshot below.
While reporting this to Microsoft, we discovered there was a documentation bug here as well. As every developer knows, this is something that does happen and they are proactively fixing it.
Recently, I learned that an UWP app can access the entire file system i.e. the app is not restricted to use the LocalStorage or files and folders via a Picker. You can find all the info from MSDN.
The moment that I implemented the feature, it was before the October 2018 Update. I noticed that the first time that I used an hardcoded file in “C:\myAppData”, I didn’t get any message and it just worked despite that MSDN said: “On first use, the system will prompt the user to allow access”. The app is a LOB app in an environment controlled by my client outside the MS store, so I was even more glad that the app does not ask any questions until the October 2018 Update arrived…
After I installed the October 2018 Update, I realized that my app was crashing at startup. I found out that accessing my file above was crashing the app. I thought that the manifest was altered, but no. I contacted my friends at Microsoft and they confirmed me two important info:
1- The Windows dialog that is supposed to be shown the first time a file is accessed does not trigger is a *bug*.
2- Because it is a privacy issue, Microsoft decided with the October 2018 Update to set to OFF the value of the broad access file system.
I actually learned that the list of applications that can have access to the file system resides in Windows Settings > Privacy > File system:
Fortunately, you can guide the user and force the display of this page settings with the following call:
When Microsoft released the Windows 10 April 2018 update, I installed it and I updated Visual Studio with the latest SDK. If you develop UWP apps where the min version is set to the latest Windows update (in this case Windows 10, version 1803, build 17134), you can stop reading here. However, if for example, the min version if the Fall Creators Update, please read on.
The other day, I was testing on my desktop machine the style that I modified of a simple TextBox. It was working well, until I deployed on my Dell Venue Pro 8. When I navigated to a page where I modified the TextBox, the app crashes every single time. I was wondering what was going on since Visual Studio didn’t warn me of anything.
If you add an TextBox and you click on “Edit Template”, the latest SDK will introduce the usage of the ThemeResource IsApplicationFocusVisualKindReveal. This resource does not exist in previous Windows 10 updates, so when the app runs on previous version, the app will crash.
What is worrisome is Visual Studio does not warn about anything (no warning message and no wiggle underline under the resource name).
I wrote an email to my XAML friends at Microsoft and they acknowledged what I found. They were actually surprised by that too. I will report back when they will find the solution for it.
In the meantime, I highly suggest that if you do an Edit Template with the April 10 SDK, go ahead and try in all of your supported Windows 10 updates.
Happy testing
PS: it’s been quite a long time from my previous blog. Having kids and a new passion (Magic the Gathering competition) took a lot of my free time. I still work full time on UWP projects for years and I enjoy this more than ever!
