-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Problem/Bug]: On some windows user accounts, setting parent of webview in some contexts results in - Exception: System.InvalidOperationException: CoreWebView2 members cannot be accessed after the WebView2 control is disposed. ---> System.Runtime.InteropServices.COMException: The group or resource is not in the correct state to perform the requested operation. (Exception from HRESULT: 0x8007139F) #4206
Comments
WebView2 controller will be auto closed if the parent hwnd is destroyed. Is it possible that when switching slides, the old parent hwnd got destroyed before we reparent to the new hwnd? If that is the case, you might have to ensure that we reparent to a valid hwnd before the old one is destroyed. |
At face value this seems unlikely for two reasons
|
WebView could be closed if its browser process crashes which has events, Close is called, or parent hwnd is destroyed. There is no events to inform that WebView is closed, not sure whether you could get event when parent hwnd is destroyed. |
Ok. I see this documentation around ensuring we listen to and handle some events. but this does not explain why it is occurring for some users and not others, always. The user behavior that replicates this is:
Creating a separate user on the same machine, and following the same steps, will never replicate the issue. I cannot see why we would be closing or destroying the webview parent or process before, so the crashing might still be a possibility, but not the root cause. Why would the same code and software crash consistently for one user, and one browser window, but not the others if the behavior, machine, OS, software version and compatibility the same. I have included two ETW traces as attachments (in one zip), we were not able to discern if there was a race condition. To me, a race condition means that sometimes, it should not repo, but with the repo user, it always repos. What kind of user settings might affect or influence a race condition if the user behavior is the same? Additionally, is there a way to get a more clear error to know when we should be attempting to recreate the controller? or should we be checking for close events after any unexpected error. |
Got it. Looking at the trace, the events in not-working-trace.etl showed that WebView browser process for powerpnt.exe was still running and Microsoft.MSEdgeWebView\WebView2_APICalled events indicates that ParentWindow were successfully updated 4 times. Nothing obnormal. For the closed WebView we reject the call and don't log WebView2_APICalled event. So, if we encountered exception when setting ParentWindow, it should be that the webview is closed. However, the trace is not taken from the begin, there is not enough info to figure out why webviews were closed. |
I can generate a new trace. I will restart the machine, start the trace
before I open any other program, and then re-attach it.
…On Thu, Nov 30, 2023 at 7:42 PM Liang Zhao - MSFT ***@***.***> wrote:
Got it.
For browser process failure, there is CoreWebView2.ProcessFailed event.
Looking at the trace, the events in not-working-trace.etl showed that
WebView browser process for powerpnt.exe was still running and
Microsoft.MSEdgeWebView\WebView2_APICalled events indicates that
ParentWindow were successfully updated 4 times. Nothing obnormal. For the
closed WebView we reject the call and don't log WebView2_APICalled event.
So, if we encountered exception when setting ParentWindow, it should be
that the webview is closed. However, the trace is not taken from the begin,
there is not enough info to figure out why webviews were closed.
—
Reply to this email directly, view it on GitHub
<#4206 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHL75E77Y4MIVLA3LVIDQDYHERY5AVCNFSM6AAAAABABSNJUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZVGE2TANZQGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Hi team, Please find another version of the trace logs. Steps I followed
Can I get an email to use to send you the updated trace? |
You can contact me at [email protected]. |
@benhbell Can you also do a search for "Close"? For any of the results in your screenshot where the CoreWebView2Controller is a variable, it could be "variable.Close()" instead of "CoreWebView2Controller". (If you already did this, please disregard this comment) |
Hi, I'm focusing the same problem, however I can see that we doing something wrong. What I would like to know: Why does it work for more than 99% of our customer and a very small number of users gets into this failure. So what we do is: _hiddenHwndSource = new HwndSource(new HwndSourceParameters("Hidden", 1, 1) { WindowStyle = 0x02C00000 });
_hiddenHwndSource.RootVisual = _webView2Core; and later on we switch it in to our view with the following code: _hiddenHwndSource.RootVisual = new FrameworkElement(); // to unlink the webView2 Control from the hidden Source (I guess due to compatibility with older .NET Frameworks)
_hiddenHwndSource.Dispose(); // I guess this is the codeline which disposes the webview2Core (for a very small amount of users)
_webView2PresentationPanel.Children.Add(_webView2Core); // here it throws the exception My problem is: I want to know how reproduce the problem, so I can relably say moving the Dispose one line down solves the problem. So under what conditions does Disposing the HwndTarget directly disposes the webview2Core? -Markus |
@benhbell: Does the one developer system has touch or pen input enabled?
the issue can be replicated on one user account on one machine, but not another user account on that same machine. In both accounts pen and touch is enabled |
hey @champnic there is no .close() that refers to webviews that are called during the steps that replicate the behavior. I did find a reference though, but commenting out that close and restarting did not help.
We still have customers reporting this issue and have not found a resolution yet or explanation why it only affects certain users. |
@sf-mzh The only thing I can think of is that I plugged in an extra monitor that had a touch screen at some point, but I have tried to replicate that issue in the past, have not been able to replicate it. |
@benhbell Would you be able to share the full stack trace where it crashes? Do you have a sample app which reproduces this issue we could use to debug further? I see in the code you shared a "wpfWebView2" referenced, which presumably isn't the problem one because the one having problems is a frameworkless WebView2 right? For frameworkless there isn't a WebView2 to call .Close() on - instead we're looking for anywhere that .Close() is being called on a CoreWebView2Controller. Sounds like that's never done in the code? |
hey @champnic Thank you so much for the clarification. I have looked for You can download the app from here I cannot promise you will be able to reproduce it. about 5% of users can with no clear pattern. I have a parallels machine with one user account that can, and another that can't. I am attaching some logs from the case that reproduces it, the stack trace when the bug is reproduced is at line 107ish |
For quick reference, here is the failure stack from your provided stacktrace.txt:
|
Is there anything else that I can provide? additional traces, etc. |
I ran the regex command, but for some reason, when I build and debug I still see the latest non-release running
|
Which runtime is getting loaded, and which were you expecting that's installed on your machine? |
In our case: We found that all users reporting this issue were running on a dpi scaling higher than 100%. However we got many many more users also running on a dpi scaling higher than 100% not reporting this issue. My current hypothesis is that it could be relatet to some kind of 3rd party tool (maybe accessibility or window helper), but I did not start to verify it. @champnic Could that be releated to an old runtime version? Which runtime version could be key for this issue? Does |
Running on a DPI scaling higher than 100% is the norm these days, so unclear if that's related or not. It's possible that it's related to an older runtime, although as far as we know this isn't a new regression. If you have data that showed a spike in hits or a clear beginning of when you started seeing this in relation to runtime version we'd be really interested in that. |
For us, the customer-reports with this specific crash started in december 2023. I got one dump which shows:
On Jan/11 that user said that it crashes since ~3 weeks. So maybe the v120 runtime? |
Ok, Attempted to get the correct runtime/browser versions to test https://www.nuget.org/packages/Microsoft.Web.WebView2/1.0.2357-prerelease
I think that now I am loading the correct version of webview2 (pre-release) and the canary edge, but I still don't see that webview2 version, should I be looking somewhere else to validate that the correct webview2 version AND edge version are loading to test if the pre-release fixes the issue. but I still replicate the issue. Additionally, I see a weird |
and I would love to give you a new trace, but I get a strange error when trying to run the Wpr profile.
My version of wpr
|
Hey @benhbell - I'm not familiar with that error, but a quick search indicates that it might be due to the OS not supporting some feature in wpr. What OS are you using? @LiangTheDev any idea? I've downloaded the app - what are the steps I need to do to potentially reproduce the issue, and how will I know if I've reproduced it or not? A video might help. (Pardon if already answered) Is there a reason you are using a frameworkless WebView2 and choosing to try and reparent manually? Could you try the scenario using WPF? The only thing I can think of is that something about the user account is causing a crash in the WebView2, and this manifests as an app crash when the WebView2 is attempted to be changed when reparenting. Liang mentioned the CoreWebView2.ProcessFailed event - are you listening and responding to that event? |
I am not familiar with that wpr error code either, but normally updating wpr to the latest version should make it work. |
Hey WebView2 folks, Though @benhbell is no longer my Project Manager, I felt it was worth following-up on this thread to let you know what our team has learned. Late Friday we found the setting that causes this bug in our code: PowerPoint's Optimize for Compatibility setting: @LiangTheDev said early in this thread "WebView2 controller will be auto closed if the parent hwnd is destroyed." We now realize that seems to be what is happening with this PowerPoint setting. Something in the code path the PowerPoint uses to load in compatibility mode closes the window handle that we attach to before building a new window handle; but we are currently exploring ways we can work around this problem. We appreciate the help of everyone in this thread, we will follow-up if we find more relevant information or a solution. |
@ChadPE Glad to hear you're getting closer to a solution. Thanks for the update! I'm closing this issue as it seems to be outside of WebView2, but let us know if you learn more and need us to take another look. |
Yea, I came back to this thread (I am no longer with that company) to check if it was ever fixed. Thanks for carrying the torch @ChadPE |
What happened?
Hello. We have a Windows PPT Plugin that our customers use. We use the latest Webview2SDK. A subset of our users are encountering an issue where some of our webviews are not displaying.
They all have a consistent error that does not seem to match what we can see in the code. Only one of our dev computers and only one user account can replicate it.
The issue can be replicated on the same machine, with the same software as another working user account and we have tried many non-code things to resolve it.
Users that encounter this issue, will always encounter this issue with one specific webview use-case, which happens to be the most critical one. We are not using a framework or UI for this, it is a frameless window. Our other usecases that do require some UI uses WFP (but those generally work).
We have customers that have reported this on windows 8, 10, and 11 (both pro and home editions)
I will be attaching some resources for you to review for both a working user account and a non-working user account on a developer machine with mock content. Both users are administrators on the machine, and the user account with the issue was actually the first user created on the machine.
Troubleshooting we have attempted
The code
Our project is large but in general, these are some parts of the code that are being used to both instantiate webview2 and then attempt to adjust the parent for some webview2 controllers.
We initialize webview2 - we use webview2 in more places than this, but we load up webviews for each slide and attempt to preload the content so that switching slides is seemless.
When a user presents a slide we call this, and start to set the parent of our webviews to the presenter window
We get a stacktrace error
Importance
Blocking. My app's basic functions are not working due to this issue.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
119.0.2151.72
SDK Version
stable
Framework
Other
Operating System
Windows 10, Windows 11, Other
OS Version
Microsoft Windows 11 Pro (10.0.22621.0))
Repro steps
Describing the Behavior
A working scenario results in the plugin working:
A non-working scenario results in the plugin working in some cases where webviews are used
Both accounts "SAY" according to the logs that they have the same DPI, zoom level, etc.
Repros in Edge Browser
Not Applicable
Regression
No, this never worked
Last working version (if regression)
No response
Attachments
The text was updated successfully, but these errors were encountered: