This problem occurs on only Windows 10 LTSB.

Thanks for the report.

We can give a try in available environment and update the bug.

This looks to be specific to Windows 10 LTSB where Internet explorer comes as default Web browser.

Tested this on Windows-10 Enterprise edition with 'Edge' as default browser under Protocols of 'Set Association' dialog as below:

1. Changed the Edge to Internet explorer under Control Panel\Programs\Default Programs\Set Associations.
2. Installed GoogleChromeStandaloneEnterprise64 and launched chrome.
3. Default protocol application for HTTP and HTTPS was still Internet Explorer.

Attached is the screenshot of the same.

Deleted: 745878.jpeg 145 KB

	745878.jpeg 145 KB View Download

Yes, I understand that this issue only occurs on Windows 10 LTSB. Hence my Comment 1. Are trying to say the problem should be logged with Microsoft Support? I don't want this to be a back and fourth between Google and Microsoft as to who should own this problem. Therefore, I would like for you to kindly provide any data that can prove it is a Microsoft problem.

The next step would be to get a ProcMon log surrounding the installation of Chrome. With this, we should be able to tell what's going on. Windows 10 has its own magic to detect when a new browser is installed so that it can prompt the user on the next navigation. Perhaps this machinery is clearing the association when it notices that Chrome is installed.

Do we have an LTSB install somewhere?

I can work on getting a PML file with all events. Stay tuned. Let me know if there is a secure site where I can upload that file.

I have a PML file saved. Do you have a location where I can upload a 248MB zip file?

Could you upload it to Google Drive and share it with me?

Shared. Thanks

I'm not certain, but I think this may be a problem with Windows. I see in the log that the ProgId for the user's https handler is "AppX90nv6nhay5n6a98fnetv7tpk64pp35es" (look in HKCU\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice\ProgId). This is the ProgID for Edge, yet the log also indicates that HKEY_CLASSES_ROOT\AppX90nv6nhay5n6a98fnetv7tpk64pp35es does not exist. My theory is that when explorer.exe notices that a new browser is installed (you can see it enumerate the values in HKLM\SOFTWARE\RegisteredApplications and then scan Chrome's registration) it takes a look at the user's configured handlers and gets confused when it sees that there's nothing registered for AppX90nv6nhay5n6a98fnetv7tpk64pp35es.

As an experiment, you could try doing something to force IE as the default browser so that its ProgId shows up in ...\UrlAssociations\https\UserChoice\ProgId (maybe un-checking and re-checking the box would do this) and then install Chrome. My guess is that you'll find that the default association is not unchecked in the UX after installing Chrome. Could you give this a try?

Just to be sure, I checked the log to see if Chrome's installer was somehow stomping on the http/https settings for the user. It is not.

Thanks for reviewing that log and for confirming that Chrome installer is not executing any logic to modify those reg key values. I will try that experiment you mentioned and take this problem to Microsoft.

I tried the experiment you mentioned and I can confirm that when Url associations are set correctly to IE ProgID, then that values sticks correctly even after installing Chrome. I will take this problem to Microsoft so that they can address it.

Thanks Chrome team for your assistance.

Deleted: https_UserChoice_IE_ProgID.png 64.3 KB

	https_UserChoice_IE_ProgID.png 64.3 KB View Download

Deleted: http_UserChoice_IE_ProgID.png 62.7 KB

	http_UserChoice_IE_ProgID.png 62.7 KB View Download

You bet. I appreciate your help with the logs. Cheers.

Today, Microsoft confirmed that this problem is a bug in LTSB. Fix date TBD.

Thanks for the update.