Windows.Storage.ApplicationData is unreliable for packaged Win32 applications

[sylveon]

Windows.Storage.ApplicationData is extremely trivial to break.

One can simply open the non-Store version of Inkscape or GIMP and then try to run a packaged app which makes use of Windows.Storage.ApplicationData.Current.RoamingFolder.Path (or one of the other folders). The app will fail to use this API, getting an invalid parameter HRESULT or the appropriate language exception (but what parameter? there's no parameter to give to this API!)

The IRestrictedErrorInfo is not useful either, it just says "Error trying to initialize application data storage folder" and a stack trace pointing to OS internals:

Two current apps on the Store which exhibit this behavior are Spotify (which crashes on startup) and my own TranslucentTB (which provides an error message and then calls RaiseFailFastException on startup)

I've received multiple bug reports both privately and publicly about this, including one issue on GitHub TranslucentTB/TranslucentTB#268. I was never able to root cause the problem for that user (or any other user for that matter), but I've later encountered the same issue by trying to debug my app while I had Inkscape open to design SVG icons for the app.

I filled feedback on the Feedback Hub a while ago: https://aka.ms/AA8av7x

How are developers expected to make use of those APIs in packaged Win32 apps if they are easily broken by another running app on the system?

[ChrisGuzak]

for MS people this is this bug: https://microsoft.visualstudio.com/OS/_workitems/edit/26262772

[sylveon]

Not USB-related, I reproduced the issue with GIMP and Inkscape in a VM where there's obviously no USB drive. USB could have been the original user's problem, but the fact so many external factors influence the reliability of this API is worrying.

[riverar]

+1

We just accepted Windows.Storage.* as completely unreliable and just catch all the exceptions, then failover to a backup storage mechanism (i.e. registry). We were working offline with WinRT Storage API devs re: high crash rates w/ Windows.Storage.ApplicationData.Current but the thread died in 2017. Happy to forward thread to ftes.

[smaillet-ms]

As @ChrisGuzak points out there is an internal bug for this, created based on the FedbackHub feedback (They really are read, and do get turned into bugs after investigations indicate a problem) This isn't a completely UWP related issue. The problem is that an underlying Win32 API can fail if a folder is opened with restrictions or exclusive access, which is what is happening here. (Basically any app running can open files or folders it is allowed to access in an exclusive mode [e.g. share mode = none ], this is sometimes a requirement for data files, but rarely ever required at the folder level for most apps.)

The engineering team is investigating options for how to avoid the error/continue functioning in this case.

@riverar please do forward me any email thread as my team should have been on such a conversation and I have no recollection of that.

[sylveon]

To add onto the pile of reliability issues: currently the #1 most impacting crash for my app on the store happens when I call a Windows.Storage.ApplicationData API.

It's caused by the system modification known as "old new explorer". For some reason it's loaded within my process, and when I call the ApplicationData APIs it manages to trigger an access violation, however COM catches it and handles it by brutally terminating my app with no chance for me to catch the SEH whatsoever.

Since retrieving the path where I store my config files is one of the first things done at startup, it leaves users with the impression that my app is buggy and doesn't even start, despite it being caused by a third party app.

At this point I am really considering just getting the local app data folder using SHGetKnownFolderPath and my package identity using the C API for it. Then concatenating those two into $APPDATA\Packages\$ID. I'm (rightfully) told I shouldn't do that but the alternative is not reliable. At all.

[stevewri]

@riverar were you able to forward the thread(s) that @smaillet-ms was asking for?

[riverar]

Hi @stevewri, I did. No response.

Rough timeline thus far:

• Email originally sent December 8, 2017 8:34:46 AM
• Last email response received December 15, 2017 12:57 AM
• Email forwarded July 13, 2020 10:30 AM

[sylveon]

Why has this been closed? The problem is not resolved.