Webview2 throws timeout Exception while initialization.

[ShaliniPVerma]

My webview2 initialization doesn't work for some group of users, But for some it works properly. It throws an timeout exception for some users.
Below is my code-

 public async Task InitializeAsync()
        {
            EnsureTemplate();
            Browser.NavigationStarting += Browser_NavigationStarting;
            Browser.NavigationCompleted += Browser_NavigationCompleted;
            Browser.PreviewKeyDown += Browser_PreviewKeyDown;
            Browser.CoreWebView2InitializationCompleted += Browser_CoreWebView2InitializationCompleted;
            var cachePath = WebUIConfigSection.Current.AbsoluteCachePath;
            var environment = await CoreWebView2Environment.CreateAsync(null, cachePath, null);
            await Browser.EnsureCoreWebView2Async(environment);
        }

Exception details-

Type: System.Runtime.InteropServices.COMException
Target site: Void ThrowExceptionForHRInternal(Int32, IntPtr)
Message: This operation returned because the timeout period expired. (HRESULT: 0x800705B4)
Source: mscorlib
Stacktrace:    vid System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
   vid Microsoft.Web.WebView2.Core.CoreWebView2Environment.<CreateCoreWebView2ControllerAsync>d__54.MoveNext()
   vid System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   vid System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   vid Microsoft.Web.WebView2.Wpf.WebView2.<>c__DisplayClass27_0.<<EnsureCoreWebView2Async>g__Init|0>d.MoveNext()

AB#38444651

[champnic]

Hey @ShaliniPVerma - do you have a sample app you can share that reproduces this issue? Is there anything distinctive (OS, arch, network, app usage, etc.) about the group of users that is seeing this vs. those that aren't?

[ShaliniPVerma]

Not able to reproduce this issue in our system, It is happening only for some clients on their system.

[champnic]

@ShaliniPVerma Do you know if WebView2's are being torn down and/or created quickly and might be interfering with each other?

You can try listening to the ProcessFailed event to see if this might be caused by a WebView2 process failure.

[ShaliniPVerma]

For further investigating the issue I created release folder on my system with 64 bit. And asked user to run the application through this release folder. And they are able to run it successfully. That means there is some problem with the installed version only.
We use Clickonce to create and deploy the application. I am not sure what could be the issue with the clickonce deployed version.

[champnic]

Hey @ShaliniPVerma - Hard to say exactly from your description, but it sounds like the app is having trouble using the installed WebView2? Could you provide some extra details:

1. SDK version
2. Runtime version of evergreen WebView2 (on the failing machine)
3. Framework type (WinUI? WPF? Win32?) and version
4. More details of what "created release folder with 64 bit" and "run the application through release folder" means

Thanks!

[rozeboosje]

This appears to have started happening to us as well now. What is REALLY upsetting is that this appears to have started happening for clients who have used versions of our software for months, and today this is happening for them in those same versions, without having changed anything in our software.

On my developer machine I discovered a timeout happening in
Await Microsoft.Web.WebView2.Core.CoreWebView2Environment.CreateAsync(browserExecutableFolder:=String.Empty, userDataFolder:=sUserDataFolder, options:=Nothing)

Where sUserDataFolder = system.io.path.gettemppath()

I changed this so it creates a new temp folder every time it's called
sUserDataFolder=System.IO.Path.Combine(System.IO.Path.GetTempPath(), System.DateTime.Now.Ticks.ToString())

and that appears to have eliminated this problem in my developer machine. But why is it only raising its head now?

[champnic]

Hey @rozeboosje - sorry to hear that this is affecting your users. What is the earliest date you have a report of this timeout, and what version of the runtime are they on? Is the timeout consistent for those that are seeing this? I've added this bug on our backlog.

[rozeboosje]

The earliest date I have of this timeout is today ... I am investigating the issue myself right now. On my developer machine I observed the timeout when I ran another program that did the same thing. So the "other program" is running completely independently of the IDE in which I observed the timeout. Adding the "ticks" to the temp path made the problem go away.

I checked my runtime (for Microsoft Edge WebView2 Runtime) and I am currently running 99.0.1150.36 - but the first time I noticed it, and I'm sorry I didn't take a note of it, it was an earlier runtime and I don't know the exact numbers but it ended in .30 - Microsoft Edge itself was already on 99.0.1150.36

[champnic]

Thanks for the info - It sounds like you run into this when running two apps simultaneously while using the same user data folder (and therefore the same browser processes)? If that's the case, does this happen when you start the apps in quick succession, starting one while closing the other, or starting one while the other has been running for a while?

[rozeboosje]

I did start the apps in succession, not "immediately" after each other but possibly within 10 seconds? The first app is a standalone application, the second one is an Outlook Add-in. The Browser is on a WPF dialog that we invoke from there so, rough estimate, I would try to look at something in the browser through the Outlook Add-in within 30 seconds or so from starting the standalone app? So the actions would be something like "start standalone app", "start Outlook", "use our add-in that shows a dialog with the browser".... all that within about 30 seconds

[ShaliniPVerma]

@champnic - Hi Thank you for your response.

In our future investigation, We found that the issue is only with the desktop shortcut (created by ClickOnce). The webview doesn't work if we open exe with the shortcut. But If we open it from the actual folder path, where it is installed on user's machine, It works fine.
Edge Runtime Version- 99.0.1150.36
It is a WPF Application. Version- .NET Framework 4.5.2
We use ClickOnce to deploy the application.

[ShaunLoganOracle]

@champnic
I have a customer reporting the same/similar exception during initialization:
Winforms
Windows 10
WV2 SDK 1.0.902.49
WV2 RT 100.0.1185.29
it is not feasible to provide a sample app

Is there any logging or other diagnostic information we can get from the WV2 as it tries to initialize itself that would provide some clue as to the cause?

Exception stack is:

Microsoft.Web.WebView2.WinForms.WebView2.InitCoreWebView2Async System.Runtime.InteropServices.COMException (0x800705B4): This operation returned because the timeout period expired.
 failed  (Exception from HRESULT: 0x800705B4)
   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
   at Microsoft.Web.WebView2.Core.CoreWebView2Environment.<CreateCoreWebView2ControllerAsync>d__41.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at Microsoft.Web.WebView2.WinForms.WebView2.<InitCoreWebView2Async>d__13.MoveNext()

[champnic]

When you hit this it's usually due to WebView2 initialization during another WebView2's teardown. There's not really much to do besides retry initialization.

[champnic]

Apparently another cause can be when using the default user data folder. Can you try specifying a custom user data folder so it's not in the same path as the exe ("C:\temp" is usually a good test) and see if that resolves this?

[ShaunLoganOracle]

Thanks, but:

1. as far as we can tell, there is no init-during-teardown going on, and
2. we already specify a custom user data folder location under %localappdata%

[LiangTheDev]

The creation failure of timeout is due to multiple apps using the same user data folder and they use different options for WebView2 environment. This is not allowed. So, different apps should use different user data folder. FWIW, it should fail with HRESULT_FROM_WIN32(ERROR_INVALID_STATE) instead of timeout. That is a regression in recent releases and will be fixed in future releases.
For ClickOnce apps, ApplicationDeployment.CurrentDeployment.DataDirectory should be a good value to use for WebView2 user data folder.

[sln162]

@LiangTheDev We also encountered that there may be a problem with the UDF folder permissions, but it takes 130 seconds to trigger a timeout error, which is not conducive to software judgment and timely response.
Are there any updates or plans?

[LiangTheDev]

The issue of timing out due to multiple apps sharing the same UDF should have been fixed. If it was not a real timeout (machine very busy), please take an ETW trace of the repro, by following the instructions at https://github.com/MicrosoftEdge/WebView2Feedback/blob/main/diagnostics/etw.md.

[sln162]

@LiangTheDev Just add one to the UDF folder to deny Users permission to write files (simulating that Users do not have permission to write files), and WebView2 will time out after 130 seconds instead of popping up an error at that time. Is this expected?

The premise is to run the program with administrator privileges.

[sln162]

@LiangTheDev ETW File

[LiangTheDev]

Though it is not ideal, the behavior is currently expected/by design. WebView users data folder is really used in WebView2 browser processes. If the user don't have access to that folder, WebView2 browser process will fail fast very earlier and would not be able to report back any errors.
I'll track the issue internally to see whether we could improve the developer experience. No promise on solving it. This could be complicated in some scenarios, like when the app runs as admin, simply checking access to the folder in app process before starting the browser process would not work as the browser process will not run as admin.

[sln162]

@LiangTheDev Yes, but this kind of timeout also takes 130 seconds, it will not return faster, and it is impossible to distinguish whether it is a real timeout or a permission problem. We can try to modify the folder permissions and add the full control permission of EveryOne or Users to solve it, but we can't modify it blindly without knowing the specific reason.
If you don’t have the permission to create a folder, you can know the result immediately. A dialog box will pop up from WebView2. There is no permission for a certain location. I hope that a dialog box can also pop up when you don’t have permission to write files. Thank you.

[LiangTheDev]

As the folder should start from non existent, the likelihood of able to create the folder but later failed to create files is low, and there are a lot of places where we are creating files, therefore, we would not add a dialog windows for this unlikely scenario.

[sln162]

@LiangTheDev Regardless of the permission to write files, when there is no permission to create a folder, popping up an error box is the behavior of Edge Dev, and WebView2 does not do this, because I set WEBVIEW2_RELEASE_CHANNEL_PREFERENCE, and removing it will not pop up an error message, but 130 second timeout. An error message pops up, is this a new addition to version 109/110? Or is this only happening on Edge Dev?

[LiangTheDev]

I don't think that there is any changes in 109/110 for whether there is a dialog. Try to copy the 109 files into a different folder and use that as fixed version webview2 runtime to see whether the behavior is different from Edge Dev channel.
The dialog is from browser process, whether it is shown or not, the webview creation probably would still timeout after 130s.

[sln162]

@LiangTheDev To increase the comparison, I also installed Edge Beta, added the UDF folder to Deny Users write permission, and the following interesting results occurred.
WebView2 108----timeout, no prompt
Edge Dev 110/Beta 109(WEBVIEW2_RELEASE_CHANNEL_PREFERENCE)----popup error message
Edge Dev 110/Beta 109(copy to other folder, fixed version) ---- timeout, no prompt

[LiangTheDev]

That confirms that popup is only for non stable channel. Anyway, the popup would not really impact webview creation result,
and this is error handling for apps running as admin when UDF has permission issue. As browser process was launched via explorer, there is no way to get feedback from it when error happens before connection can be established, and therefore errored as timeout.
We'll try to see what we can do in the future. Don't expect it to be fixed soon though.

[sln162]

@LiangTheDev Even if it does not pop up, at least output the error content to InitializationException.Message, such as: failed to create a folder, location: C:/..., please check permissions, etc.
Instead of what it is like now, developers and users don't know why.

[webview2]灾难性故障 (异常来自 HRESULT:0x8000FFFF (E_UNEXPECTED))|108.0.1462.54|10.0.19044.0

[LiangTheDev]

We are going to document that WebView creation can fail with E_UNEXPECTED if runtime does not have permissions to the user data folder.

I am closing this long thread with multiple different real issues. Please open new issue if some part in this issue has not been addressed.