Windows服务启动排错
在微软新闻组里有很多网友咨询有关Windows服务无法启动的问题，例如无法启动“Logical Disk Manager”服务。这类服务出错的现象往往是五花八门，判断起来比较麻烦，而且有些问题还无法通过查看微软知识库文章得到解决。所以这里进行一个简单的小结，帮助初学者解决常见的服务无法启动的问题。
特别提醒
在阅读本文的时候，请严格按照故障现象进行比对排错！
如果涉及到注册表操作，请务必事先备份相关注册表项，并新建还原点。
如果系统无法顺利启动，请按Reset键重新开机，然后按F8，在Windows高级启动菜单上选择“恢复到最近一次的正确配置”菜单项，这样就可以先前的HKLM\SYSTEM\ControlSet00n覆盖错误配置的CurrentControlSet（ControlSet00n中的n由HKLM\SYSTEM\Select的LastKnownGood键值指定）。
错误2：系统找不到指定的文件
1．故障现象
尝试在“服务”管理单元窗口手动启动服务是，系统提示“错误2：系统找不到指定的文件”(Error 2: The system cannot find the file specified.)，如图1所示。
2．原因分析
两种可能：
(1) 服务的可执行文件丢失或者被破坏。
(2) 服务相关注册表键值ImagePath的数值数据被篡改，导致SCM无法加载服务的可执行文件。
在“服务”管理单元窗口里可以看到每个服务的可执行文件路径，请仔细检查如图2所示的可执行文件所在路径，如果和参照系统的正确配置不符合，说明注册表键值ImagePath的数值数据有误。如果此处的配置没有问题，则说明可执行文件丢失或者被破坏。
3．解决办法
以“Task Scheduler”服务为例。
如果注册表键值ImagePath的数值数据被篡改，可以定位以下注册表项：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Schedule
在右侧定位到ImagePath键值，将其数值数据修改为正确的值，并重启系统。
或者借助sc命令：
sc config Schedule binpath= "%SystemRoot%\System32\svchost.exe -k netsvcs"
如果是可执行文件丢失或者破坏，请用正确的副本进行替换，并重启系统。对于本例来说，可执行文件是svchost，如果该文件被破坏，系统将无法正常运行。
错误1053：服务没有及时相应启动或控制请求
1．故障现象
尝试在“服务”管理单元窗口手动启动服务时，系统提示“错误1053：服务没有及时相应启动或控制请求”，如图3所示。
2．原因分析
如图2所示，可执行文件的附加命令参数配置有误，会导致问题。
3．解决办法
参照上述的方法，用sc命令或者注册表编辑器，对附加的命令参数进行排错。
错误1083：配置成在该可执行程序中运行的这个服务不能执行该服务
1．故障现象
尝试在“服务”管理单元窗口手动启动服务时，系统提示“错误1083：配置成在该可执行程序中运行的这个服务不能执行该服务”，如图4所示。
2．原因分析
该故障通常在由svchost服务宿主进程所启动的服务上发生。大家知道Windows XP SP2最多可以启动七个svchost进程实例(实际上启动六个进程实例)，分别负责启动一组服务。每个svchost实例所负责启动的服务由以下注册表项决定：
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost
其下共有七个键值：DcomLaunch、HTTPFilter、imgsvc、LocalService、netsvcs、NetworkService、rpcss和termsvcs。每个键值都定义了一个或者多个服务，也就是对应每个svchost进程实例所能启动的一组服务。
本例中“Task Scheduler”服务的可执行程序参数是“svchost.exe -k netsvcs”，对应的svchost进程在启动该服务之前，会先到HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost下的netsvcs键值里查找是否有该服务的定义，如果没有，就会出现该故障现象。
3．解决办法
很简单，首先打开该服务的属性对话框，查看其可执行程序的命令参数（本例是netsvcs），如图2所示。
然后进入以下注册表项：
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost
在右侧定位到对应的键值，本例是netsvcs，在其数值数据里添加该服务名即可，本例是Schedule，如图5所示，并重启系统。
提示 为什么通常只会启动六个svchost进程实例？都是TermService服务惹的祸！TermService(Terminal Services)这个服务非常另类，不仅仅出现在DcomLaunch组里，同时还独立出现在termsvcs组里，然而在“服务”管理单元窗口里，该服务的命令行为“svchost.exe -k DcomLaunch”，也就是说实际上并没有一个svchost进程实例负责启动termsvcs服务组！
错误126：找不到指定的模块
1．故障现象
尝试在“服务”管理单元窗口手动启动服务时，系统提示“错误126：找不到指定的模块”(Error 126: The specified module could not be found.)，如图6所示。
2．原因分析
该故障通常在由svchost服务宿主进程所启动的服务上发生。这一类的Windows服务，其实是以dll模块的形式插入某个svchost进程。如果该dll文件被破坏，或者注册表的相关键值被篡改，都可能导致问题。
这类服务所对应的Dll文件，是由HKLM\SYSTEM\CurrentControlSet\Services\ServiceName\Parameters注册表项下的ServiceDll键值所定义的(此处的ServiceName是指服务名)，如果该注册表键值出错，或者对应的Dll文件被破坏，就会导致这个问题。
在微软新闻组里有不少网友抱怨无法打开“磁盘管理”窗口，寻根溯源发现是“Logical Disk Manager”服务无法启动所导致。其中有一个case是系统被木马PCShare所感染，木马修改了“Logical Disk Manager”服务的注册表键值，把HKLM\SYSTEM\CurrentControlSet\Services\dmserver\Parameters注册表项下的键值ServiceDll的数值数据指向木马的文件“%SystemRoot%\System32\drivers\Ybfbqufe.sys”，尽管后来利用杀毒软件杀除木马，但是杀毒软件未能处理被木马篡改注册表键值，导致无法打开“磁盘管理”。
注意 不要将该故障和“错误2：系统找不到指定的文件”相混淆！
3．解决办法
对于“Logical Disk Manager”服务的问题，在以下的注册表项：
HKLM\SYSTEM\CurrentControlSet\Services\dmserver\Parameters
确保将其下ServiceDll键值的数值数据修改为“%SystemRoot%\System32\dmserver.dll”。
如果注册表键值没有问题，请确保用正确的文件副本替换原来的dll文件，并重启系统。
错误1079：此服务的帐户不同于运行于同一进程上的其他服务的帐户
1．故障现象
尝试在“服务”管理单元窗口手动启动服务时，系统提示“错误1079：此服务的帐户不同于运行于同一进程上的其他服务的帐户”，如图7所示。
2．原因分析
该故障通常在由svchost服务宿主进程所启动的服务上发生。前面说过Windows XP SP2最多可以启动七个svchost进程实例，分别负责启动一组服务。一组服务中的每个服务必须和对应的svchost进程实例运行在同一个启动帐户下。
例如Alert服务属于LocalService组的服务，其对应的svchost进程实例运行在Local Service帐户下，如果错误地将Alert服务的启动帐户修改为别的帐户，例如Local System帐户，就会报错。
3．解决办法
首先根据该服务的可执行文件路径属性找到其所属的服务组，例如Alert服务属于LocalService的服务组，然后确定同一组的其他服务的启动帐户，将其修改为相同的启动帐户即可。
错误1068：依存服务或组无法启动
1．故障现象
尝试在“服务”管理单元窗口手动启动服务时，系统提示“错误1068：依存服务或组无法启动”，如图8所示。
2．原因分析
某些服务依赖于其他服务或者驱动，只有这些依赖的服务或者驱动都启动成功，该服务才能顺利启动，否则就会报1068的错误。
3．解决办法
首先我们要对这些不能启动的依赖服务或驱动进行排错，通常来说，可能有以下的一些原因：
(1) 由第三方应用程序向系统服务添加额外的依赖服务，一旦这些额外的依赖服务出错、或者被删除，而注册表中的相关键值并没有做相应的改动，则会导致问题。
(2) 这些依赖的服务或者驱动被标志为禁用。
对于第(1)种情况，这里有一个实例(来自于微软中文新闻组)：
问题：打印机是Legend LX1+1 1201i-2401i，现在无法正常使用，在事件查看器里的错误日志如下：
事件来源: Service Control Manager
事件种类: 无
事件 ID: 7003
日期: 2006-3-22
事件: 17:57:45
用户: N/A
描述: Print Spooler 服务和下列不存在的服务存在相依的关系: LexBceS
回答：联想应该是OEM利盟的打印机，所以系统会安装利盟的驱动程序，该第三方的驱动程序会给系统的Print Spooler服务添加一个新的依赖服务LexBceS，由于某种原因，该依赖服务LexBceS破坏，连累Print Spooler服务启动失败。
可以在命令提示符窗口运行以下命令恢复Windows默认的依赖关系(Print Spooler服务默认依赖RPCSS服务)：
sc config spooler depend= RPCSS
当然，也可以打开注册表编辑器，进入以下注册表项：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Spooler
在右侧的详细窗格里找到DependOnService键值，确保其数值数据为RPCSS，删除其他任何的依赖服务。
错误1747：未知的验证服务
1．故障现象
尝试在“服务”管理单元窗口手动启动服务时，系统提示“错误1747：未知的验证服务”，如图9所示。
2．原因分析
未安装Microsoft网络客户端，就会导致某些服务无法启动，这些服务可能是WWW、FTP、IPSec Service等和网络有关的服务。
3．解决方法
安装或者重新安装Microsoft网络客户端，重新启动即可解决问题。
注意：本文部分内容参考自微软知识库。
鉴证实录系列之一：为什么“系统信息→正在运行任务”中的进程信息不可用？
引子
首先我得承认用这个Title确实有点哗众取宠，不过这也是Blog的魅力所在，在ITECN上我们可以任意发表自己对微软技术的心得体会，甚至可以发某些悬而未决、半成品的东西，只要是值得和大家分享的，都可以放上来～～扯远了，打住～～
为何取名“鉴证实录”？其实该系列的文章都取材于微软中文新闻组（所遴选的帖子大多有笔者的参与）。“鉴证实录”系列文章，将尽可能忠实地记载帖子的原文（当然会根据实际情况，加以适当的调整），同时笔者将会对其中的每个问题，尽可能地提供背景知识的解析，同时尽可能加以相应的实验论证，既保证“原汁原味”，又确保“营养丰富”……
微软中文新闻组的web地址如下，大家有任何有关微软产品的相关问题，都可以到那里交流：：
http://www.microsoft.com/China/community/dgbrowser/zh-cn/default.mspx
领衔主演
参与这次问答的一共有三位朋友，都是领衔主演，呵呵。其中一名是提问的网友，他提出一个非常棒的技术问题；其他两位是回答者，其中一位是网友Youyang，另一位就是笔者(盆盆)。在这里，非常感谢提问网友和Youyang对笔者的启发。
鉴证实录
网友：在Windows XP中启动“系统信息”程序窗口，在左侧控制台树中展开软件环境→正在运行任务，无意中发现有9个任务的路径、最小（最大）工作设置、版本、大小、开始时间、文件日期等项均显示为不可用，如图1所示。这些进程包括：alg.exe、csrss.exe、wdfmgr.exe、wmiprvse.exe、system、system idle process、svchost.exe（共有5个同名进程，其中有3个进程显示“不可用”）。因不清楚是究竟是怎么回事，特此请教大家，希望能够详细说明原因，谢谢！
Youyang：正常的，我们的系统也是相同现象，关于Svchost.exe进程，你可以看看这里：
http://support.microsoft.com/default.aspx?scid=kb;zh-cn;314056
网友：感谢Youyang的回复，我亦感觉应该没有什么问题，并且排除了系统及病毒等方面的可能因素。不过，还想请教一下为何会这样，某些进程显示为不可用？谢谢！
盆盆：system和system idle process并没有真正的进程映象，所以找不到是正常的。至于其他五个进程信息为什么找不到，可能涉及到“系统信息”这个组件的工作机理，推荐你到开发新闻组去提问，以了解更详细的信息。
我目前仅发现，除了system和system idle process和csrss.exe之外，其他几个进程都有以下的共性：
(1)都是服务的宿主进程
(2)进程的启动帐户是network service或者local service(笔者注：这些进程将会处于各自不同的Logon Session，从而具有不同的Logon SID)
Youyang：呵呵，我也准备找问题的答案。我现在脑子里面的一个想法就是，Msinfo32的所使用的线程的访问令牌没有访问某些Svchost.exe背后进程信息的权限，因此会显示出来无信息。不知道大家理解没，就像注册表中的SAM数据库，我们使用的帐户如果没有对他的Read权限的时候，是看不到内容的。
笔者注释
System和System Idle Process，都不是真正意义上的用户模式进程，它们并没有对应的映象文件，例如System进程并不存在一个对应的system.exe进程映象文件。所以“系统信息”程序无法找到它们的进程信息，这是正常的。
System进程实际上是代表内核模式线程的总和，而System Idle Process只是用来统计空闲的CPU时间。
csrss.exe进程是Windows子系统的用户模式部分，它工作在LocalSystem帐户下。
三个“不可用”的svchost进程工作在network service或者local service帐户下，Youyang网友在前面提到，可以参考知识库文章KB31456了解svchost进程的详细信息。
network service和local service帐户，是Windows XP（Windows Server 2003）新引入的帐户，和LocalSystem帐户一样，它们都不是Interactive组的成员，也就是说，不能在用户登录界面使用这些帐户进行“交互”登录。由Windows自动为这些帐户分配和管理密码，有关这些帐户的详细信息，可以参考以下微软官方网页：
http://www.microsoft.com/technet/security/topics/serversecurity/serviceaccount/sspgch02.mspx
实验论证
本文认为，Youyang朋友在最后所提到的解释应该就是问题的真正原因。接下来笔者将用实验进行论证和扩展。为了方便讲述，这里假设测试计算机上的管理员帐户为Admin，同时假设Windows XP安装在C盘。
1．准备知识
首先需要理解，进程是一个很奇妙的东东，它既可以像文件夹和打印机那样，可以对进程指定访问权限(例如谁可以query进程的信息、谁可以Terminate这个进程等等)，也就是说每一个进程都可以关联一个ACL(访问控制列表)。
然而和文件夹和打印机不一样的是，进程不但可以有ACL，同时还具有一个访问令牌（Access Token），访问令牌里定义一个帐户SID的列表和该进程所具有的一组特权(Priviledge)。
可以把进程想像成具有“双重性格”，或者高中物理所学的“光的波粒二相性”，这样就不会忘记进程的这种双重特性。
当进程（或者线程）需要访问某个共享资源（包括其他进程）时，就需要出示它访问令牌。然后安全子系统就会根据共享资源的ACL中的帐户和组，来逐个比对进程访问令牌中的帐户和组，以确认是否允许进程访问该共享资源。
要了解关于访问令牌的详细信息，请参考以下微软官方网页：
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/access_tokens.asp
2．实验工具
(1)Process Explorer：可以利用该工具来查看进程的ACL和访问令牌，可以到以下站点下载该工具：
http://www.sysinternals.com/Utilities/ProcessExplorer.html
(2)PsExec：可以利用该工具来以其他帐户身份启动某个进程，可以到以下站点下载该工具：
http://www.sysinternals.com/Utilities/PsExec.html
3．实验步骤
由于没有官方的内部文档，我们无法知道“系统信息”进程中的“正在运行任务”这个线程，到底获得什么访问令牌。所以这里我们只能假设“正在运行任务”这个线程，继承“系统信息”进程的访问令牌。
首先我们可以查看“系统信息”进程的访问令牌：
(1)以Admin帐户登录系统，启动“系统信息”程序窗口，然后打开Process Explorer，双击“系统信息”的对应进程HelpCtr.exe，切换到“Security”标签页，这就是“系统信息”进程所获得的访问令牌，如图2所示。我们可以假设“正在运行任务”这个线程，自动继承“系统信息”进程的访问令牌。
提示 尽管“系统信息”程序的对应Image文件应该是msinfo32.exe，但是通过Process Explorer监控发现，其对应的进程应该是HelpCtr.exe。
(2)接下来可以查看这些“不可用”进程的访问控制列表，首先查看一下csrss.exe进程。在Process Explorer中双击该csrss.exe进程，切换到“Security”标签页，然后单击其右下角的“Permission”按钮，即可查看csrss进程的访问权限设置。可以看到该进程只允许LocalSystem帐户访问，单击打开对话框上的“高级”按钮，还可以查看LocalSystem帐户的详细权限分配，如图3所示。
这样就可以解释为什么无法查看csrss进程信息，原来只有LocalSystem帐户才可以有权限访问csrss进程，而“系统信息”进程的访问令牌里并不包含LocalSystem帐户！
(3)接下来查看“不可用”的svchost进程的访问控制列表，在“系统信息”窗口里记下“不可用”svchost进程的PID，然后在Process Explorer窗口里打开该进程的权限查看窗口，如图4所示。
和csrss进程相比，除了LocalSystem帐户外，svchost进程的访问控制列表中还包含了一个未知帐户SID（本例是S-1-5-5-0-35860）。实际上这是该svchost进程的Logon SID，也就是该svchost进程所在登录会话的SID。也就是说，只要是在同一个登录会话里运行的进程，都能访问该svchost进程的信息。
对比一下图2，发现“系统信息”进程的访问令牌中的Logon SID是S-1-5-5-0-40881，和svchost进程ACL中的Logon SID不同，这就是为什么该svchost进程的信息不可用的原因！
用同样的方法，可以找到alg和wdfmgr.exe的进程信息不可用的原因。
提示 关于Logon SID和其他内置SID的详细信息，可以参考以下的微软官方网页：
4．提升系统信息的启动身份
为了证明以上的结论，还需要进行逆向验证。
由于以上“不可用”进程，都允许LocalSystem帐户访问其进程信息，所以这里我们尝试用LocalSystem帐户的身份启动“系统信息”进程，然后查看是否可以正常显示进程的信息。
(1)要以LocalSystem帐户身份启动进程，可以借助PsExec，可以在CMD窗口运行以下命令，以LocalSystem帐户的身份启动“系统信息”进程：
PsExec -d -i -s "C:\Program Files\Common Files\Microsoft Shared\MSInfo\msinfo32.exe"
(2)现在可以看到，能够访问几乎所有进程的信息（除system和system idle process之外），如图5所示。
而如果以普通用户的身份启动“系统信息”程序（可以借助runas或者PsExec命令），则可以发现有更多进程的信息现在都变成“不可用”，如下图所示。您能说出问题的原因吗？
5．如何设置进程的权限
我知道不少朋友已经跃跃欲试，想通过Process Explorer来修改进程的权限。但是让人沮丧的是，结果会是“拒绝访问”。不过不要紧，我们可以借助Windows Server Resource Kit Tools工具包中的SubInAcl来设置进程的访问权限。这里以alg.exe为例：
(1)打开命令提示符窗口，运行以下命令：
SubInAcl /process alg.exe /grant=Admin=F
(2)运行以下命令，查看alg.exe进程现在的权限设置，命令结果如下：
C:\>SubInAcl /process alg.exe /display
========================
+Process alg.exe - 1840
========================
/control=0x0
/owner =local service
/primary group =local service
/audit ace count =0
/perm. ace count =3
/pace =S-1-5-5-0-55078 ACCESS_ALLOWED_ACE_TYPE-0x0 AccessMask=0x1f0fff
/pace =system ACCESS_ALLOWED_ACE_TYPE-0x0 AccessMask=0x100201
/pace =testxp\admin ACCESS_ALLOWED_ACE_TYPE-0x0 AccessMask=0x1f0fff
Elapsed Time: 00 00:00:00
Done: 1, Modified 0, Failed 0, Syntax errors 0
Last Done : alg.exe - 1840
可以看到，现在Admin帐户对alg.exe进程具有完全控制权限。
(3)打开“系统信息”窗口，应该可以看到alg进程的详细信息了！
6. Process ACL Internals
阅读了《Windows Internals》和以下MSDN文章，可以了解到Windows进程是调用CreateProcess函数创建的，其中的lpProcessAttributes参数“貌似”可以自定义进程的访问权限，这大概可以解释为什么csrss和winlogon进程都是smss进程的子进程，却会有不同访问权限(winlogon进程直接继承父进程的ACL，而csrss进程则有不同的ACL)。然而笔者本人对开发方面的内容不了解，还望诸兄多多加以指正，非常感谢！
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp
悬而未决
到这里为止，已经可以解释为什么“系统信息”窗口无法列出某些进程的信息。
但是以下的两个问题，还是让笔者觉得疑惑不解：
(1)Process Explorer获得的是和“系统信息”进程一样的访问令牌，为什么它可以查看所有进程的详细信息？是不是其线程可以模拟（Impersonate）相关进程的访问令牌？
另注 MVP Smallfrogs的提示是：Process Explorer可能使用AdjustTokenPrivileges这个API函数，在自己进程的访问令牌里激活了SeDebugPrivilege特权，如下图所示。由于这个令牌的存在，使得Process Explorer能够绕过进程的ACL，对进程进行枚举。
(2)在即将粉墨登场的Windows Vista上，如果以提升特权运行“系统信息”窗口，这个“Bug”似乎消失了，这又是为什么？微软似乎不应该去逐个调整这些进程的ACL，因为这样既吃力不讨好、又不利于安全。
“误操作导致无法打开组策略”之本机解决法
本文是以下的文章的姐妹篇（感谢Heelen的Comment）：
http://blogs.itecn.net/blogs/ahpeng/archive/2005/11/01/NoGpedit1.aspx
这里就简单讨论一下如何在本地计算机上进行恢复。
该问题的难点在于我们可能将面对一个非常苛刻的环境，考虑这样一个近乎极端的可能性：用户在组策略里设置仅允许运行某个无关紧要的应用程序，这将会导致无法运行regedit、组策略管理单元、记事本、系统还原等几乎所有的组件，这种可能性不是没有。这样的话，留给我们的排错空间就非常小。那么如果碰到这种情况，又该如何对付？
这里介绍以下两种方法：
一、新建用户法
这种方法适用于Windows XP SP2，在SP2下只能在用户配置下启用“只运行许可的Windows程序”策略项，而删除了在计算机配置下的相应策略项。这为我们排错提供了很大便利。
(1)我们可以在控制面板里打开“用户帐户”组件，新建一个管理员帐户，假设是Test。
(2)打开我的电脑，定位到以下目录：
C:\WINDOWS\system32\GroupPolicy\User
重命名其下的Registry.pol文件。
(3)注销当前用户，登录到新建的Test帐户，现在可以打开组策略管理单元了，修改回原来的配置即可。
疑难解答
1.为什么该方法能够奏效？
原来组策略的”用户配置“部分的策略项，保存在C:\WINDOWS\system32\GroupPolicy\User\Registry.pol文件里，同时“用户配置”的策略只能在用户登录后才能加载到注册表（HKEY_CURRENT_USER\SOFTWARE），重命名Registry.pol文件后，“用户配置”部分对新建用户就无效，可以在该新建用户下将组策略修改回原来值。
2.为什么可以启动“用户帐户”组件？
该策略项并非可以阻止一切程序或者组件运行，而是只能阻挡从资源管理器中启动的进程，而不能阻止由系统启动的进程（例如任务管理器），也不能阻止从CMD命令行窗口启动的进程（如果允许运行cmd的话）。
二、离线修改注册表
如果是Windows 2000计算机，则可以在“计算机配置”下启用“只运行许可的Windows程序”策略项，那么以上方法就不可以使用了。因为“计算机配置”下的策略会加载到HKEY_LOCAL_MACHINE\Software中，在其他用户登录前就已经生效。这时候我们可以借助第三方工具Offline NT Password & Registry Editor，进行注册表的离线修改。
可以到以下站点下载免费的Offline NT Password & Registry Editor：
http://download.myrice.com/arts/dn01/dn0107/31508.html
(1)恐怕只能在其他计算机上下载该工具，并制作一张启动软盘。
(2)用该软盘启动该故障计算机，在命令行下离线加载Software注册表配置单元，并删除以下的注册表项：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer\RestrictRun
(3)重启系统，就可以解锁。
疑难解答
1.如何知道该策略项所对应的注册表项和键值？
“计算机配置”部分的策略保存在C:\WINDOWS\system32\GroupPolicy\Computer\Registry.pol文件里，用记事本打开该文件，即可看到每个策略项所对应的注册表项和键值。
注意
根据MVP刘晖的提醒，其实只要在安全模式下登录到Administrator帐户环境下，即可绕过软件限制策略。本文只是为了提供一种解决问题的思路。
“误操作导致无法打开组策略”之局域网解决法
在微软中文新闻组里有网友问这么一个问题：在组策略→用户配置→管理模板→系统的“只运行许可的Windows程序”策略项里指定当前系统能够运行的应用程序，考虑到应该允许组策略的运行，所以把“gpedit.msc”添加到该策略项中，但是结果发现无法再也打开组策略窗口。
原来打开组策略的实质是启动MMC进程，然后加载gpedit.msc管理单元，所以在这里应该添加mmc程序，而不是gpedit.msc。如果添加了gpedit.msc，而不是mmc，导致系统无法启动mmc进程，就会导致无法打开组策略窗口。
遇到这类问题，比较容易想到的办法就是借助局域网的计算机打开故障系统的组策略管理单元，然后将策略项修改回原来的配置。
要使用该恢复方法，必须满足以下的使用条件：
(1) 该故障计算机必须处于局域网的环境中。
(2) 该故障计算机上的防火墙必须经过适当的配置，以允许远程访问组策略工具。
(3) 该故障计算机必须没有禁止管理员帐户从网络登录的权利。
(4) 该故障计算机上必须禁用“简单文件共享”。
(5)该故障计算机必须是Windows XP Pro或者Windows 2000。
恢复过程
假设故障计算机的计算机名为NoGpedit，位于工作组环境中，其上的管理员帐户名为Admin，密码为Passwd。假设局域网的另外一台正常计算机名为Test。
(1)在局域网计算机Test上打开运行对话框，并运行以下命令：
control userpasswords2
(2)在打开的对话框上切换到“高级”标签页，并单击其上的“管理密码”按钮。
(3)在打开的“存储用户名和密码”对话框上，单击“添加”按钮，在打开的对话框上输入NoGpedit计算机名和帐户名、密码，保存即可。
即可在Test计算机上获得NoGpedit计算机的管理员帐户Admin的凭据。
(4)在局域网计算机Test上的“运行”对话框里输入以下命令并回车：
gpedit.msc /gpcomputer:"NoGpedit"
(5)在Test计算机上打开NoGpedit计算机的组策略编辑窗口，修改相应的策略项回默认值即可。
(6)注销NoGpedit计算机，重新登录，结果即可生效。
类似方法：如果安全策略禁止所有管理员帐户本地登录，可以在局域网计算机上借助Ntrights命令远程给管理员组帐户赋予适当的本地登录的权利。
注意
根据MVP刘晖的提醒，其实只要在安全模式下登录到Administrator帐户环境下，即可绕过软件限制策略。本文只是为了提供一种解决问题的思路。
另类方法破解管理员密码
技术难度：Level 200
版权声明：如需转帖或者登载，请与pen.aihua AT gmail.com联系
重要说明：本方法在Windows XP环境下测试通过，有兴趣的朋友可以尝试在Windows 2000下进行测试。
原理简述：在正常计算机上加载故障计算机的SYSTEM配置单元，然后通过修改注册表将一个批处理文件安装为服务（以LocalSystem权限运行），在开机时自动运行，新建一个管理员帐户。
如果遇到管理员密码遗忘的问题，常见解决方法是采用之前创建的密码重设盘进行恢复（仅限于Windows XP），或者借助ERD Commander维护光盘中的LockSmith，或者O&O BlueCon进行密码重设。
这里介绍一个另类的方法，将一个添加新用户的批处理文件安装为系统服务，该服务会在系统登录之前自动运行，这样我们就可以利用新建的用户登录系统。
下面简单介绍步骤：
（1）新建一个批处理文件AddUser.bat，内容如下：
@echo off
net user test /add
net localgroup administrators test /add
（2）利用Windows 98启动盘引导故障计算机，然后复制出C:\WINDOWS\system32\config\system文件。并将先前创建的AddUser.bat批处理文件复制到C盘根目录下。
如果C盘为NTFS格式，则需要加载NTFSDOS Pro，下载地址如下：
http://www.sysinternals.com/Utilities/NtfsDosProfessional.html
如果C:\WINDOWS\system32\config\system文件容量超过软盘的剩余空间，则需要在DOS下加载USB驱动，以便可以将system文件复制到USB存储器里。
也可以将故障计算机的硬盘挂接到正常的计算机，以便复制出C:\WINDOWS\system32\config\system文件。
（3）在正常的计算机上打开注册表编辑器，然后选中HKEY_LOCAL_MACHINE，并单击文件、加载配置单元，定位到先前复制出的system配置单元文件，并指定加载到HKEY_LOCAL_MACHINE\Test System。
（4）定位到以下键值，并记下该键值的数值数据x，该键值记录故障计算机默认加载的ControlSet00x（例如是ControlSet001）。
HKEY_LOCAL_MACHINE\Test SYSTEM\Select\Default
（5）根据步骤（4）所记录的数值，展开以下注册表项：
HKEY_LOCAL_MACHINE\Test SYSTEM\ControlSet00x\Services
（6）在其下新建一个注册表项AddUser。
（7）在新建的HKEY_LOCAL_MACHINE\Test SYSTEM\ControlSet00x\Services\AddUser注册表项下新建以下键值：
类型：DWORD值，名称：ErrorControl，数值数据：0x1
类型：可扩充多字符串值，名称：ImagePath，数值数据：C:\AddUser.bat
类型：字符串值，名称ObjectName，数值数据：LocalSystem
类型：DWORD值，名称：Start，数值数据：0x2
类型：DWORD值，名称：Type，数值数据：0x20
这样就可以新建一个AddUser服务，以LocalSystem帐户的身份启动，类型为“自动”。
（8）修改结束以后，单击文件、卸载配置单元，保存所做的设置。
（9）将修改好的system文件复制回故障计算机。
（10）重启系统，并用Test用户登录系统，然后重设管理员密码，并删除HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AddUser注册表项。
注意：尽管在事件查看器里会提示新建的AddUser服务启动失败，但是实际上该服务确实可以生效。
启用了SYSKEY，但是将密钥软盘丢失了，怎么办？
SYSKEY的Mode 2是将启动密钥（Start Key）保存在软盘里，如果没有启动密钥，将无法解密SAM数据库。
注意不能使用故障恢复控制台，因为SAM数据库被加密，一样会被锁住。
请尝试以下方法，恢复注册表配置单元：
一、系统还原已经启用
如果Windows XP启用了系统还原，那么可以借助启用SYSKEY之前的还原点进行操作，方法有以下两种：
1． ERD Commander 2005
【该方法已经测试通过】
如果能够恢复到启用SYSKEY之前的还原点，那么这个问题就能得到解决，这里的关键是能够Offline访问系统还原功能。
可以借助ERD Commander 2005来离线访问Windows XP的系统还原。
用ERD Commander 2005恢复光盘引导系统，进入Winternals桌面以后，首先备份重要数据，例如C:\Documents and Settings\UserName\Desktop（这里的UserName要用你的工作帐户名称代替）下的文件。
然后启动Winternals自带的System Restore，选择一个以前的还原点恢复即可。
?
2． 借助还原点的注册表备份
【该方法未经测试，请慎用】
如果没有ERD Commander 2005，可以借助WIN98启动盘，如果C盘是NTFS，则需要借助NTFSDOS Pro软盘，以便能够访问NTFS分区。然后进入实模式DOS环境下，利用启用SYSKEY以前的还原点，将注册表配置单元恢复到原来的状态。
进入实模式DOS环境后（根据实际情况，可能需要借助NTFSDOS Pro挂载启动分区），然后进入系统还原的工作目录C:\System Volume Information，当然你得先用dir命令显示其8.3短文件名。然后参考KB307545的“第二部分”恢复注册表配置单元（唯一的区别在于，您只能“屈尊”在DOS下完成）。
http://support.microsoft.com/kb/307545/zh-cn
注意 恢复以后，在该还原点以后安装的驱动和应用程序可能需要重新安装。
二、系统还原已经禁用
3．借助初始安装的注册表备份
【该方法已经测试通过】
借助WIN98启动盘＋NTFSDOS Pro软盘进入实模式DOS环境，将C:\WINDOWS\repair目录下的注册表配置单元覆盖C:\WINDOWS\system32\config目录下的同名文件，以恢复到初始安装时的注册表配置。具体方法请参考KB307545的第一部分。
?
[Windows 2000]为什么把用户帐户从guests组改为users组，原来的桌面设置会丢失？
问题描述：
（原样提供）
在win2000下，有一个帐号emp是属于user组的，某天我把emp帐号改成了guest组。
后来在某人的强烈要求下，我又把emp帐号改回到user组，这时候问题来了,emp帐号桌面上的文件、桌面背景都不见了，我的文档中的文件也没有了，就好像这个emp帐号是刚刚才新建并第一次登陆的样子。
现在某人要和我拼命！
我现在很郁闷，就是不知道为什么会这样！
原因解释：
这可能是Windows 2000的一个bug，我做了两个测试，分别在Windows 2000 SP4中文版和Windows XP SP2中文版下进行实验，实验结果是：
1. 在Windows 2000 SP4下确实会存在这个问题
2. 在Windows XP下不会出现这个问题。
由于时间关系，我没有对其他语言版本、其他Service Pack版本进行全面测试，不过结论应该类似。
简单原因解释如下：
emp用户的配置文件，包括桌面配置、我的文档、收藏夹等，是保存在C:\Documents and Settings\emp文件夹里，当将emp从guests组组改为users时，Windows 2000会自动删除该文件夹（当将emp用户从users组改为guests组时，这种情况不会发生）。
重新启动Windows 2000时，系统会自动从配置文件的模板C:\Documents and Settings\Default User里复制一份到新建的C:\Documents and Settings\emp文件夹。这样，您就会发现原来的用户配置信息全部丢失。
该问题无法进行修补，您只能按照以下方法进行预防：
在将用户所属组从guests更改为users组之前，需要事先对C:\Documents and Settings\emp文件夹进行备份，这里面重要的是，要实现带ACL的备份，这里推荐两种方法：
1.? 用xcopy命令
管理员登录，打开命令提示符，运行以下命令：
xcopy /s /e /k /h /o "C:\Documents and Settings\emp" "C:\Documents and Settings\empbak"
等修改emp用户所属组以后，将复制的empbak目录重命名为emp即可。
2. 打开系统属性对话框，切换到“用户配置文件”标签页，选中emp配置文件，单击“复制到”按钮，指定复制的路径和文件名即可。
以上问题在Windows XP下不会发生。
Windows XP启动黑屏的一个实例分析
操作系统：Windows XP Pro
难度等级：Level 100
案例来源：微软中文新闻组（Windows XP）
排错记录：
问题摘要：我的windows xp pro (英文版）面对了在启动 Windows时计算机停止响应并出现黑屏的问题。我有看过KB314503，寻求解决方案可是他们所提供的我都尝试了都无效。
步骤1：
（1）初步分析：KB314503介绍了出现Windows Logo前的启动故障排错方法，既然该方案无效，则可能用户并非在该阶段启动出错。
（2）收集信息：询问用户启动出错的阶段，属于以下的哪个阶段：
a. 系统POST时出错
b. 出现Windows Logo前出错
c. 出现Windows Logo后出错
d. 帐户登录后出错
（3）用户反馈：属于阶段c，在出现Windows XP Logo时系统黑屏。（这也是KB314503无法解决该case的原因）
步骤2：
（1）原因分析：问题可能是由于某个驱动或者服务所引起。
（2）推荐方案1：开机按F8，选择“Last Known Good”，系统会自动从HKEY_LOCAL_MACHINE\SYSTEM\ControlSet00x里读取上次正确启动的配置信息，这里的x由HKEY_LOCAL_MACHINE\SYSTEM\Select下的LastKnownGood键值所指定。
用户反馈：无效
（3）推荐方案2：重启系统按F8，选择安全模式，看看能否登录系统。
用户反馈：安全模式下无法登录系统，每次到了AGP440.SYS就停止不动了。
（4）推荐方案3：借助Windows XP安装光盘引导系统，登录到Recovery Console，然后在命令提示符下运行listsvc，确认系统里有AGP440驱动，然后运行disable AGP440禁用该服务，设置完毕，重启系统。
用户反馈：问题解决。
补充：还可以开机按F8，在高级启动菜单里选中“Enable Boot Logging”，等系统启动失败后，利用Windows XP安装光盘引导系统，在故障恢复控制台下用more命令检查%systemroot%\ntbtlog.txt（引导日志文件），找出问题原因。
