如何诊断 Windows 访问/权限错误
标题说的就是这样。 我正在寻找一种方法来准确确定此可执行文件正在尝试访问哪个文件/注册表项。 我尝试使用 Windows 审核功能和进程监视器 来确定故障发生的位置，但是，此故障不会产生审核失败事件或显示为拒绝访问过程监视器。
当然，如果有人经历过这种情况并且可以提供直接解决错误的解决方案，那就太好了。
背景：
我正在使用 moveuser.exe，它是 Windows Server 2003 资源工具包工具，用于转换多个 Windows XP 工作站上本地用户配置文件的安全性。
症状：
有时，moveuser.exe 无法转换配置文件的安全性，并出现错误“错误：5 访问被拒绝”。 我无法确定失败的帐户或其所在的计算机之间有任何共同点。 一台给定的计算机可能有主机 6 个配置文件，其中 5 个可以正常转换，1 个会产生错误。
有几个因素是我可以确定的：
- 我用来运行 moveuser.exe 的帐户对本地计算机和配置文件安全性要转换到的域具有完全管理员权限。
- 失败与配置文件目录中的文件权限无关（整个目录可以移动、重命名、删除或通过解决方法成功转换）。
我已经为这些情况开发了一种可靠的解决方法，但是，它相当复杂，我更愿意了解此错误的根本原因并预先纠正它。
我的解决方法（很高兴分享它，为简洁起见而省略）似乎表明该故障与 HKEY_LOCAL_MACHINE \ SOFTWARE\ Microsoft\ Windows NT \ CurrentVersion \ ProfileList 注册表项有关，但是，我无法确切确定如何/为什么。
The title says it. I'm looking for a way to determine exactly which file/registry key this executable is attempting to access. I have attempted to use Windows auditing capabilities and Process Monitor to determine where the failure is happening but, this failure does not produce audit failure events or show as access denial in Process Monitor.
Of course, If someone has experienced this and can provide a solution to resolve the error directly that would be almost as nice.
Background:
I am using moveuser.exe which is part of the Windows Server 2003 Resource Kit Tools to convert the security of local user profiles on a number Windows XP workstations.
Symptom:
Occasionally, moveuser.exe will fail to convert the security of a profile with the error "Error: 5 access denied". I have not been able to determine any commonality among the failing accounts or the computers they reside upon. A given computer may have host 6 profiles, 5 of which convert without issue and 1 which produces the error.
There are a few factors that I'm as sure as I can be about:
-The account I'm using to run moveuser.exe with has full Administrator rights to the local machine and the domain to which the profile security is being converted.
-The failure is not related to file permissions within the profile directory (the entire directory can be moved, renamed, deleted, or successfully converted via a workaround).
I've developed a reliable workaround for these cases but, it is fairly involved and I would much rather understand the root cause of this error and correct it pre-emptively.
My workaround (glad to share it, left out for brevity) seems to indicate that the failure is related to HKEY_LOCAL_MACHINE \ SOFTWARE\ Microsoft\ Windows NT \ CurrentVersion \ ProfileList registry keys but, I cannot determine exactly how/why.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您是否尝试使用“regini”命令行工具来获取管理员帐户的注册表权限？
Did you try to use the "regini" command line tool to grab registry permissions for the administrator account?
使用 FileMon 和 RegMon（现在是 Microsoft，以前是 SysInternals，仍然免费）来监视正在访问的内容、方式以及请求的权限/访问权限。
我没有方便的 URL，但 Google 搜索应该能够帮助您使用这些工具。
Use FileMon and RegMon (now Microsoft, formerly SysInternals, still free) to monitor what exactly is being accessed, how, and what rights/access are being requested.
I don't have a URL handy, but a Google search should be able to hook you up with these tools.
我会尝试一些项目。 首先，是否是用户已登录并且计算机尚未重新启动。 Microsoft 有一个名为 UPHClent 的产品 这有助于卸载不需要的用户配置单元。
接下来我想知道的是，您是否在运行 moveuser 可执行文件之前尝试重新启动。 此 对话 似乎表明这将有助于解决此类错误。
A couple items I would try. First, could it be that the user was logged in and the computer hasn't been rebooted. Microsoft has a product called UPHClent which helps in unloading unneeded user hives.
Next thing I wanted to know, is if you try rebooting before running the moveuser executable. This Conversation seems to indicate this would help with this kind of error.
发布此文两天后，我找到了问题的根源。 事实证明，正如 Rob Haupt 所建议的那样，这与卡住的用户蜂巢有关。 我正在运行的程序 moveuser 正在读取
HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ ProfileList\\ 下找到的 Refcount 键并立即结束。将 Refcount 设置为 0 立即解决了问题
推出 UPHClean 预先针对所有目标计算机几乎消除了该问题，上周我们能够在数百台计算机上成功转换配置文件。
关于 UPHClean 的一个重要说明：
我之前曾尝试安装它，但它似乎没有帮助。 我太不耐烦了， UPHClean ReadMe 显示该服务只需要时间来完成其工作。
Two days after posting this I got to the bottom of the problem. It turned out, just as Rob Haupt suggested to be related to a stuck user hive. The program I was running, moveuser, was reading the Refcount key found under
HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ ProfileList\ <SID>\and ending immediately.Setting Refcount to 0 solved the problem immediately
Pushing out UPHClean to all the target machines pre-emptively has all but elimated the problem and we were able to successfully convert profiles on several hundred machines over the last week.
An important note about UPHClean:
I'd tried installing it previously but, it didn't appear to help. I was too impatient, the UPHClean ReadMe revealed that the service just takes time to do its job.