Hi,
Been doing some digging...
So as you might know, the WebView2 control that AntView wraps is uses an Out Of Process COM model.
As such when you create the WebView2 control it starts a bunch of msedgewebview2 processes in the background. Similar like how all the major browsers nowadays start many processes to handle browsing websites.
Your application's WebView2 component then communicates with those background processes to make it look like a native control to your application.
As you can imagine this is all very resource intensive, so the smart WebView2 developers are re-using those background processes when you start the second instance of your application.
You can see this by querying for the process ID in AntView via BrowserProcesID.
The 2nd instance of your application will report the same Process ID as the first instance.
I _think_ that this background process re-use is what is biting you.
Is there no way to prevent the 2nd instance from re-using the existing msedgewebview2 processes you might wonder?
WebView2 determines if it re-uses the existing msedgewebview2 processes or not based on the User Data Folder that is used.
It seems the current version of WebView2 is ignoring our ability to change the User Data Folder setting for this via the UserDataFolder property, so we are currently researching why that is so.
You can probably test the above "background process re-use" hypotheses by having a copy of your application in a different folder, start that copy for the 2nd program instance and see if the lock up issue still occurs.
--
Wil
Been doing some digging...
So as you might know, the WebView2 control that AntView wraps is uses an Out Of Process COM model.
As such when you create the WebView2 control it starts a bunch of msedgewebview2 processes in the background. Similar like how all the major browsers nowadays start many processes to handle browsing websites.
Your application's WebView2 component then communicates with those background processes to make it look like a native control to your application.
As you can imagine this is all very resource intensive, so the smart WebView2 developers are re-using those background processes when you start the second instance of your application.
You can see this by querying for the process ID in AntView via BrowserProcesID.
The 2nd instance of your application will report the same Process ID as the first instance.
I _think_ that this background process re-use is what is biting you.
Is there no way to prevent the 2nd instance from re-using the existing msedgewebview2 processes you might wonder?
WebView2 determines if it re-uses the existing msedgewebview2 processes or not based on the User Data Folder that is used.
It seems the current version of WebView2 is ignoring our ability to change the User Data Folder setting for this via the UserDataFolder property, so we are currently researching why that is so.
You can probably test the above "background process re-use" hypotheses by having a copy of your application in a different folder, start that copy for the 2nd program instance and see if the lock up issue still occurs.
--
Wil