When the UDF folder is occupied and 0x8007139F appears, it is recommended to automatically create a new folder for internal processing

[sln162]

I believe many developers have encountered the issue of 0x8007139F, one of which is that the UDF folder is occupied, not in shared mode, or the DPI does not match, and so on.

The prompt message is: The group or resource is not in the correct state to perform the requested operation (Exception from HRESULT: 0x8007139F)

This can cause headaches for many developers who have to study and search around to find out the reason. The official suggestion is to specify a new UDF location, which is to set a new folder as the UDF folder.

I suggest that when encountering this situation, especially when the folder is occupied, it is possible to automatically create the folder directly. The location should still be in the UDF location specified by the user, and add names such as (1) and (2). Similar to when downloading from a browser, will it still prompt the user for duplicate files? No, it's automatic renaming and downloading.

Of course, in order to prevent users from not needing this feature, an option can be provided for users to choose from.

AB#45730263

[novac42]

@sln162 That's an interesting idea and I've added it to our backlog to investigate. We need to be careful when dealing with user data folder as the developer may not intend to automatically create a new one. Do you have some examples where you don't care having multiple user data folders? Would you need to combine the newly created UDF with existing one later, like in downloading you can download multiple copies but only 1 will be actually used?

[sln162]

@novac42 UDF folders are better to have only one, but when this problem occurs, you have to switch to a new folder. So creating a new folder is necessary, and every time we encounter it, we also worry that there will be too many folders, so we control the number, such as up to 5 can be created, when the UDF at index 0 is not available, it will try 1-5, many times when it tries to index 1 it is already possible, and sometimes it may take two or three more times (we think the reason may be the multiple opening of the program), but it will not try the number of times we set.

And the next time you initialize, you still start with index 0 first, which maximizes the reuse of folders and prevents infinite expansion.
So I suggest that you can provide a parameter for the user, such as int type, when it is 0 then do not try to create a folder, when it is 3 then try 3 times to create a new folder, the default value can be 3 or 5, this will be evaluated later depending on the situation.

[sln162]

We also tried to delete the previous UDF and other solutions, but the execution would fail because of the occupation and could not be deleted. We had to delay the deletion and check whether the webview2 process was exited. It was very troublesome. We also tried to delete the previous folder every time we reopened the software, but we didn't understand the deeper mechanism of Webveiw2, so we chose the compromise solution in the previous message. You can take a simple reference.

[aluhrs13]

@sln162 the UDF is pretty important to the state of WebView2. An application changing UDFs between runs will lose cookies, storage contents, caches, etc. so I'm not sure it'd be broadly valuable to try to support this pattern.

The official suggestion is to specify a new UDF location, which is to set a new folder as the UDF folder.

Where did you see this suggestion? If you hit 0x8007139F, the best troubleshooting approach is to look at which applications are using that UDF, understand their environment options, and work out a way to ensure they match. That would prevent the error from happening at all.

[sln162]

@aluhrs13 I disagree with your view.
When encountering an error of 0x8007139F, it is impossible to complete initialization without switching the UDF position! If it's a development environment, of course, the cause can be investigated. The problem is that this error often occurs on other users' machines, and there is no way to investigate it in depth.
Based on the logs we collected, 0x8007139F appears frequently, and switching to a new UDF can generally resolve the issue.

I understand what you mean, and when encountering this problem, you should study more deeply why it is triggered, but the user's environment is varied and the reasons are different, such as the different DPIs that cause it, why does the same program have different results? For example, there are other antivirus software occupying and scanning folders that cause the occupation (just an example), can we prompt the user to uninstall and exit your antivirus software? No, so we prompt what caused what, can they understand? It's better to directly create a new UDF to help them solve the problem, I think this is what the user wants.

[fdzatdtv]

We also encounter very often 0x8007139F during initialization of a WebView2 on productive systems. To be more specific, on Windows Server 2016 Standard, because our applications are widely used on WTS.
The runtime is 120.* (evergreen installation). The SDK version is 1.0.1462.37.
How did you collect the logs? What should we collect and how?

[sln162]

@fdzatdtv We will send the relevant information of various initialization failure events to our server, including 0x8007139F. When we encounter 0x8007139F, we directly replace the UDF folder and try again. If the initialization still fails, the software will report the initialization failure error information for the second time. For example, if we try up to 4 times, and the user's software sends 4 error requests in a short time, it means that the internal policy of the software has failed. If the user does not reach the maximum number of attempts, such as only sending once, it generally means that the internal policy of the software has worked. Of course, we also need to analyze other requests comprehensively, but this telemetry data is usually enough.

[aluhrs13]

This is not something we'd build into WebView2 itself, given that the work-around to do this in your application, we're going to close this as not planned.