HOWTO: 解决 远程桌面连接已停止工作 的故障问题
HOWTO: 解决 远程桌面连接已停止工作 的故障问题
故障现象是用户打开“远程桌面连接”程序去登录一台计算机，连接过程中该程序发生错误，提示“远程桌面连接 已停止工作”，如下图所示。
对于此类应用程序发生崩溃的故障问题，通常可展开详细信息查看故障程序中具体的出错模块进行排查。也可以在事件查看器中的应用事件日志中查找具体错误信息。
但是本案例中，导致 mstsc.exe(远程桌面连接)的错误模块是 ntdll.dll，由于是系统核心文件，且系统未出现其他异常，故怀疑是 ntdll.dll 加载和处理其他驱动动态链接库文件时发生了错误。
但是该如何查看 mstsc.exe 加载的动态链接库呢？！好在 Windows Error Reporting（WER） 为我们记录了相对详细的信息，可用于进一步的排错。首先通过事件查看器找到“Windows Error Reporting”日志，打开日志查看 WER 存储的具体位置，通常位于当前用户配置文件目录下: “\AppData\Local\Microsoft\Windows\WER\ReportAchive”。
文件名为 Report.wer，此文件使用 UTF-16LE有签名 编码，可以使用一些第三方的文本编辑器打开查看，当然也可以用系统自带的记事本，但是显示效果惨不忍睹！
此外，还可以使用第三方的 WER 查看器，比较有名的是 NirSoft 出品的 AppCrashView 工具。（PS：使用参数 /ReportsFolder <Folder> 可以直接定位打开 WER 目录）
通过分析发现，mstsc 在载入 HP1005 驱动时发生了错误，是导致本次崩溃的罪魁祸首！解决方法是在通过远程桌面连接前，修改本地资源选项，不要勾选打印机。如果此打印机不再使用，建议直接卸载驱动！
使用 Microsoft Authenticator 轻松管控 Microsoft Account
使用 Microsoft Authenticator 轻松管控 Microsoft Account
微软旗下很多产品和服务都已经支持双重身份验证，而 Microsoft Authenticator（Microsoft验证器）应用适合于使用双重验证来保护个人或工作账户的用户，或者想要不输入密码即可登录到个人 Microsoft Account（Microsoft 账户）的Android 和 iOS 用户。
当启用双重验证后，使用账户登录时，第一步会输入密码，第二步是使用手机上的应用进行验证。这样可以起到保护账户安全的作用，即一旦账户密码丢失，被人盗用去访问敏感信息时仍旧需要通过手机再次进行身份验证，这样安全性就会提高。
此外，借助 Microsoft Authenticator 还能实现免密码输入进行账户的登录，这一特性是 gOxiA 非常喜欢的！由于要在一些非受信任设备上使用Microsoft Account 或 Office 365 Account 登录微软产品或在线服务，输入密码会非常不安全，但在登录界面选择“改为使用 Microsoft Authenticator 应用”则会非常轻松和安全，只需通过 Microsoft Authenticator 应用验证即可，而无须输入账户密码。
如果要对双重验证以及Microsoft Authenticator 应用进行设置，可以访问微软官方站点（https://account.live.com/proofs/Manage/additional）进行配置。
Microsoft Authenticator 支持 Windows Phone、Android 和 iOS，可点击下面的链接访问官方应用商店下载。
Windows Phone: https://www.microsoft.com/zh-cn/store/p/microsoft-authenticator/9nblgggzmcj6?rtc=1
Android: https://play.google.com/store/apps/details?id=com.azure.authenticator
HOWTO: 解决无法打开 Excel 表格中 URL 的故障问题
HOWTO: 解决无法打开 Excel 表格中 URL 的故障问题
最近遇到一个比较典型的故障问题，排错过程跌宕起伏，事后感觉挺有代表性，决定拿出来与大家分享。故障环境是一台 Windows 10 + Office 2016 的加域设备。用户打开一个 Excel 文档，表中有一列文本包含 URL 超链接，可通过点击该文本启动 IE 去访问指定的网址。但是实际在点击链接后会提示“无法打开http://……无法下载您要求的信息。”
对其他链接进行了尝试，均提示相同的警告，但是手工新增加一个文本链接，却访问正常。之后将故障网址复制出来，粘贴到 IE 中再次访问，发现能够到达对方的服务器，但返回了“403 Forbidden”，可是将网址复制到其他浏览器，如：Edge、Chrome 中访问却是正常的。再回顾 IE 访问故障界面，发现地址栏中的中文路径在403反馈中显示的是一段乱码。说明故障的原因是由网址中包含的中文字符导致的，通常这类问题是由字符编码错误引发的。
为了求证错误，gOxiA 对正常和异常访问的 Web 数据进行了抓包，以做进一步的分析。如下结果，分析发现中文字符确实被进行了编码，但是异常访问的 Web 数据中所包含的第二次 URL 请求出现了变化，编码字符有异常，前后不符。
- 正常访问：
- 异常访问：
另外比较奇怪的是为什么会发起两次 HTTP 请求呢？！对两次访问的发起代理程序进行了分析，发现用户在 Excel 中点击 URL 时，Excel 发起了 HTTP 请求，且提交的 URL 编码是正确的。
但是，在传递给 IE 后，却被 IE 重新编码成了错误的 URL 。
至此，可以判定是因为 IE 提交的含中文字符 URL 的编码问题引发的此次故障。而中文编码问题通常出在 Windows 和 Linux 系统之间，多数原因是 Windows 提供的中文编码默认为 GB2312，而 Linux 使用的是 UTF-8，所以需要强制 IE 使用 UTF-8 来提交 URL，即可解决该问题。
但是，在执行配置操作时发现，IE 的“以 UTF-8 形式发送 URL 路径”选项被锁定了，无法修改！且明确提示“某些设置由系统管理员进行管理”。做进一步分析，确认系公司域下发的组策略所谓，不知道为什么要禁用这个选项，实属奇葩！
通知 AD 运维团队修改 GPO 不切实际，只能另寻出路！于是对 Excel 中点击 URL 的操作进行了抓包，筛选出来4000多行数据，“功夫不负有心人”在位于“HKCU\Software\Microsoft\Office\16.0\Common\Internet”下发现了一个有价值的注册表键“Encoding”，既然隶属于 Office，也就意味着可以通过 Office 选项对文档的编码进行定义。
最后，在 Excel 高级选项的 Web 选项中找到了切换文档编码的设置。即，进入 Excel 选项，依次点击“文件-选项-高级”，在右侧窗口中向下拖动至“常规”，找到“Web选项”，进入。
在“Web选项”下，切换至“编码”选项卡，找到“将此文档另存为”选项，从下拉框中找到“Unicode(UTF-8)”，点击“确定”完成设置，保存当前文档重新打开再点击 URL 尝试，故障消失。
