none
Xbab applications not running from the internet

    Question

  • Hi there,

    I am trying to run an xbap application from this URL

    http://www.valil.com/winfx/Valil.Chess.WinFX.xbap
    (other xbab apps from the internet are not running either e.g http://www.charlespetzold.com/wpf/JeuDeTacquin/JeuDeTacquin.xbap )

    IE 6 gives me an error message and wont let me run the app even though I
    have added the site as a trusted site. It runs if I get the source and
    compile and run it locally. It looks like a security issue. Can some one
    kindly tell me what I need to do get the app running from the internet ?

    The detailed error info is as follows:

    Startup URI: http://www.valil.com/winfx/Valil.Chess.WinFX.xbap
    Application Identity:

    System.UnauthorizedAccessException: Access is denied. (Exception from
    HRESULT: 0x80070005 (E_ACCESSDENIED))
       at
    System.Deployment.Internal.Isolation.IsolationInterop.GetUserStore(UInt32
    Flags, IntPtr hToken, Guid& riid)
       at System.Deployment.Internal.Isolation.IsolationInterop.GetUserStore()
       at System.Deployment.Application.ComponentStore..ctor(ComponentStoreType
    storeType, SubscriptionStore subStore)
       at System.Deployment.Application.SubscriptionStore..ctor(String
    deployPath, String tempPath, ComponentStoreType storeType)
       at System.Deployment.Application.SubscriptionStore.get_CurrentUser()
       at System.Deployment.Application.DeploymentManager..ctor(Uri
    deploymentSource, Boolean isUpdate, Boolean isConfirmed, DownloadOptions
    downloadOptions, AsyncOperation optionalAsyncOp)
       at System.Deployment.Application.InPlaceHostingManager..ctor(Uri
    deploymentManifest, Boolean launchInHostProcess)
       at System.Deployment.Application.InPlaceHostingManager..ctor(Uri
    deploymentManifest)
       at MS.Internal.AppModel.XappLauncherApp.TryUriActivation()
       at MS.Internal.AppModel.XappLauncherApp.XappLauncherApp_Startup(Object
    sender, StartupEventArgs e)
       at System.Windows.Application.OnStartup(StartupEventArgs e)
       at System.Windows.Application.<.ctor>b__0(Object unused)
       at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
    callback, Object args, Boolean isSingleParameter)
       at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source,
    Delegate callback, Object args, Boolean isSingleParameter, Delegate
    catchHandler)
       at System.Windows.Threading.DispatcherOperation.InvokeImpl()
       at
    System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object
    state)
       at System.Threading.ExecutionContext.runTryCode(Object userData)
       at
    System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext
    executionContext, ContextCallback callback, Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext
    executionContext, ContextCallback callback, Object state)
       at System.Windows.Threading.DispatcherOperation.Invoke()
       at System.Windows.Threading.Dispatcher.ProcessQueue()
       at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32
    msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
       at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam,
    IntPtr lParam, Boolean& handled)
       at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
       at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
    callback, Object args, Boolean isSingleParameter)
       at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source,
    Delegate callback, Object args, Boolean isSingleParameter, Delegate
    catchHandler)
       at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority
    priority, TimeSpan timeout, Delegate method, Object args, Boolean
    isSingleParameter)
       at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority
    priority, Delegate method, Object arg)
       at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr
    wParam, IntPtr lParam)

    -----------------------

    PresentationHost.exe v3.0.51116.0
    (winmain_oob/avalon_wap_FEB_CTP_2006.060131-1602 -
    C:\WINDOWS\system32\PresentationHost.exe
    ntdll.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\ntdll.dll
    kernel32.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\kernel32.dll
    msvcrt.dll v7.0.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\msvcrt.dll
    ADVAPI32.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\ADVAPI32.dll
    RPCRT4.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\RPCRT4.dll
    USER32.dll v5.1.2600.2622 (xpsp_sp2_gdr.050301-1519) -
    C:\WINDOWS\system32\USER32.dll
    GDI32.dll v5.1.2600.2818 (xpsp_sp2_gdr.051228-1427) -
    C:\WINDOWS\system32\GDI32.dll
    ole32.dll v5.1.2600.2726 (xpsp.050725-1531) - C:\WINDOWS\system32\ole32.dll
    SHELL32.dll v6.00.2900.2869 (xpsp_sp2_gdr.060316-1512) -
    C:\WINDOWS\system32\SHELL32.dll
    SHLWAPI.dll v6.00.2900.2861 (xpsp_sp2_gdr.060303-1517) -
    C:\WINDOWS\system32\SHLWAPI.dll
    urlmon.dll v6.00.2900.2870 (xpsp_sp2_gdr.060317-1513) -
    C:\WINDOWS\system32\urlmon.dll
    VERSION.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\VERSION.dll
    WININET.dll v6.00.2900.2861 (xpsp_sp2_gdr.060303-1517) -
    C:\WINDOWS\system32\WININET.dll
    CRYPT32.dll v5.131.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\CRYPT32.dll
    MSASN1.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\MSASN1.dll
    OLEAUT32.dll v5.1.2600.2180 - C:\WINDOWS\system32\OLEAUT32.dll
    IMM32.DLL v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\IMM32.DLL
    comctl32.dll v6.0 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll
    comctl32.dll v5.82 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\comctl32.dll
    MsgPlusLoader1.dll v3, 63, 4, 0 - C:\Program Files\MessengerPlus!
    3\MsgPlusLoader1.dll
    MSCTF.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\MSCTF.dll
    tiptsf.dll v1.7.2600.2180 (xpsp_sp2_rtm.040803-2158) - C:\Program
    Files\Common Files\microsoft shared\ink\tiptsf.dll
    OLEACC.dll v4.2.5406.0 (xpclient.010817-1148) - C:\WINDOWS\system32\OLEACC.dll
    MSVCP60.dll v6.02.3104.0 - C:\WINDOWS\system32\MSVCP60.dll
    PSAPI.DLL v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\PSAPI.DLL
    CLBCATQ.DLL v2001.12.4414.308 - C:\WINDOWS\system32\CLBCATQ.DLL
    COMRes.dll v2001.12.4414.258 - C:\WINDOWS\system32\COMRes.dll
    xpsp2res.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\xpsp2res.dll
    McVSSkt.dll v10, 0, 0, 26 - c:\progra~1\mcafee.com\vso\McVSSkt.dll
    WS2_32.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\WS2_32.dll
    WS2HELP.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\WS2HELP.dll
    Secur32.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\Secur32.dll
    dfshim.dll v2.0.50727.42 (RTM.050727-4200) - C:\WINDOWS\system32\dfshim.dll
    mscoree.dll v2.0.50727.42 (RTM.050727-4200) - C:\WINDOWS\system32\mscoree.dll
    PresentationHostDLL.dll v3.0.51116.0
    (winmain_oob/avalon_wap_FEB_CTP_2006.060131-1602 -
    C:\WINDOWS\WinFX\v3.0\WPF\PresentationHostDLL.dll
    mscorwks.dll v2.0.50727.42 (RTM.050727-4200) -
    C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
    MSVCR80.dll v8.00.50727.42 -
    C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd\MSVCR80.dll
    mscorlib.ni.dll v2.0.50727.42 (RTM.050727-4200) -
    C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\a1fb4119af2f9c478da1ffb42ae06bbe\mscorlib.ni.dll
    System.ni.dll v2.0.50727.42 (RTM.050727-4200) -
    C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System\09b24e0f71234f42b31ef6107414b1b5\System.ni.dll
    WindowsBase.ni.dll v3.0.51116.0 -
    C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\WindowsBase\6cb2b9e21ed5fb4f86ba6033c634e44c\WindowsBase.ni.dll
    PresentationCore.ni.dll v3.0.51116.0
    (winmain_oob/avalon_wap_FEB_CTP_2006.060131-1602 -
    C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\PresentationCore\cbc59dea81eda64f96469d9f773c69d8\PresentationCore.ni.dll
    PresentationFramework.ni.dll v3.0.51116.0
    (winmain_oob/avalon_wap_FEB_CTP_2006.060131-1602 -
    C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\PresentationFramewo#\58f84ee44c4a5747b445e016591fde1c\PresentationFramework.ni.dll
    msctfime.ime v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\msctfime.ime
    mslbui.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\mslbui.dll
    actxprxy.dll v6.00.2900.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\actxprxy.dll
    msi.dll v3.1.4000.2435 - C:\WINDOWS\system32\msi.dll
    SXS.DLL v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\SXS.DLL
    PresentationUI.ni.dll v3.0.51116.0 -
    C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\PresentationUI\0d8c626bdfe1fe498012e37befdd8cad\PresentationUI.ni.dll
    System.Deployment.ni.dll v2.0.50727.42 (RTM.050727-4200) -
    C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System.Deployment\61a6971c7a2b8e4cbc39f5fd9da1ebe3\System.Deployment.ni.dll
    rsaenh.dll v5.1.2600.2161 (xpsp.040706-1629) - C:\WINDOWS\system32\rsaenh.dll
    nbmaptip.dll v1.0.2201.0 - C:\Program Files\windows journal\nbmaptip.dll
    sptip.dll v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) - C:\WINDOWS\ime\sptip.dll
    SPGRMR.DLL v5.1.2600.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\IME\SPGRMR.DLL
    shfolder.dll v6.00.2900.2180 (xpsp_sp2_rtm.040803-2158) -
    C:\WINDOWS\system32\shfolder.dll
    diasymreader.dll v8.0.50727.42 (RTM.050727-4200) -
    C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\diasymreader.dll

    Thursday, May 11, 2006 7:45 AM

Answers

  • We got caught up in the v3.5 SP1 release, but the XBAP permission repair tool is finally released: http://www.microsoft.com/downloads/details.aspx?FamilyID=adb47247-4e27-4490-a153-39d8334172d9. It repairs the most commonly occurring registry & file permission problems that fail XBAP deployment. Shortly, the Watson service will start offering it to users of affected computers.
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, June 12, 2008 5:10 PM
  • If you have the problem described in this thread, here's some manual steps you can take to try to fix it:

     

    Check the ACLs on all the following things:

     

    XP: File System

  • "x:\Documents and Settings\username\Local Settings\Application Data" folder and/or Deployment subfolder
  • "x:\Documents and Settings\username\Local Settings\Apps" folder.

    Vista: File System:

    - Same as above but under x:\Users\username\...

    Registry:

  • HKCR\Interface\{79EAC9C9-BAF9-11CE-8C82-00AA004BA90B} key

     

    There's a slight chance there could be other mis-ACL'ed registry keys or files.  If explicitly granting your user ACL rights to those paths doesn't work, simply run a registry monitoring tool like SysInternals Process Monitor, and look for registry or file accesses that fail.  These are the reg keys or folders you need to fix.

     

     

    HTH,
    Matt

Wednesday, February 27, 2008 5:51 PM

All replies

  • Hi,

    I've got no problems running http://www.charlespetzold.com/wpf/JeuDeTacquin/JeuDeTacquin.xbapp or the other one.

    Which CTP Version of WinFX are you running ?
    Are you administrator on the machine ?

    Bye
    Thursday, May 11, 2006 8:12 AM
  • Hello. We have run into the very same problem. Two out of 10 - 15 users are getting the same error above, whereas everyone else has had no problem. We should all be running the same configurations: XP SP2, IE6. We are all running TrendMicro. Though turning that off did not solve the problem for affected users. Each user is also listed as an Admininstrator on their own machine.

    All users are running WinFX Runtime Components 3.0 - Beta 2 ( 3.0.03906.22 ). All development is with the latest CTP.

    Could anyone provide a direction to head in on resolving this?

    Thanks,
    Mark
    Tuesday, June 13, 2006 8:26 PM
  • Looks to be a version problem as I'm running 3.0.6327.0 of the PresentationFramework and it works fine.

     

     

    Wednesday, June 14, 2006 6:38 AM
  • My apologies. I must have copied the version from the wrong place. The Presentation Host version is 3.0.6327 also.

    Are there any other possibilities? 

    Thanks,
    mark
    Wednesday, June 14, 2006 3:41 PM
  • The original post had "UnauthorizedAccessException".

    According to the doco "Represents the error that occurs when an I/O operation cannot be performed because of incompatible file access levels".

    As a  side note I'm running IE7 from www.microsoft.com/ie

    As Thomas Lebrun suggests maybe you need to Run IE as Administrator?

     

    Wednesday, June 14, 2006 11:20 PM
  • First, let me clarify that you do not need to be administrator to launch a typical WPF standalone application or browser application (xbap). These apps are ClickOnce-deployed and are per-user (not per-machine).

    The exception stack suggests the ClickOnce deployment service is unable to induct the application to the store. Can you try manually creating a file or a folder under C:\Documents and Settings\<username>\Local Settings\Apps\2.0 or in one of the subfolders underneath there? Want to make sure there isn't some weird access issues going on. If that isn;t the case, can you kill dfsvc.exe,  delete all the contents of that folder and try deploying the app again?

    Friday, June 16, 2006 5:34 PM
  • Same problem here with xbap applications:

    System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
    at System.Deployment.Internal.Isolation.IsolationInterop.GetUserStore(UInt32 Flags, IntPtr hToken, Guid& riid)
    at System.Deployment.Internal.Isolation.IsolationInterop.GetUserStore()
    at System.Deployment.Application.ComponentStore..ctor(ComponentStoreType storeType, SubscriptionStore subStore)
    at System.Deployment.Application.SubscriptionStore..ctor(String deployPath, String tempPath, ComponentStoreType storeType)
    at System.Deployment.Application.SubscriptionStore.get_CurrentUser()
    ...

    No problem accessing and deleting all content under C:\Documents and Settings\<username>\Local Settings\Apps\2.0 but without better luck. Please note that dfsvc.exe does not even start. I didn't see any acces denied error using FileMon.

    On the contrary, no problem using other ClickOnce applications, such as http://www.sellsbrothers.com/wahoo2/publish.htm

    Tuesday, June 20, 2006 8:59 AM
  • Thanks for your response, Ashish.

    Unfortunately, I still cannot get this to work. I took a look in C:\Documents and Settings\<username>\Local Settings. There was not an Apps folder. I made sure that the Local Settings directory was not read-only, but that didn't seem to help.

    I also noticed that dfsvc.exe was not running on the system before I attempted the install or afterwards. This could be a problem, no? I also see from searching the net that there are several worms that install a file with the same name. (MYFIP.A or MYFIP.K).  Perhaps an anti-spy, or antivirus program could be the problem?

    I will look into this possibility, but I would also like to know if this seems likely to you.

    Thanks,Mark

    Tuesday, June 20, 2006 5:28 PM
  • Is this still a problem? Can you try deleting the ClickOnce app store (all contents under C:\Documents and Settings\<username>\Local Settings\Apps\2.0), then trying again? The dfsvc.exe I was referring to is the ClickOnce service that does the downloads and checks for updates. It is launched on application launch and shuts down soon thereafter. If it wasn't running at the specific instance you checked, there's no reason to panic.
    Monday, June 26, 2006 4:13 AM
  • Hi Ashish. Thanks again for inquiring on the status.

    We have still not arrived at a solution. There is no ...\Apps\2.0 directory on the affected machines. It seems to me as though creating those very directories is part of the problem.  The only new piece of information I have right now is the following error message I retrieved from the Events log:

    The description for Event ID ( 0 ) in Source ( .NET Runtime ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Unable to open shim database version registry key - v2.0.50727.00000.

    I had a moment just now to look up this error. I found the following discussion:

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=131584&SiteID=1&PageID=1

    In this forum, there is the following post: 

    As already stated earlier in this thread giving  user-rights onto the key "v2.0.50727.00000" in [HKLM\Software\Microsoft\.NETFramework\Policy\AppPatch]

    should solve the issue. I granted users Read/Write and the problem has not re-occured since then.

    I will try this solution and report back.

    Monday, June 26, 2006 2:07 PM
  • We have resolved this issue.

    Tuesday, July 11, 2006 3:05 PM
  • Is there something wrong with the forum software? My posts are being cut-off and the edit feature does not work.

    Anyway, we solved the issue by deleting and recreating the affected user accounts.

    -Mark

    Tuesday, July 11, 2006 3:09 PM
  • i am unable to run xbap application on browser, i am using winfx may CTP release and IE 7.0
    Thursday, July 13, 2006 5:46 AM
  • Try to download the June CTP and to see if you are able to display/launch the page/application

     

    Thursday, July 13, 2006 10:18 AM
  • It is fixed if you create a new user profile, however that is unacceptable

    is there another solution for this problem?

    Monday, December 25, 2006 12:45 PM
  • I have the exact same error. Creating a new user enables me to view the XBAP applications as well, but obviously we need a better solution. None of the other suggestions on this thread helped. When I looked at the permissions tab for some of the framework related directories under my user profile, I received the message documented in the following KB articles:

    http://support.microsoft.com/default.aspx/kb/322293

    http://support.microsoft.com/kb/899182

    I have not tried the hotfixes mentioned because it is unclear to me if these are pre- or post-SP2 files and it is also unclear as to whether these files are only supposed to prevent future permissions problems or if they fix all currently existing permission ordering problems on the drive and in the registry.

    I'm using IE7 and it only showed the call stack to me one time when I got the error, but it was the same call stack as shown at the beginning of this thread. Now it just tells me there was a System.UnauthorizedAccessException and hangs. I tried looking up the method System.Deployment.Internal.Isolation.IsolationInterop.GetUserStore mentioned in the call stack, but it is apparently undocumented on MSDN.

    Has anyone opened a support incident with Microsoft on this?

    Friday, January 12, 2007 6:37 AM
  • Has anyone found a solution to this problem? I have seen this on 2 out of 8 XP machines trying to run my xbap. All machines have the released version of the .NET 3.0 runtime. I am interested in releasing this application for the WPF challenge, but things aren't looking good at the moment with only a 75% success rate.
    Monday, March 12, 2007 6:30 PM
  • Nope I'm still waiting for a solution as well. I hope that if anyone on this thread does learn of a solution other than deleting the user that they will post it back onto this thread so the rest of us can find out about it.

     

    Monday, March 12, 2007 8:41 PM
  • From a similar case I debugged a while ago, I have a theory for what might be going wrong. On a computer where you get the problem, can you try this: In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Windows Presentation Foundation\Hosting, create a DWORD value RunUnrestricted=1. This will tell PresentationHost not to restart itself with a restricted process token. If this makes XBAPs run, very likely there are incorrect ACLs on registry keys.

    [Caution: The above registry switch is not an officially supported feature--strictly for debugging purposes.]

    Friday, March 16, 2007 2:41 AM
  • Chango,

    Thanks very much for your response. Setting the registry parameter you suggested did get rid of the error for me and enabled me to view XBAP applications. As you said, using this parameter as a solution is not advisable as presumably it introduces security vulnerabilities.

    Do you have any idea which registry keys may have incorrect permissions and what the permissions should be?

    Kyle

     

    Friday, March 16, 2007 3:49 AM
  • Okay, this already feels like making progress. But I don't know what the root cause is. In the one case we looked into, the process with the restricted token had no access to HKCU at all! I suspect some corporate OS deployment system might be responsible for this. (sysprep?) To see what's happening in your case, can you use RegMon from sysinternals.com to compare the access logs with and without RunUnrestricted? Set the filter to "PresentationH" (not full name b/c sometimes it gets reported abbreviated by the OS). Also, carefully compare the registry key permissions (HKCU, HKCU\Software) for a "good" and a "bad" user profile, preferably on the same computer and neither being the built-in administrator.

    Thanks for reporting these issues and for the cooperation. With enough patience, we should be able to reach some positive resolution.

    Friday, March 16, 2007 4:11 AM
  • Chango,

    The only account I have a problem with is my personal administrator account, but it is not the built-in administrator account. My system is Windows XP SP2, fully patched from Windows Update.

    I created a new account on this machine and it has no problem. The new account is not an administrator. Both accounts have the same permissions on HKCU and HKCU\Software. They each show Administrators, the user, and System as having Full Control while a group called RESTRICTED has only Read. When I go into Computer Management, the RESTRICTED group does not exist.

    As you requested, I took a RegMon using my problem account, with RunUnrestricted=1 and without, and with a filter of PresentationH* while I attempted to open:

    http://wpf.netfx3.com/direct/cubeapp/CubeApp.xbap

    Unfortunately, both the successful attempt and the failed attempt produced hundreds of entries, so I'm not confident that I'll be able to identify the key difference. I have uploaded both logs here if you would like to look at them:

    http://www.filemonster.net/en/file/4938/Regmon-XBAP-zip.html

    If you look back at the beginning of this thread, the exception occurs at:

    System.Deployment.Internal.Isolation.IsolationInterop.GetUserStore(UInt32 Flags, IntPtr hToken, Guid& riid)

    This is apparently a non-public API since I can't find it on MSDN. Can you provide any information about what this API requires for permissions? Any help you can provide is greatly appreciated.

    Thanks,
    Kyle

    Friday, March 16, 2007 5:37 PM
  • Thanks for the logs. Beyond Compare with a couple of custom rules makes comparing FileMon/RegMon log files a breeze. :-)  Now you can go ahead and delete them from the download server. For further communication you can email me at [me]@microsoft.com.

    The log file clearly shows that the restricted PresentationHost has no access to HKCU\Software\Classes. This is definitely abnormal. (System.Deloyment...GetUserStore() fails because it can't create keys under HKCU\Software\Classes\Software\Microsoft\Windows\CurrentVersion\Deployment\SideBySide\2.0.)  Can you examine the permissions of the Classes key? Normally, it should just be using the inherited ACLs, which should explicitly give your individual account Full Control. Based on the observations so far, my guess is that the unrestricted process is getting access to the keys via your membership in the Administrators group. When PH restarts itself "restricted", it gives up that SID. An alternate way to view the key permissions (sysinternals tool):
       accesschk.exe -v -k hkcu\Software\Classes

    You can see the effect of running without the Administrator token with the help of PsExec (from sysinternals again):
        psexec.exe -l cmd.exe

    The new command window will run with a very similar process token to PH's. From it, run regedit. (Make sure it's closed before that.) Navigate to HKCU\Software\Classes and try to make any change within. This should fail in your case but not under a healthy account. (And as an additional confirmation of the method, you can try changing something under HKLM. This should always fail.)

    Let's see how well things match the theory so far...

     

     

    Friday, March 16, 2007 8:06 PM
  • You found it! The permissions on the Classes key do appear to be the problem.

    Under my problem account, I found that the permissions for this key are exactly the same as HKCU, in that it lists Administrators and System with Full Control and RESTRICTED with Read, but instead of listing my account specifically along with these, it shows an unresolved SID with Full Control. I added my account back to the list with Full Control, and this enabled me to view XBAPs. When I clicked the Advanced button I also noticed that the checkbox for the option "Inherit from parent the permission entries that apply to child objects. Include these with entries explicitly defined here." is unchecked, but on the working user account it is checked. So as a 2nd test, I removed the explicit entry for my account on the Classes key and checked this checkbox, which enabled the permissions for my account to be inherited from HKCU, and I was still able to view XBAPs.

    So it would appear that the correct solution is to check this checkbox on the Classes key. Please respond as to whether you agree.

    Also, do you believe that the unresolved SID can be safely removed from the list?

    If you have any other theories about what might have caused these permissions discrepancies, I'd be interested in that as well.

    Friday, March 16, 2007 9:57 PM
  • Glad to hear the confirmation. :-)  Now the challenge remains to figure out what caused your HKCU\Software\Classes key to have broken permissions. Have you done anything "unusual" with this account and its profile? Renamed the computer or account? joined and disjoined a domain? roaming profile? reset password via recovery disk or from another admin account? upgraded Windows (from 2000 or previous installation of XP)? The unresolved SID suggests that this profile once belonged to a "different" user.

    Can anyone else with a similar XBAP deployment problem check for this apparent cause? Based on other reports, I'm concerned this may not be an isolated "freak case".

    Friday, March 16, 2007 10:19 PM
  • The only thing on your list that has been done to my machine is that this machine was originally Windows XP Home and I upgraded it to Windows XP Professional.

    This is certainly not an isolated case. I have seen numerous reports of this issue on the Internet in addition to the multiple people on this thread who have reported it.

    Do you agree that checking the checkbox is the correct solution?

    Do you believe the unresolved SID can be safely removed?

    Friday, March 16, 2007 10:32 PM
  • I have verified that adding the RunUnrestricted=1 to the Hosting key solves the issue on the two problematic computers here. The Windows installation history is not known by both users - most likely performed by a IT guy who is no longer here.

    I don't have easy access to either of these computers, so I will have to wait till they are idle to perform some more diagnostics - I am not a confident registry hacker - i don't even know what an ACL is (other than that part of your knee which is easily injured while playing soccer) - but I'll try to perform the previously stated tests.

    Monday, March 19, 2007 6:30 PM
  • ACL is short for Access Control List. It's just a way of referring to the permissions list on the Classes key. I'm satisfied that at least in my case the solution was to go into the permissions of the Classes key and then go to Advanced and re-enable permissions to be inherited from the parent, which then enabled my specific user account to receive Full Control permissions on the key.

    With regard to the unresolved Security Identifier (SID) on the permissions of my Classes key, I have set its permissions to Deny for now. After testing my applications for a while, I'll go back and delete it. However, I'm fairly confident that the SID is not required by any of the applications I am using because the very fact that the SID does not resolve means that I do not currently have a local account on my system that is associated with that SID, and I'm not part of a domain so therefore there is simply no way that any application could be using that SID to gain access to the Classes key.

    Hopefully you will have success as I did with changing the permissions on the Classes key, but I want to stress again that RunUnrestricted=1 should NOT be used as a solution because I would imagine that this would enable a malicious XBAP application to do things such as delete files on the hard drive, manipulate the registry, or put a virus on your system.

    Tuesday, March 20, 2007 1:46 AM
  • I have the same issue with a corporate PC. At least three of the 'unusual' things you mentioned happened to it: upgrade from W2K to XP, we changed domains and my username was changed.
    Although my 'career' might have been a bit extreme (worked for company A, which was bought by B, which was bought by C and then by A again), I am not sure it's that unusal...
    Wednesday, March 21, 2007 7:05 PM
  • Thanks to everyone for providing the feedback. (And I'm still interested in more.) To understand how wide-spread the particular problem with HKCU is and what the probable cause(s) may be, we'd need to collect more tangible evidence. In the end, issuing a hotfix and/or trying to work around the problem in the next version (or service pack) may be warranted.
    Wednesday, March 21, 2007 11:06 PM
  • I too have several PC that this exact issue is happening with. The registry permissions fix works as well (explicit user account permissions weremissing). I also know what is the likely cause of this on my systems. All of the systems affected have had user profiles migrated to a domain user account. Not a super common situation I'm sure, unless you have migrated profiles like this (which is sometimes common in an SBS network, btw).

    david

    Saturday, March 24, 2007 1:50 AM
  • I also encountered this problem.  I recently changed both the name of my account and the name of my computer (due to a name change).  Lucky, updating the registry permissions as suggested in this thread fixed the problem for me.  I urge you to investigate this problem in detail and solve it soon, as this proves a big deployment risk for our customers if and when we develop XBAP applications. 

     

    Thanks for the help!

     

    Shannon Schubert (Schneider Electric)

    Friday, June 08, 2007 11:26 PM
  • We are trying to understand the possible causes and in paralel considering the options for some kind of a hotfix and possibly also automatic detection of the issue in SP1 code.
    Wednesday, June 27, 2007 10:21 PM
  • I had similar problem. Thanks to this forum, it's now fixed.

    My machine has two user accounts. One is local account and the other network account.

    In my case, Classes key only has permission for the local account (other than Administrators, Restricted and System).

    HKCU and Software keys have full control for the network account which i am using. So by ticking the check box to inherit from parents, the problem with running XBAP has been solved.

    I run XP pro, factory installed, not an upgrade or anything like that.

    Thursday, July 26, 2007 6:24 AM
  • Giving my domain user account Full Control and Read permissions to HKCU\Software\Classes fixed this problem as well.

     

    This PC was installed from retail XP Pro with a local user account created. Then I used the Small Business Server 2003 Client Setup Wizard to convert the account to a domain user account configured to connect to our server. Perhaps this is where the permissions are not getting set correctly for some users.

     

    HTH.

     

    Monday, August 27, 2007 11:39 PM
  • I have been experiencing the same problems for a while now. I have done everything suggested in this thread. I have created a RunUnrestricted=1 DWORD as suggested and I have checked the permissions on HKCU\Software\Classes (which were not corrupt to begin with).

     

    When the problem first started, XBAPs failed to load, both locally and from the Internet, with no error message. After updating to .NET 3.5, I now recieve a generic error message from Windows stating:

     

    "Windows Presentation Foundation Host has encountered a problem and needs to close."

     

    Is there any additional advice that can be given?

    Tuesday, November 27, 2007 11:32 PM
  • We are discussing kennie's problem on another thread, but I wanted to provide an update about the XBAP deployment failures in general here since this thread seems to be getting a lot of hits.

    SP1 and .NET v3.5 were recently released. In a few weeks, Windows Update will start pushing SP1 to computers that have .NET 3.0 installed. PresentationHost.exe, the host process for XBAPs, now detects all known or likely registry/file permission problems causing deployment failure and triggers a Watson report. Shortly, we'll have Watson response pages set up that take users of affected computers to an automatic repair tool. This is not the ideal user experience, but it's significant progress toward eliminating these random, non-crashing failures that we could previously hear about only by direct user/developer reports. Depending on how things go, the next service pack might include the permission repair functionality in its setup program.

    Additionally, the new PresentationHost tries to turn most previously silent failures into Watson reports as well. This will give us more tangible information about any additional causes of deployment failure other than inadequate system object permissions. So, please send these error reports when prompted (no need for duplicates from the same computer). We are aware that some web server configuration problems may now lead to a "crash" in PresentationHost, but long term this is going to be beneficial since we'll have the ability to set up specific Watson response pages that help developers understand and resolve such configuration problems.

    Thanks to specific customer suggestions (including most recently DCMonkey on this tread), we were able to isolate an account migration scenario involving Small Business Server 2003 that causes the particular HKCU\Software\Classes ACL anomaly that makes ClickOnce fail in the context of PresentationHost, while nothing else on the system may seem to be affected. Of course, we'll be taking up the issue with the SBS group, trying to address the root cause. Thanks to all who provided relevant information. And credits go to our awesome Deployment tester Matt Galbraith, who was able to nail the fatal account migration/upgrade scenario.

     

     

    Wednesday, November 28, 2007 8:58 PM
  •  

    The exact cause that I identified stems from the "Small Business Server Network Configuration Wizard" that runs on the client machine when connecting to the machine.  Several menus into the wizard is one titled "Assign users to this computer and migrate their profiles".  The bottom pane of this window has a section with text saying:

     

    "Select the name from the list that represents your previous user account.  If you do not want to preserve existing settings or were not previously using this computer, click Next"

     

    To prevent this ACL problem, DO NOT set any values in the dropdown menus (i.e. all users on the machine should be set to "-- None --".  This migration causes weird SID mismatch leading to the problem described in the thread.  It may not be the only source of this issue but it seems to be the most common one in the wild.

     

    -Matt

    Wednesday, November 28, 2007 10:53 PM
  • Over the past several weeks we have been seeing more customers running into this issue with the security restriction around the registry hive. Have there been any windows updates which could cause us to start seeing this issue more frequently?

     

    Jim Wooley
    Tuesday, February 19, 2008 8:45 PM
  • Can anybody tell me how works the sandbox i need to find a link that explain it me...

    How i can give the rights for the XBAP Application?

    Thanks for the answer ^^
    Tuesday, February 19, 2008 9:15 PM
  • If you have the problem described in this thread, here's some manual steps you can take to try to fix it:

     

    Check the ACLs on all the following things:

     

    XP: File System

  • "x:\Documents and Settings\username\Local Settings\Application Data" folder and/or Deployment subfolder
  • "x:\Documents and Settings\username\Local Settings\Apps" folder.

    Vista: File System:

    - Same as above but under x:\Users\username\...

    Registry:

  • HKCR\Interface\{79EAC9C9-BAF9-11CE-8C82-00AA004BA90B} key

     

    There's a slight chance there could be other mis-ACL'ed registry keys or files.  If explicitly granting your user ACL rights to those paths doesn't work, simply run a registry monitoring tool like SysInternals Process Monitor, and look for registry or file accesses that fail.  These are the reg keys or folders you need to fix.

     

     

    HTH,
    Matt

Wednesday, February 27, 2008 5:51 PM
  • We got caught up in the v3.5 SP1 release, but the XBAP permission repair tool is finally released: http://www.microsoft.com/downloads/details.aspx?FamilyID=adb47247-4e27-4490-a153-39d8334172d9. It repairs the most commonly occurring registry & file permission problems that fail XBAP deployment. Shortly, the Watson service will start offering it to users of affected computers.
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, June 12, 2008 5:10 PM
  • I've also been encountering issues with running Xbap applictions within XP with IE 7.0.
    We are having issues with the windows PresentationHost.exe faulting.  Has anyone else experienced this issue and if so, a solution?
    In the interim, it's quite weird but seems to work, we found that if you have fiddler running, then the windows presentationhost doesn't fault and you are
    able to view the xbap application.  Anyone know why?

    Thanks.
    Friday, July 25, 2008 2:32 PM
  • Sometimes PresentationHost triggers a Watson report when downloading the deployment manifest (.xbap file) fails. This is due to lacking error UI for such situations. Normally, the browser gets the error first and reports it appropriately to the user. But due to caching, the browser may not do a real network request, and then PH will hit the error. Another similar known issue is with SSL certificate validation. PH does not let you ignore warnings/errors.

    Having Fiddler active changes the way web requests are handled. That's a likely explanation for the difference you are seeing.

    To debug your problem:
      1. Clear the browser cache and try again.
      2. Look at the web server log to see what requests it's getting when the error occurs and when it doesn't.
      3. What is the Watson bucket id? You can find it in the Windows Event Viewer, Application Section. Look for event type of 1001.
      3. Post a callstack of PresentationHost's main thread taken you get the Watson dialog. Use the Microsoft public symbols server.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, July 25, 2008 4:23 PM
  • All our users do not have admin rights.  Our issues stem around the HKCU\software\classes\software which is locked.   The fix we have been using is to delete the users usrclass.dat file and reboot.  Once they log back in all is well.

    You may to reboot first then delete the file as it is locked usually.  

    This is not ideal as we want to push an app out to 200+ users and cannot possibly fix this on all their machines.
    • Edited by Dan_Haligas Monday, August 11, 2008 8:12 PM Updated
    Monday, August 11, 2008 8:10 PM
  • Dan, I'm very interested to know whether the repair tool (linked above) works on your clients' computers. It does attempt to repair permissions for HKCU\software\classes\software. But it's possible their profiles are locked down so much that they can't change permissions of their own regkeys.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, August 12, 2008 4:09 AM
  • not really tried it because it requires admin permissions and our users do not have admin rights.  If we logged on as admin it may work, but we have over 500 users failing this way and we cannot log on as admin and run this for every user.
     
    Could we run this with a policy login script, etc?

    Tuesday, August 19, 2008 4:24 PM
  • The repair tool is meant to run under the account of the affected user. Just give it a try. It may fail to do the job, but it's extremely unlikely to cause any new problem … and there’s even a no-action switch. To get extended diagnostic output, download the tool and run it this way:

       XbapPermFix_sx.EXE /c:"XbapPermFix -v"

    In particular, it's interesting to see the permissions for HKCU\Software\Classes\Software.

    You could also include the -n switch (within the quotes) to not do any repair, just report problems.

    Any idea how your users got in that state? I suppose it is the same sys-prepped OS image that they all use…







    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, August 19, 2008 5:44 PM
  • Yes it is an image and it is on every machine.  We got the tool to work by giving admin rights (via runas to computer mgmt), staying logged in as the same user and then running your tool with run as and that user so it picks up the new admin credentials. 

    It stated there was an issue with HKCU\software\classes\software and it fixed the issue.  The user can now run.  The issue we have now is how do we do this in an automated fashion using gpo, sms, etc. to fix this issue on over 500 computers.
    Tuesday, August 19, 2008 5:55 PM
  • Also it appears that current user has not rights at all (not even read) to the HKCU\Software\Classes\Software.  Once the tool successfully runs the user has full control and read back and all works.

    Who creates this key.  My help desk guys say it does not exist until we run a click once app.  After the click once app fails it shows up with these broken ACL's.
    • Edited by Dan_Haligas Tuesday, August 19, 2008 7:51 PM Change
    Tuesday, August 19, 2008 7:50 PM
  • The key is the root of the registry part of ClickOnce's application store ("cache"). If it gets created with inadequate permissions, I guess they are inherited from the Classes key. What permissions does this key have?

    You could run the repair tool in an automated way with a command line like this:
      XbapPermFix_sx.exe /q /c:"cmd.exe /c XbapPermFix.exe"
    The /q switch suppresses the EULA, and running via cmd /c is a trick to avoid the prompt for Enter key at the end. ;-)

    I'm still interested in any clues about the cause for this particular permission anomaly. It's only the second case we've heard about (affecting this Classes\Software key), and the first investigation was inconclusive. What is the symptom you get to begin with? Also, what is the ACL on the Classes key? I think it's likely to be "broken" too, but that finding in itself would not suggest a cause--rather, the setup of this OS image, and in particular the security templates applied, and more likely to be the key. You may email me directly any relevant details.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, August 19, 2008 9:42 PM
  • The symptom is the initial post on page 1 of this thread where we get an unauthorized exception so it is like the cache is being created the first time and it does not have rights to go any farther after that and get the "Application cannot be started error".  I can reproduce this like crazy here and we have open SRX with you guys on this right now.

    The classes key looks to have the current user with full control and read.  How do I email you directly?
    Tuesday, August 19, 2008 10:15 PM