System.Runtime.InteropServices.COMException when trying to open dialog to add Process Dump File

[DrGav]

When trying to trying to open dialog to add Process Dump File an unhandled exception is thrown.

The following is the stack trace that results:

System.Runtime.InteropServices.COMException (0x800700AA): The requested resource is in use. (Exception from HRESULT: 0x800700AA)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at Microsoft.Web.WebView2.Core.CoreWebView2Environment.d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Web.WebView2.Wpf.WebView2.d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Web.WebView2.Wpf.WebView2Base.<>c__DisplayClass32_0.<g__Init|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at PerfView.GuiUtilities.WebBrowserWindow.<>c__DisplayClass18_0.<<Browser_Loaded>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

[brianrob]

Thanks for reporting this DrGav. We'll start with letting copilot triage this and see what it finds. I've not personally seen this one before.

[brianrob]

I don't think that copilot's triage is correct. It produced #2396, but testing with and without the fix doesn't change anything. And interestingly, it shouldn't have anything to do with opening a process dump.

DrGav, can you please provide exact repro steps? And can you confirm that this consistently repros for you (or is it intermittent)?

[DrGav]

Thanks for looking Brian Robbins (@brianrob). So I've been able to reproduce the issue and get it to work as well, and it is quite a specific instance that causes the problem.

I'm running the application as admin which uses my separate admin account (not the one I'm logged into Windows with). When clicking on "Process Dump File" hyperlink to open the Help page it seems to have an issue that the resource is in use (which I believe is a slight red herring, it appears more likely that the resource is unreachable). If I run as my local user, rather than admin, then there is no issue and the help guide opens correctly.

I've pulled the code down and found the exception is thrown on line 126 of WebBrowser.xaml.cs when running as admin.

await Browser.EnsureCoreWebView2Async(environment).ConfigureAwait(true);

the userDataFolder variable is being populated into admin users AppData folder but it would appear and instance of Edge then tries to read/write to that location but because windows is signed in as my regular user it doesn't have permission to access the folder in a location like:

C:\Users\MY-ADMIN-USER-GOES-HERE\AppData\Roaming\PerfView\VER.2026-03-24.20.31.22.520\WebView2

There is an existing issue of this type raised in the Web2View repo seen here:

MicrosoftEdge/WebView2Feedback#4672

The solution recommended in the issue thread above it to change the userDataFolder on line 114 of WebBrowser.xaml.cs to a location that all users can access:

var environmentAwaiter = CoreWebView2Environment
    .CreateAsync(userDataFolder: userDataFolder)
    .ConfigureAwait(true)
    .GetAwaiter();

I have changed this in the code to test and it does solve the issue, but I'm really not sure on the best practice of storing temp data for global user access.

If this all makes sense and you do want a fix I can look into solutions for storing global temp data and throw up a PR, I completely understand if this is too specific of a bug and not worth the fix though.

Cheers,
Gav

[brianrob]

This one has become a bit more complicated than I'd like. I assume that the issue here is that you're running PerfView as administrator because you needed to capture a trace? If so, I think I'd like to resolve this as not planned, but "fix" this by changing how we elevate PerfView for collection, so that it only elevates during collection, and otherwise doesn't stay elevated. Would that address your usage?