让人抓狂的问题：运行WPF Browser Application（XBAP）导致PresentationHost（IE）崩溃

来源：互联网发布：文本相似度算法 svm 编辑：程序博客网时间：2024/05/13 19:56

前段时间刚开始接触WPF Browser Application（XBAP）时，遇到了件怪事，在公司的多台机器上都出现了在IE中运行任何XBAP程序都使IE（PresentationHost）崩溃的现象，抛出UnauthorizedAccessException异常。根据实际的跟踪发现应该是ClickOnce在GetUserStore时失败，但此时登录的用户是管理员组Administrators用户，实在想不通是怎么回事。以下是崩溃时的堆栈情况：

System.Deployment.dll!System.Deployment.Internal.Isolation.IsolationInterop.GetUserStore() + 0x44 bytes

System.Deployment.dll!System.Deployment.Application.ComponentStore.ComponentStore(System.Deployment.Application.ComponentStoreType storeType, System.Deployment.Application.SubscriptionStore subStore) + 0x2f bytes

System.Deployment.dll!System.Deployment.Application.SubscriptionStore.SubscriptionStore(string deployPath, string tempPath, System.Deployment.Application.ComponentStoreType storeType) + 0x6a bytes

System.Deployment.dll!System.Deployment.Application.SubscriptionStore.CurrentUser.get() + 0x99 bytes

System.Deployment.dll!System.Deployment.Application.DeploymentManager.DeploymentManager(System.Uri deploymentSource = {http://localhost/WPFBrowserApplication1.xbap}, bool isUpdate, bool isConfirmed, System.Deployment.Application.DownloadOptions downloadOptions, System.ComponentModel.AsyncOperation optionalAsyncOp = null)+ 0x61 bytes

System.Deployment.dll!System.Deployment.Application.InPlaceHostingManager.InPlaceHostingManager(System.Uri deploymentManifest, bool launchInHostProcess = true) + 0x6a bytes

System.Deployment.dll!System.Deployment.Application.InPlaceHostingManager.InPlaceHostingManager(System.Uri deploymentManifest) + 0x27 bytes

PresentationFramework.dll!MS.Internal.AppModel.XappLauncherApp.TryUriActivation() + 0x68 bytes

PresentationFramework.dll!MS.Internal.AppModel.XappLauncherApp.XappLauncherApp_Startup(object sender, System.Windows.StartupEventArgs e) + 0x9e bytes

PresentationFramework.dll!System.Windows.Application.OnStartup(System.Windows.StartupEventArgs e) + 0xa4 bytes

PresentationFramework.dll!System.Windows.Application..ctor.AnonymousMethod(object unused) + 0x2a bytes

经过尝试发现，在一台机器上尝试删除用户本机配置文件再重新登录（删除Document and settings目录下对应该用户的所有内容），发现可以运行成功。或者以新的用户登录，也可以成功。看来问题应该出现在用户配置文件上。
后来从微软的技术支持工程师那里得到如下信息：

运行ClickOnce的应用程序，您需要确保当前的Windows账号对下列文件系统具有读写的权限：

%userprofile%/Local Settings/Apps
%temp%/Deployment

注册表：

HKCU/ Software/Classes/Software/Microsoft/Windows/CurrentVersion/Deployment

    我仔细检查了上述相关目录和相关注册表项的权限，确定所有的权限都是完全控制，可是问题还是出现。后来使用FileMon和RegMon进行跟踪发现，发现问题是出现在注册表权限上，除了会访问到HKCU/ Software/Classes/Software/Microsoft/Windows/CurrentVersion/Deployment这个注册表项之外，还会访问到HKCU下其他一些注册表项，于是我将HKCU根目录的完全控制权限赋予该用户，问题终于得到解决。
    不过让人感到奇怪的是该用户是 Administrators组用户，居然不具备对注册表HKCU根目录的完全控制权限，所以才会导致ClickOnce无法运行下去。仔细检查了几台计算机的相关配置，才终于明白这个问题是怎么出现的：原来我们公司曾经更换过主域控制器（好像重建过用户），为了避免重新安装大量软件以及避免丢失以前的用户配置，这几台出问题的计算机都是用以前备份的Document and settings目录下的相应用户的目录内容直接恢复用户配置，虽然域名和用户名仍然跟以前一样，但是用户ID已经不同了，所以HKCU根目录的完全控制权限被赋予了一个现在并不存在的用户（以前的同名用户）而非当前用户，所以才导致出现上述问题。
    这个问题前后折腾了一个多星期才找到原因，简直让人抓狂，特写下此博客以为纪念。