Surface 蓝屏故障分析 PDC WATCHDOG TIMEOUT 14F
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，且发生了莫名其妙的问题，多半都是由于老旧的安全软件版本导致的。
微软发布 Windows 7 等多平台版 Microsoft Edge
微软于今日发布了面向 Windows 7/8/8.1 版的 Microsoft Edge 预览，至此 Microsoft Edge 已完成了全平台版本的发布，不论您是移动设备用户，使用的是 Android 或 iOS；还是 PC 设备用户，使用的是 Windows 家族（7 ~ 10）或 macOS，现在都可以免费享用这款全新的 Microsoft Edge 浏览器。
虽然目前还是预览版，但是对于日常使用几乎是没有影响的，而且在最近发布的版本上，已经提供了中文界面的支持。
任何人只要您愿意，就可以加入到 Microsoft Edge Insider，即可访问网址：http://www.microsoftedgeinsider.com，以下是各系统版本的下载地址：
for Windows 10:
https://www.microsoftedgeinsider.com/en-us/download/
for Windows 8.1:
https://www.microsoftedgeinsider.com/en-us/download/?platform=win8dot1
for Windows 8:
https://www.microsoftedgeinsider.com/en-us/download/?platform=win8
for Windows 7:
https://www.microsoftedgeinsider.com/en-us/download/?platform=win7
for macOS:
https://www.microsoftedgeinsider.com/en-us/download/?platform=macos
for Android:
https://app.adjust.com/k50nf8b
for iOS:
Windows 应用程序的用户默认值和计算机默认值
是时候写一篇日志进行这个问题的总结了，毕竟拖得时间太久，久到连 gOxiA 自己都要遗忘掉!背景是这样的，在某个案例中需要使用“start apps”调用某个应用，也就是说某个程序内部会通过 Windows 的 Start 命令调用一个应用程序，这个应用程序可能是 chrome 也可能是 msedge，这里以msedge 早期版本为例进行说明。
当我们在 cmd 命令提示符下使用“start msedge”后，正常情况应该会默认启动基于 Chromium 开发的 Edge 浏览器，但是却遇到了错误提示，内容为“Windows 找不到文件 'msedge'，请确定文件名是否正确，再试一次”。当然现在的版本已经解决了这个问题，但是在某些极端环境下，不论是 msedge 还是 chrome ，甚至其他应用，也都可能会遭遇到该问题。
起初发现这个问题时，首先想到的分析方法就是抓取轨迹进行分析。确实有所收获，gOxiA 发现在执行“Start msedge”时会遍历注册表，并最终读取“HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\msedige.exe”路径下定义的值，而结果是未能找到该值。
此时，问题已经很明朗了，修复该路径定制的值，问题即可解决！但其实该问题却引出了更底层的一些知识，而且非常有价值。
在早先的排错过程中，gOxiA 尝试了重装应用程序，排除了安装问题。由于最早遇到的类似案例就是基于 Chrome 的，所以是先对 Chrome 进行了分析。下图是当时对 Chrome 分析时的截图，会发现执行“Start chrome”后，会遍历注册表但最终会以“HKCU\Software\MicrosoftWindows\CurrentVersion\App Paths\chrome.exe”定义的值为准。
此时，不论 HKLM 下如何定义都不会生效，但是 msedge 的情况却正好相反，HKCU 下有定义的数据，也无法被正常调用。
难道是因为安装应用程序的模式导致的？！我们知道，常见的 msi 安装包默认都会以计算机配置模式进行安装，所以需要以管理员权限执行 msi 安装包，默认应用程序会被安装在 ProgramFiles 目录下，如果你下载了 chrome 的脱机安装包，那么你会发现其安装格式为 msi。
而如果安装包是 exe 格式，以 chrome 和 msedge 为例，通过云下载数据到本地后，会启动一个真正的安装过程，而这个安装过程是面向用户配置的，也就是说当前用户即使不是管理员，也能够正常安装它们，因为应用程序数据写入到了当前用户配置文件下，而涉及注册表的部分会写入到 HKCU 下。
那么两者的区别是什么呢？其实显然易见，排除目录不谈，重点说说注册表，面向用户配置的在 HKCU 下，面向计算机配置的在 HKLM 下。
看起来执行"start msedge"时发生错误是因为它要去读 HKLM 下的定义数据，而 HKLM 下无数据，也就说明当先 msedge 应用实例是安装在计算机配置下，那么也论证了这是 msedge 的一个 bug。（PS：该问题仅发生在 msedge 早期的开发版本中，gOxiA 已经向产品组提交了 bug，目前已经修复！）
而对于之前在 Chrome 上遭遇的此类问题，可论证不是产品 bug，因为该应用程序实例是安装在用户配置下的，所以会依据 HKCU 下的定义数据执行，而发生故障是因为 HKCU 下的定义数据被“流氓”软件破坏导致的，所以必须修复 HKCU 下的定义数据。
综上，貌似这些执行机制是一个规范设计，那么就需要找出微软官方的依据进行论证。功夫不负有心人，在 Windows Shell 的官方文档中确实有相关的说明。
"Per-user default settings are specific to an individual user account on the system. If per-user default settings are present, they take precedence over corresponding per-computer defaults for that account."
具体可参考：https://docs.microsoft.com/en-us/windows/desktop/shell/vista-managing-defaults
