gOxiA=苏繁=SuFan Blog

Windows Update 组件重置及更新常见问题解决方法

        Microsoft 将于 2020年1月14日对 Windows 7 终止支持，虽然您的电脑还可以继续工作，但是将不再提供以下内容：

• 任何问题的技术支持
• 软件更新
• 安全更新或修复

        对于 Windows 7 专业版和 Windows 7 企业版的用户，可以购买到 2023年1月为止的扩展安全更新。所以国内的很多企业还在苦苦挣扎……

        最近连发的几起安全公告使企业 IT 更加重视 Windows 更新，随之而来的是 Windows 在安装更新中所遇到的各种问题，而这些问题的根源通常还是来自日常的 IT 管理，但是今天 gOxiA 要与大家分享的不是管理方面的经验。

        当 Windows 更新发生故障问题通常可分为两类，一种是获取更新时发生问题；另一种是安装更新时发生问题。这两点在具体排错时需要注意。但通常部分问题是可以通过重置 Windows Udpate 组件来解决的，下面 gOxiA 将顺序列出重置组件以及相关问题的解决方法。

1. 如果客户端有加入域，可重新获取组策略，可以删除客户端上组策略相关的目录：GroupPolicyUsers 和 GroupPolicy，根据实际情况还可考虑删除注册表对应键值。之后使用命令“gpupdate /force”重新更新组策略。
2. 停止 Windows Update 服务（wuauserv），重新注册 Windows Update 相关组件。
   
   

   regsvr32.exe atl.dll
   regsvr32.exe urlmon.dll
   regsvr32.exe mshtml.dll
   regsvr32.exe shdocvw.dll
   regsvr32.exe browseui.dll
   regsvr32.exe jscript.dll
   regsvr32.exe vbscript.dll
   regsvr32.exe scrrun.dll
   regsvr32.exe msxml.dll
   regsvr32.exe msxml3.dll
   regsvr32.exe msxml6.dll
   regsvr32.exe actxprxy.dll
   regsvr32.exe softpub.dll
   regsvr32.exe wintrust.dll
   regsvr32.exe dssenh.dll
   regsvr32.exe rsaenh.dll
   regsvr32.exe gpkcsp.dll
   regsvr32.exe sccbase.dll
   regsvr32.exe slbcsp.dll
   regsvr32.exe cryptdlg.dll
   regsvr32.exe oleaut32.dll
   regsvr32.exe ole32.dll
   regsvr32.exe shell32.dll
   regsvr32.exe initpki.dll
   regsvr32.exe wuapi.dll
   regsvr32.exe wuaueng.dll
   regsvr32.exe wuaueng1.dll
   regsvr32.exe wucltui.dll
   regsvr32.exe wups.dll
   regsvr32.exe wups2.dll
   regsvr32.exe wuweb.dll
   regsvr32.exe qmgr.dll
   regsvr32.exe qmgrprxy.dll
   regsvr32.exe wucltux.dll
   regsvr32.exe muweb.dll
   regsvr32.exe wuwebv.dll

3. 建议删除 SoftwareDistribution 目录，它位于 Windows 目录。

4. 修复 BITS 服务，删除所有任务，为此执行“bitsadmin /reset /allusers”，然后可停止 BITS 服务（bits），重新设置服务的安全性描述符。
   
   

   sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
   sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

5. 如果怀疑网络组件异常，可执行“Netsh winsock reset”重置 WinSock。

6. 使用“Chkdsk /f /c:” 对执行磁盘检查，并修复可能出现的逻辑错误。

7. 执行“sfc /scannow” 对系统组件执行检查和修复，如果存在错误，应分析 CBS.log 对具体错误进行修复。

常见错误：

• 8007FFFF，该问题需要安装服务栈更新，可参阅 KB3177467。
• 80240037，该问题通常是使用了不支持 Windows 7 的硬件导致的。
• 80070005，典型的拒绝访问故障，可尝试关闭安全软件。
• 80073712，系统存在组件问题，需执行“系统更新准备工具”，即 KB947821，但该工具也不是万能的，如果遇到错误，需要具体分析具体处理。

        最后，友情提示企业 IT 人员，如果未执行持续和完善的 Windows 更新管理工作，那么客户端将会出现严重的碎片化问题，gOxiA 建议企业应该尽快开始到 Windows 10 的升级工作，以减少不必要的维护成本。

Windows 10 排错 PHASE1_INITIALIZATION_FAILED

        一台 Windows 10 计算机在启动过程中发生 Bug Check，提示“PHASE1_INITIALIZATION_FAILED”，且没有任何参数。微软官方资料也未对该错误有更多的解释，但可以肯定这是非常罕见的启动故障类型，因为即使通过“安全模式”也无法正常启动系统。

        用户反馈在发生故障前使用 USB 端口插入过华为手机拷贝过资料（PS：我为什么要重点提牌子呢？！），那么应该与驱动程序或系统文件损坏有关，目前只能使用 WinPE 引导进行脱机修复。

        考虑到故障是“PHASE1_INITIALIZATION_FAILED”，那么问题应该发生在“内核初始化”或“会话初始化”阶段，可参考下图（PS：虽然是 Windows 7 Boot Process，但也适用于 Windows 10）。

        在内核初始化阶段，内核将初始化数据结构和组件，启动 PnP 管理器，该管理器初始化在 OSLoader 阶段加载的 Boot_START 类型驱动程序。当内核将控制传递给会话管理器进程（smss.exe）时，SMSSInit 子阶段开始，在此子阶段期间，系统将初始化注册表，加载并启动未标记为 Boot_START 的设备和驱动程序，并启动子系统进程，当控件传递给 Winlogon.exe 时 SMSSInit 结束。

        所以，我们需要确认当前系统中安装的驱动程序，这也包含一些安全软件的逻辑驱动。如果系统是在线模式，我们可以使用设备管理器，或 Driverquery.exe 查询这些驱动程序。对于离线系统，如果你没有微软的 DaRT，那么只能使用注册表编辑器离线加载系统注册表（C:WindowsSystem32configSYSTEM）。

        然后逐个审查“HKLMSYSTEMCurrentControlSetServices”下的项，要识别启动类型则需要通过“Start”键值，这是一个 DWORD 值，具体表示如下：

• 0x00000000: SERVICE_BOOT_START
• 0x00000001: SERVICE_SYSTEM_START
• 0x00000002: SERVICE_AUTO_START
• 0x00000003: SERVICE_DEMAND_START
• 0x00000004: SERVICE_DISABLED

        此外，我们还可以从“HKLMSYSTEMCurrentControlSetControlServiceGroupOrder”获得完整的加载顺序。参考资料：https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/what-determines-when-a-driver-is-loaded

        可疑的设备驱动没发现，倒是发现了 360 相关的，以及另一个可疑的驱动，果断干掉，重启后可能会遇到 0xc0000001 故障，可以忽略重启，之后就能够进入桌面。

        简单总结一下，在 Windows 登录界面未启动前如果发生异常，则可以重点检查系统加载的驱动程序。当然，也可以对磁盘做一次扫描检测，最好再对系统组件也做一次扫描修复。

Surface 蓝屏故障分析 PDC WATCHDOG TIMEOUT 14F

        PDC WATCHDOG TIMEOUT 14F 蓝屏故障已在环境中多个型号的 Surface 上复现，包括 Surface Pro 4 和 Surface Laptop 2，且从 1803 至 1903 的 Windows 10 都未能幸免，如果继续使用 1607 肯定是很不现实，现在不管怎样，重点都先转回蓝屏分析上！

        对三台 Surface 设备的 7 个蓝屏文件进行了分析，发现均为 PDC_WATCHDOG_TIMEOUT 14F 蓝屏，且“A resiliency client failed to respond.” 生翻这句话，貌似是一个具有恢复能力的客户端发生了响应失败。

        引发蓝屏的驱动组件是 dam.sys，该驱动即桌面活动审查器，是 Windows 的一个内核模式驱动程序，如果当前系统支持 Connected Standby，则会在系统引导时加载并初始化。

        DAM 会将进程添加为系统管理的作业对象：

• 如果在会话0中创建了进程，则 DAM 会将该进程添加到受限制的作业对象。
• 如果该进程是在交互会话（会话1或更高）中创建的，则 DAM 会将该进程添加到要暂停的作业对象。

        可以理解为，当屏幕打开时，DAM 将脱离，且不会影响系统上的任务进程。当系统处于 Connected Standby 状态时，DAM会限制或暂停进程。

        综上，并结合栈的轨迹，导致 DAM.sys 引发蓝屏的原因应该是系统上的某些应用与 Connected Standby 发生冲突，出现了兼容性问题。在设备激活 Connected Standby 时，DAM 无法正确的限制或暂停某些进程，通常安全类应用都会有守护机制防止其他进程限制或挂起自己，所以最终导致 DAM 操作超时，引发蓝屏保护。

解决和缓解方案：

• 卸载或更新最近安装的应用，尤其是安全软件。
• 如果受企业安规影响，无法卸载存在兼容性的安全软件，那么缓解办法就是禁用 Connected Standby。为此，可修改注册表“HKLM\SYSTEM\CurrentControlSet\Control\Power”，将 CsEnabled 值改为 0。

        Windows 10 在兼容性方便是有目共睹的，令人满意！只是一些安全软件厂商实在是不给力，未能跟上 Windows 10 的节奏，更新底层的存在兼容问题的 API 调用，所以如果您所在的企业正在更新至 Windows 10，且发生了莫名其妙的问题，多半都是由于老旧的安全软件版本导致的。