[Feature]: Improve Error Messages for Startup Failures

[RickStrahl]

Describe the feature/enhancement you need

I'm running into a lot of problems UnauthorizedException on WebView startup. I know what the problem is - most likely the environment folder is ending up somewhere it shouldn't and doesn't have permissions to write. My app provides an explicit path in %localappdata% which in theory should always work but there are a lot of places where a WebView is instantiated including some places that are out of the base application's scope (add-ins).

The problem is that it's impossible to get any useful information about the failure. My app creates 15 different WebView instances internally at various times throughout the application cycle, some of them coming from external addins. I've gone through and tried as much as possible to homogenize the CreateAsync() call that provides the browser environment with all of them using the same startup path and structure, but still I see these errors.

When they show up they come in like this:

There's no call stack and the UnAuthorizedException has no further information.

The scenario/use case where you would use this feature

My request is to have this exception report more information - specifically the path and actual cause would be useful here (I'm not 100% sure it's the environment path but that would be my guess).

How important is this request to you?

Impactful, but not critical.

Suggested implementation

Provide an exception wrapper around the internal CreateAsync() calls and provide more context in the exception message/data or a custom exception.

Other

FWIW, it's not just this exception but also invalid command line parameters passed into the environment that could benefit from this. Some context about instantiation would benefit any WebView creation errors!

What does your app do? Is there a pending deadline for this request?

It's a commercial desktop application and these errors are 95% of all errors reported, although the number is relatively small (about 2-4 a day out of 1000 users a day). These errors do cause hard stop so although the failure rate is low it has a negative impact.

AB#46940915

[victorhuangwq]

Hi Rick, thanks for the feature request. We are tracking it in our backlog. Do note that does not mean any commitment that we will work on it soon.

In the meantime, can @vbryh-msft see if there's any current workarounds for it?

[RickStrahl]

Perhaps a related question:

What would you consider a safe directory on Windows for the WebView Environment folder, if not in LocalAppData?

For context, I'm currently using a private WebView environment folder in %localappdata%\Markdown Monster. I've gone through my code again today to double check and I see that all WV instances are using the same path to set the environment.

FWIW, I recently switched the folder from %appdata%\Markdown Monster to the %localappdata%\Markdown MOnster and there's been a huge uptick in failures now which doesn't make sense to me. Permissions should be identical. The reason for the change was to ensure that the WebView environment doesn't accidentally get shared via Windows profile or if the common folder is redirected to DropBox/OneDrive etc.

[vbryh-msft]

we have written doc page about user data folder - here It describes also how you can read the one from environment.

[RickStrahl]

Yup doing this already. Custom location is in %localappdata% which has the correct permissions, but still seeing these errors. A lot of them! Which is why it would be so useful to get more information in that exception about What actually causes the Unauthorized exception, and if it's file/folder access which file or folder caused it. That would help tremendously in tracking down these issues.

Wondering if some of the reason for these failures has to do with changes in the runtime. I had these problems some time ago, then they more or less went away, but now I'm seeing TONS of them with the latest runtime releases.

In my app 95% of critical errors I see are related to the WebView runtime UnauthorizedAccess exceptions.

[RickStrahl]

Here's another followup that's related to the exceptions I see:

Note this is different error which comes from the same CreateAsync() call that shows the same call stack as the above.

[vbryh-msft]

• Could you check if what you are observing looks similar to this issue?
• When you see UnauthorizedException creation failure - that means that you cannot create wv2 on that machine at all - or it is intermittent?
• Do you have a dump to check if there is smth else instead of user data folder permissions issue - it should not in theory, just want to double check?

[RickStrahl]

I'm not 100% sure where /when the error pops up. I've never run into it myself - it comes from my application logs so it's end users that are seeing this in a variety of environments.

I've added some additional error tracking to all of my WebView instantiations (which unfortunately there are quite a few of before I consolidated with a wrapper behavior class), which should provide more error detail if the errors are occurring from code that originates within my app and known addins of mine.

It's possible it comes from one of the third party (and my own) addins, and I'm checking mine now to make sure they are using the latest bits and/or wrapping the Ensure calls there as well.

I have a feeling this is the problem (add-in) as some of the errors are not occuring right at startup but after the app's been running for a while. Since I create many WebViews right on startup if the base controls fail the error would be immediate in the first few seconds of the app running. Some of the errors I see are 5-10 minutes or more in which seems to suggest either a special feature subwindow that I missed (unlikely at this point) or an add-in that doesn't load until activated later.

All that said means most likely that this is my fault for somewhere either not setting an environment path (which would fail due to app starting in Program Files without write permissions, or using a path that is not accessible that's not in local data (ie. some legacy configuration).

Would be nice

But as I said - it would be really useful to not have to do this all on the invocation end and rather have the exceptions that are thrown return some of that information. Some representation of the environment or key values thereof would be useful so we could track errors back to their source.