none
Windows 10/1709: Internet Explorer 11 will not open with UEV agent running RRS feed

  • Question

  • I've seen numerous posts about IE not opening once upgrading to Windows 10 1709.  I've experienced the same issues and the only way i could get IE 11 to launch is by stopping the UEV AgentService.  Seems all the advice the MS mods offer is re-install this and that.

    Anyone else had issues opening IE 11 and did killing the UEV service solve it?  Any longer term fix?  We enable UEV via group policy and I'm wondering if any changes have to be made.

    Thanks.

    Monday, September 17, 2018 8:06 PM

All replies

  • Any fix for this? we have the same issue, since upgrade to 1709 IE11 doesn't open, iexplorer.exe appears in task manager but then disappears after about 30 seconds. stop UEV and all IE11 works.
    Tuesday, October 16, 2018 1:57 PM
  • We're also facing this issue since upgrade to Windows 10 1803 - IE doesn't open anymore. Our current workaround is to delete following subfolders in "%localappdata%\Microsoft\UEV\...":

    MicrosoftInternetExplorer.common
    MicrosoftInternetExplorer.Version11

    Then IE can then be started again - although after a few days the same issue appears again...

    • Proposed as answer by MChaudoir Friday, December 21, 2018 2:44 PM
    Wednesday, November 7, 2018 1:43 PM
  • I have seen this issue for IE11, but interestingly, only for individuals who upgraded from an earlier version of Windows 10 to build 1803. I found that stopping UE-V, and then removing all the IE related folders from the server storage location and local profile got them working again. However as noted above, it seems as though the issue *may* return (it has not yet returned here but I suspect it'll take a couple of days).

    However, and this must be noted, all the fresh build and profiled 1803 users work fine - absolutely no issues at all, and it's been running since December.

    Did you do an in-place upgrade with existing user profiles?


    • Edited by Rashmika Thursday, January 24, 2019 10:43 AM
    Thursday, January 24, 2019 10:42 AM
  • In the meantime I opened a Microsoft case for that - still in progress.

    I also thought that only clients/users were affected on computers with an inplace upgrade but I also could reproduce it on newly installed clients. The only thing so far which is common for all users is that they are using two or more clients. Users with only one client haven't faced this issue so far.

    Thursday, January 24, 2019 12:14 PM
  • Excellent information everyone, thanks for the heads up.  Hope to hear more from your open case.

    It's happening to newly imaged machines and upgrades.  We are mostly on 1709 currently.  My 1809 machine works fine but it might be because it's been my test bed and I've done multiple changes on it.  Upgrading a laptop right now with a non-functional UEV/IE.  We'll see how that goes.

    Thursday, January 31, 2019 9:09 PM
  • Cause : When the IE starts we try to load the saved Data from a previous session – this doesn’t happen in time and hence we time out.

    Resolution : The Default timeout for SyncTimeoutinMilisenconds is 2000 ms

    Increase the SyncTimeoutinMilisenconds to 10000 or more 

    PowerShell:

    Set-UevConfiguration -SyncTimeoutInMilliseconds 10000

    • Proposed as answer by Steve40 Thursday, March 7, 2019 3:43 AM
    Monday, February 4, 2019 6:50 PM
  • Ben Sicko's fix worked for us for a hour until the user had a 2nd workstation and opened up IE triggering a sync event.  It then broke the 1709 machine that was fixed.  With 1603 coming end of life in April hopefully this gets fixed soon.

    @Bensicko1980  - we have case open also.

    $BI577rk - any idea if your fix works on users with multiple workstations?

    I could not find this anywhere but what is the proper folder structure for %appdata%\local\msft\uev\ie11\ the IE11 sync folder.  I tried to find a example but came up short. I noted on the broken machines they don't have the 3 folders (I don't have it in front of me but I think they are (Current, Backup, Common*) and one file but I forget the name.  Does everyone else have this folder structure in the ie11 appdata folder?  I noted the broken machines did not have all 3 folders but two.




    • Edited by Mukippa Tuesday, February 5, 2019 1:07 AM
    Tuesday, February 5, 2019 1:01 AM
  • Hello,

    the case is still open and we identified following workarounds (still no solution found...):

    - deleting the folder "MicrosoftInternetExplorer.common" in "%localappdata%\microsoft\uev\localsyncfolder\settingspackages" and "%localappdata%\microsoft\uev\%computername%"

    - disabling UEV on the affected clients

    - unregistering the IE Common Settings template on the affected clients

    - starting the IE with 'Run as administrator' (therefore the user needs to be member of the local admin group)

    - increasing the 'SyncTimeoutInMilliseconds' to a high value (e.g. 10000 - worked in most cases for us)

    Tuesday, February 5, 2019 7:21 AM
  • The fix works but has to be ran on every computer. Once you run the Power Shell command a reboot is required. 

    Set-UevConfiguration -SyncTimeoutInMilliseconds 10000

    Tuesday, February 5, 2019 1:58 PM
  • OK, then you should set it via GPO (Computer configuration\Policies\Administrative Templates\Windows Components\Microsoft User Experience Virtualization; Synchronization timeout) - did you try it ?
    Tuesday, February 5, 2019 2:15 PM
  • I too have encountered the same problem. I too have found that disabling UEV or unregistering the IE Common template will temporarily fix the issue. But it does not resolve the problem completely. 

    Manually setting the timeout above the default works in most cases. But I have seen a few where the change does not resolve the issue. I am wondering if there are other settings/files playing a part.

    In our environment we need WaitForSyncOnApplicationStart and WaitForSyncOnLogon Enabled. This is enabled so we can ensure the settings and files are present at the first launch of the application. 

    I am curious what settings other people have defined that are encountering this issue and if they are using the InboxTemplates too. 

    Below are all my non-default settings found using "Get-Uevconfiguration":

    DontSyncWindows8AppSettings = True

    SettingsStoragePath = \\contoso.com\UEV\%username%

    SettingsTemplateCatalogPath = \\contoso.com\uev\template

    SyncEnabled = True

    SyncProviderPingEnabled = False 

    SyncUnlistedWindows8Apps = True

    WaitForSyncOnApplicationStart = True

    WaitForSyncOnLogon = True

    I am setting a GPO to change WaitForSyncTimeoutInMilliseconds to 10000 to see if it stops the issue for frequent flyers. 

    There still seems to be some underlying issue here. One thing that I have noticed in the template that does not make much sense to me is:

    1) The Common Setting part of the Template collects [Software\Microsoft\Internet Explorer\Main] non-recursively.

    2) The Application part of the template collects also collects [Software\Microsoft\Internet Explorer] recursively and does not exclude the Main key

    It seems like there would be a possibility for some kind of collision here. Might have to bust out the old procmon next time.

    I have my doubts on whether we get an answer from Microsoft on this issue. I have been told there are no engineers tasked with working on UEV anymore. Same for the other MDOP applications. Except for App-V which the MSIX team has adopted.  

    But I am hoping there will eventually be a solution for this issue since it seems to be impacting quite a few people.

    Tuesday, February 5, 2019 11:16 PM
  • I had this issue.

    Using Powershell (Set-UevConfiguration -SyncTimeoutInMilliseconds 10000) did not fix the issue, but increasing the value to 90000 worked.

    Thursday, March 7, 2019 3:40 AM
  • Hi all,

    I engaged MS Premier support and here's what is known (from MS):
    "I’ve found some information that may be referring to a known issue on this.  Unfortunately the guy that logged the bug is out of the office until Monday."

    "At the moment they provided an unofficial solution which is to unregister the current template and register the templated attached to this email.

    As far as I understood from the engineering team, yes, this workaround that I provided is being developed into a patch."

    They provided me a new inbox template (MicrosoftInternetExplorer2013.xml).  Basically I just unregistered all templates, replaced the xml in the C:\ProgramData\Microsoft\UEV\InboxTemplates, re-registered all templates.  It seems to be working on my test machine, but I don't plan on deploying it as the timeout increase to 20000 milliseconds seems to have resolved most of the issues and I don't want to introduce a new variable.  I'll probably just wait for the patch in the future.

    Thursday, March 14, 2019 5:49 PM