locked
Metro UI Apps dont work when joined to the domain RRS feed

  • Question

  • So I have Windows 8 RTM. All the metro UI apps work fine until I join the domain. I checked related topics and they say registry settings in Group Policy but we don't have any of those such settings. It seems that dllhost.exe is locking these log files and then causes the Metro UI app like Store to hang. Upon killing the COM Surrogate process everything works fine. So why is this COM Surrogate using the same files?

    taskhostex (4088) WebCacheLocal: An attempt to open the file "C:\Users\chrise\AppData\Local\Microsoft\Windows\WebCache\V01.log" for read only access failed with system error 32 (0x00000020): "The process cannot access the file because it is being used by another process. ".  The open file operation will fail with error -1032 (0xfffffbf8).

    taskhostex (4088) WebCacheLocal: Error -1032 (0xfffffbf8) occurred while opening logfile C:\Users\chrise\AppData\Local\Microsoft\Windows\WebCache\V01.log.

    The program WWAHost.exe version 6.2.9200.16384 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Action Center control panel.
     Process ID: 1374
     Start Time: 01cd8b86d5b2bb5f
     Termination Time: 31
     Application Path: C:\Windows\System32\WWAHost.exe
     Report Id: 1cf00077-f77a-11e1-be73-60d819fcd93c
     Faulting package full name: winstore_1.0.0.0_neutral_neutral_cw5n1h2txyewy
     Faulting package-relative application ID: Windows.Store
    Wednesday, September 5, 2012 5:08 PM

Answers

  • We've recently run into this problem too. All other suggestions about proxies, etc. did not apply, so I downloaded ProcessMonitor and started digging. After spending a whole afternoon on it, I believe I may have a workable solution.

    Try this:

    1. Open regedit and locate HKCR\AppID\{3EB3C877-1F16-487C-9050-104DBCD66683}.
    2. Right click the {3EB3C877-1F16-487C-9050-104DBCD66683} key and modify permissions.
    3. Go to the "Advanced" permissions options and change the owner of the key to your local administrator account.
    4. Once you have ownership, give yourself full control of the registry key. Assuming you're a local administrator, you could just grant Full Control to the local Administrators group.
    5. Close regedit and open dcomcnfg.
    6. Browse through Computers -> My Computer -> DCOM Config -> and locate "WinInetCacheServer".
    7. Right-click "WinInetCacheServer" and select "Properties".
    8. Click the "Identity" tab and modify this setting to run the application under "The interactive user", rather than the default setting of "The launching user".
    9. Reboot, and your Metro UI Apps should start working again.

    All the regedit stuff is basically just to give you the ability to modify the DCOM component.

    I imagine, if needed, something could be worked into a domain GPO if this "fix" was needed on a grander scale. However, this needs thoroughly testing first. It's working great for us, and we've not seen any adverse effects, but I don't claim to fully understand *why* it works. Switching from launching user to interactive user in the DCOM config was partly guesswork, combined with fairly extensive research on the WinInetCacheServer component and careful review of my ProcessMonitor logs.

    I imagine at some point, Microsoft will recognise this as a problem and issue a "proper" fix. But, until then, please try this and report back to let me know how you get on!

    Best wishes to all for 2013!

    Simon.

    Friday, January 4, 2013 12:37 PM

All replies

  • Hi,

    You can try to enable proxy settings in Internet Explorer or modify the following policy for a test.

    1. Open "Local Group Policy Editor"
    2. Navigate to "Computer Configuration -> Administrative Templates -> Network -> Network Isolation"
    3. Open "Internet Proxy Servers for Apps" and set the value to your proxy server address like 172.16.0.1:8080.

    Isolating Metro Style Apps on Your Network
    http://technet.microsoft.com/en-us/library/hh831418.aspx

    There similar thread you can refer:

    http://social.technet.microsoft.com/Forums/en-US/W8ITProPreRel/thread/acc45e6e-86fe-4928-9f33-429ce8bebc8f

    http://social.technet.microsoft.com/Forums/en-US/w8itpronetworking/thread/a2aa72be-4964-459a-a220-5cf00ce187a9

    Hope that helps.

    Regards,

    Leo   Huang


    Leo Huang

    TechNet Community Support

    Friday, September 7, 2012 8:19 AM
  • This did not work. I looked at the other threads and those didn't pertain to me.
    Friday, September 7, 2012 4:13 PM
  • Hi,

    Try to disable firewall and antivirus program for test. And disable UAC also.

    Furthermore, removed this policy from Group Policy:

    Computer Config\Policies\Windows Settings\Security Settings\Local Policies\Security Options\

    These were called DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax and DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax

    and also removed the whole registry key HKLM\SOFTWARE\Policies\Microsoft\Windows NT\dcom.

    Regards,

    Leo   Huang


    Leo Huang

    TechNet Community Support

    Monday, September 10, 2012 2:23 AM
  • Firewall is disabled through group policy. Whenever I disabled UAC it tells me I need to run UAC to use the apps.

    Both DCOM group policy settings are Not Defined. 

    DCOM registry setting doesn't exist.

    Monday, September 10, 2012 4:06 PM
  • Have a look and see if your IT admins disable UAC by policy.

    win+Q then enter UAC and switch to setting and click UAC link.

    We had to remove all the Win8 machines from the domain where I worked to get this fixed while IT work on getting their policies changed and the impact that will cause to pre-8 OS.

    Tuesday, September 11, 2012 12:59 AM
  • I think I've found a possible reason - what is the version of your Active Directory Domain?  We have a W2K8 R2 Domain and when I join my pc to that domain I'm unable to link my Microsoft Account with my AD Account.  We also have a test W2K12 Domain - when I join the pc to that domain I can link the 2 accounts.  I've reviewed all the group policies and can't see any difference - perhaps there is a schema update that needs applying to the W2K8 Domain to allow this functionality to work?

    Would be interested to see if anyone else has tried this approach?

    Tuesday, September 11, 2012 8:30 AM
  • I've just run adprep on the W2K8 Domain Controller and am still unable to link my Microsoft Account with my Active Directory Account.  Must be more to update / apply....
    Tuesday, September 11, 2012 9:45 AM
  • So I was able to join the computer to the domain with no group policy on it. All the Metro UI apps work.  So it must be some policy that is affecting it. Doesn't make much sense though. Now I have to manually add each group policy we have to find out what one breaks it.
    Tuesday, September 11, 2012 1:09 PM
  • My issue appears to be proxy related.  If I by-pass the proxy authentication then all apps work.  Pushing anything through the proxy stops Metro UI apps working.

    Hope this helps someone else?

    Tuesday, September 11, 2012 4:39 PM
  • I'm still having issues with this. It seems more random now. I took off all the group policy. Works fine. I then add in stuff and it works.  Then when I log in with a different user from a different OU it comes up with the same issues. Same group policy is in that OU. I don't understand why this file is locking up on me. I may have to call Microsoft.
    Thursday, September 13, 2012 2:40 PM
  • "Metro UI doesnt work when joined to the domain"

    ..sounds like a feature to me!

    Thursday, September 13, 2012 2:53 PM
  • lol... maybe this is the solution for people who want Win8 but don't want the Metro UI. make sure you document that GPO seting when you find it, it may be the most popular setting of them all!

    Mark

    Thursday, September 13, 2012 3:22 PM
  • lol... maybe this is the solution for people who want Win8 but don't want the Metro UI. make sure you document that GPO seting when you find it, it may be the most popular setting of them all!

    Mark

    The Apps don't work. Metro UI works fine.
    Thursday, September 13, 2012 3:28 PM
  • Hi,

    If the issue occurs when GPO become effective, I think this should be related with GPO improperly configuration.

    As which the GPO cause this issue, I suggest to contact GPO forum for further help, maybe they can help you to find out:

    http://social.technet.microsoft.com/Forums/en-US/winserverGP/threads

    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. 

    Thank you for your understanding.

     

    Regards,

    Leo   Huang


    Leo Huang

    TechNet Community Support

    Tuesday, September 18, 2012 6:49 AM
  • Hi,

    I have the same problem. All PCs don't work after join domain.

    Regards,

    Thursday, November 15, 2012 9:36 AM
  • Hello,

    I have a Workaround that works for me.

    Log on as an Administrator and go to the User Profile
    "C:\Users\%Username%\AppData\Local\Microsoft\Windows\WebCache".
    Delete all Files in WebCache. To do so log on as a different User because the
    Files are still open in svchost (Sysinternals Process Explorer File
    handles)  has the File opened if the User is logged on. Now if the Users logs
    on again the Apps will work.

    In my opinion the Apps brake if the User doesn’t close
    the Apps before shutting down or logging off the System. If you close all Apps
    and shutdown the System the Apps still working.

    Regards,

    Robert


    • Edited by Robert 42 Monday, November 19, 2012 12:29 PM
    • Proposed as answer by Leo Huang Thursday, November 22, 2012 8:27 AM
    • Marked as answer by Leo Huang Thursday, December 6, 2012 7:06 AM
    • Unmarked as answer by Chris Erickson1212 Thursday, December 6, 2012 1:51 PM
    • Unproposed as answer by Chris Erickson1212 Wednesday, December 26, 2012 2:56 PM
    • Proposed as answer by Robert 42 Friday, February 1, 2013 7:49 AM
    Monday, November 19, 2012 12:28 PM
  • Hey,

    her an Update. The dllhost.exe in svchost is blocking the files. You just have to kill dllhost.exe with Process Explorer. After that all Apps are running fine.

    Regards,

    Robert

    Monday, November 19, 2012 3:50 PM
  • Workarounds are not really fixes. That's why I unmarked this answer.
    Thursday, December 6, 2012 1:53 PM
  • I was in the same situation, and none of my metro apps would work, so I decided to check and see if I had any traffic going out while the metro apps were running...NONE.

    This was my clue that something was wrong on my connection, so I verified that the Firewall settings looked good, then realized that my Windows 7->8 upgrade migrated an old proxy application I'd forgotten about and no longer use.  This proxy (Privoxy, a great application), was causing all of the issues.  After I removed it and checked Control Panel->Internet Settings->LAN settings and sure enough, the proxy was there too.  I cleared the fields and all of my maps began to work immediately.

    Thursday, December 6, 2012 11:24 PM
  • We do no use proxies.
    Wednesday, December 26, 2012 3:14 PM
  • We've recently run into this problem too. All other suggestions about proxies, etc. did not apply, so I downloaded ProcessMonitor and started digging. After spending a whole afternoon on it, I believe I may have a workable solution.

    Try this:

    1. Open regedit and locate HKCR\AppID\{3EB3C877-1F16-487C-9050-104DBCD66683}.
    2. Right click the {3EB3C877-1F16-487C-9050-104DBCD66683} key and modify permissions.
    3. Go to the "Advanced" permissions options and change the owner of the key to your local administrator account.
    4. Once you have ownership, give yourself full control of the registry key. Assuming you're a local administrator, you could just grant Full Control to the local Administrators group.
    5. Close regedit and open dcomcnfg.
    6. Browse through Computers -> My Computer -> DCOM Config -> and locate "WinInetCacheServer".
    7. Right-click "WinInetCacheServer" and select "Properties".
    8. Click the "Identity" tab and modify this setting to run the application under "The interactive user", rather than the default setting of "The launching user".
    9. Reboot, and your Metro UI Apps should start working again.

    All the regedit stuff is basically just to give you the ability to modify the DCOM component.

    I imagine, if needed, something could be worked into a domain GPO if this "fix" was needed on a grander scale. However, this needs thoroughly testing first. It's working great for us, and we've not seen any adverse effects, but I don't claim to fully understand *why* it works. Switching from launching user to interactive user in the DCOM config was partly guesswork, combined with fairly extensive research on the WinInetCacheServer component and careful review of my ProcessMonitor logs.

    I imagine at some point, Microsoft will recognise this as a problem and issue a "proper" fix. But, until then, please try this and report back to let me know how you get on!

    Best wishes to all for 2013!

    Simon.

    Friday, January 4, 2013 12:37 PM
  • That fixed it for me! Now the only issue is to do that on every machine..

    Thank you

    Friday, January 4, 2013 3:17 PM
  • That fixed it for me! Now the only issue is to do that on every machine..

    Thank you

    Good to hear! :)

    As I said before, I should think it could be doable with a GPO. So far as I can tell, if you look back in that same registry key after modifying the DCOM properties, it just creates a single registry entry. So, it should be possible to push that registry entry out to Windows 8 machines on your domain using a GPO filtered to only effect Windows 8 systems.

    The only thing I'm not 100% about is whether a GPO registry setting would be able to apply given the only account with the ability to modify the key by default is the "TrustedInstaller" account (if I recall correctly - I'm not sat at my Win8 PC to check). I guess some testing is in order ;)

    Would really love to hear how you get on, and would be happy to investigate pushing this out via GPO when I'm back in the office next week, if you'd like some additional assistance.

    But, for now, enjoy your weekend!

    Best regards,
    Simon.

    Friday, January 4, 2013 6:08 PM
  • I just had a go at this and unfortunately it hasn't worked for me.  Were there any other steps you took involving user accounts?

    Thanks

    Wednesday, January 9, 2013 9:03 AM
  • Hi Planescape -

    Sorry to hear this doesn't appear to have worked for you.

    No additional steps, no. In fact, from a completely fresh Windows 8 installation, once joined to the domain, the steps I documented were the *only* steps required. I wonder, have you tried any of the other suggestions for this particular issue prior to trying my steps?

    It might be worth deleting the contents of the WebCache folder for the specific user in question. You'll need to log in as a different user in order to be able to do this, as these files are locked when the user in question is actually logged in.

    So, login with a different user account, then go to the folder C:\Users\[username of problem user]\AppData\Local\Microsoft\Windows\WebCache and delete all the files in this folder. Log out and back in as the problem user and see if there is any change.

    (Note that the "WebCache" folder is a system folder, and therefore only visible when you uncheck "Hide protected operating system files" in Folder Options / View)

    Best regards,
    Simon.

    Wednesday, January 9, 2013 9:38 AM
  • If you are planning on joining a domain, install Windows 8 from a Windows Deployment Server.  The install creates a domain user up front.  I consider this a workaround, but it works.

    - Michael Faklis

    Saturday, January 12, 2013 2:46 PM
  • Monday, April 22, 2013 7:00 PM
  • Genius - been fighting with this for a few days Thanks and lets hope MS wort this out with an update before I roll out to my entire network !

    Monday, May 20, 2013 2:33 PM
  • Thanks rahulsharma7, all I ended up needing was to give "ALL APPLICATION PACKAGES" read permission to HKEY_CLASSES_ROOT, then the metro apps began to work again.  For me, the issue didn't start after joining the domain, rather after configuring VPN access.
    • Edited by Eric Palmer Wednesday, August 14, 2013 3:13 AM
    Wednesday, August 14, 2013 3:12 AM
  • what is regedit?
    Wednesday, September 24, 2014 4:13 PM