排查 Windows 必须关闭所有会话框才能关闭 MMC 的故障问题
排查 Windows 必须关闭所有会话框才能关闭 MMC 的故障问题
在 Windows 系统的日常操作中，我们经常会遇到这样一种故障问题，当要关闭基于 Microsoft 管理控制台（MMC）的程序时，会提示我们必须先关闭所有会话框，但实际上我们已经关闭了 MMC 下对应设置的属性对话框，当反复切换几次后，才能正常关闭 MMC。
这种问题在 Hyper-V 管理器、服务管理器中尤为突出。那么造成这种问题出现的原因是什么呢？！使用何种工具能协助我们排查这类故障？！
我们可以使用微软官方工具 Spy++ 来排查这类问题，Spy++隶属于 Visual Studio 的组件，它支持绿色方式运行，利用 Spy++ 可执行下列任务：
- 显示系统对象之间关系的图形树，这些对象包括：进程、线程和窗口。
- 搜索指定窗口、线程、进程或消息的属性。
- 直接从视图中选择窗口、线程、进程或消息。
- 使用查找程序工具，通过鼠标指针定位选择窗口。
- 使用复杂消息日志选择参数设置消息选项。
对于本案例要使用 Spy++ 排查原因，需要在故障重现时启动 Spy++，然后切换到线程视图，再点击工具栏上的“Find Window”图标，通过拖拽标靶图标到要监视的 Windows 对话框上来定位窗口。
之后在弹出的 Property Inspector 对话框中单击 Synchronize 按钮，即可在 Spy++ 的线程列表视图中，同步定位到这个窗口。
接下来便可审查这个进程中的子线程，看看是否存在可疑项。本例中发现的可疑线程是必应输入法，当尝试切换输入法后，故障消失，可正常关闭 MMC。
而对于大多数安装了第三方输入法，尤其是使用搜狗输入法的朋友，相信这类问题更为常见，所以可切换关闭搜狗输入法，该问题便会消失。此外，如果你尝试使用 Spy++ 进行排错，需要注意它区分 32 和 64 位版本。有关 Spy++ 的详细信息可参考微软官方资料。
https://docs.microsoft.com/en-us/visualstudio/debugger/spy-increment-help?view=vs-2017
在 Azure 中创建 Upgrade Readiness 以管理 Windows 10 升级
在 Azure 中创建 Upgrade Readiness 以管理 Windows 10 升级
Windows 7 EOS 的日子所剩无几，更多的企业开始着手将更多的设备升级到 Windows 10，但是 IT 人员心里都非常清楚升级到新操作系统是一项非常具有挑战性的工作，已交付的众多应用程序和驱动是否兼容新的 Windows 10，是否具有潜在的兼容性问题，它们成为 IT 不能不面对的问题。
有不少同行朋友向 gOxiA 咨询微软是否提供有一种工具，可以帮助评估企业 IT 化境下的 Windows 设备，是否具体升级到 Windows 10 的能力，并且只需投入很少的精力和成本，最好基于云来实现？！
Windows 10 的 Upgrade Readiness 工具便可满足这些用户的需求，其利用 Windows 诊断数据功能，收集系统、应用程序和驱动数据以供分析，以便帮助 IT 人员确定可能阻止升级的兼容性问题。
Upgrade Readiness 提供了一种可视化的工作流程，以及丰富的计算机和应用程序库，为用户提供有关应用程序和驱动兼容性相关问题的指导和见解，以及建议的修复。并允许将收集的数据导出到常用的软件部署工具中，如SCCM。
通过下图我们来了解一下 Upgrade Readinesss 在典型场景中的工作方式。
在用户计算机上启用 Windows 诊断数据后，用户计算机通过微软数据管理服务将计算机、应用程序和驱动诊断数据发送到 Azure，在 Upgrade Readiness 就绪后，其会将分析诊断数据推送到 OMS 工作区，然后我们便可以使用 Upgrade Readiness solution 来规划和管理 Windows 10 升级。
接下来 gOxiA 将演示如何在 Azure 中创建 Upgrade Readiness，首先登录到 Azue ortal 创建资源，通过搜索框找到“Upgrade Readiness”，并创建该资源。
随后跟随向导创建OMS 工作区，如下图所示。
等待片刻待 Upgrade Readiness 创建完毕后，便可进入 Upgrade Readiness solution 面板，在 Upgrade Readiness Settings 中我们能够获取到“商用 ID 键”，复制它到后面的 Upgrade Readiness 部署脚本中，即可在客户端计算机上执行以收集相关数据。此外，我们还可以根据需要选择 Windows 10 的版本，如当前最新的为 1809，待客户端上执行脚本后，便可以执行“生成报告”。
Upgrade Readiness 部署脚本可从微软下载中心获取到，其下载地址是：
https://go.microsoft.com/fwlink/?LinkID=822966&clcid=0x409
下载到 Upgrade Readiness 部署脚本后，解压缩对于较小规模的环境，可以选择使用 Pilot 版本的脚本，并需要编辑 RunConfig.bat 将前面提到的商业ID 填写到“set commerciallDValue”中。
最后在一台准备升级到 Windows 10 的 Windows 7 设备上执行 Pilot 版本的脚本，如果运行成功，则回到 Azure Portal 的 Upgrade Readiness Settings 页面下，点击生成报告。（PS：通常需要等待一段时间报表才会生成数据。）
如下图所示便是 Upgrade Readiness 生成的分析报表，我们可以基于它管理我们的 Windows 10 升级过程。
分享一例 IE 浏览器插件故障排错过程
分享一例 IE 浏览器插件故障排错过程
前段时间 gOxiA 做了一例 IE 浏览器插件的故障排错，感觉挺有收获！特写出来与大家分享，希望能够帮助大家扩宽排错思路。
故障现象是这样，一位用户的 Windows 7 x86 操作系统，安装的 Office 2007，使用 IE11 浏览器访问一个官方电子投标网站，在编辑电子标书时提示“文件存取错误”的故障，见下图，导致无法正常编写标书。
其实这一类插件问题在国内还是非常突出的，太多陈旧的插件仍在被使用，迫使用户不得不使用过时的系统和应用程序。所以 gOxiA 的第一反应就是查找该插件的需求说明。
经确认需要 Windows 7 x86 系统，这点满足；Office 支持 2007/2010，但要求是非删减过的原版，且系统上不得安装过 WPS，而该用户的机器上安装的 Office 2007 还果真是一套精简版（PS：随机的原版 Win10 和 Office 365 因为要满足国内众网站的需求，被买电脑的给改装成了盗版精简版！）；浏览器方面支持 IE11，建议 IE8！（典型的现状问题）
OK，为了满足插件需求，卸载并清理了 Office 2007，并全新安装了 Office 2010；也将 IE11 降级到了 IE8，但经过测试发现仍旧报之前的错误。怀疑是网站问题，也打电话给对方的运维人员，被告知网站正常，其他人使用正常，还是找自身问题！
为了排除是系统问题，创建了一台虚拟机，干干净净的环境，开始测试。在不安装插件的情况下访问，会提示要求下载安装这个文档控件，且需要按照说明修改可信任站点的安全配置，并将网站添加到信任中。
作为10多年的“老司机”这些再简单不过的操作肯定不会有什么失误，但故障依旧！再次打电话求助网站运维人员得到的答案仍旧是网站正常！无奈，只能走高级排错的途径了，看看到底是什么原因。
首先捕获了操作轨迹，既然是文件存取错误，那么先搜索文档扩展名，发现果然有线索。浏览器会下载一个临时的DOC文档，并传递给Word打开。从下图找到临时文件所在位置，手动去打开看看结果！
尝试打开这个 Word 文件时提示“此文档中的某个表格已损坏”。看来问题已经与这个损坏的 Word 文档有关。
强行打开后可以确认文档内容确实有损坏，难道是 IE 下载过程发生了什么问题？！
随后对 IE 访问过程进行了抓包，分析结论是 IE 成功获取到了该 Word 文档，并未发生意外错误。
既然 IE 获取文件没有问题，传递给 Word 的过程也未有异常，说明这个插件的工作运行是正常的，唯独是这个 Word 文件自身损坏。为了能证明插件安装正常，又重新分析了操作轨迹，发现浏览器在调用 OCX 控件时确实是正常的！
至此，心里已经有谱！再次联系网站运维人员，告知分析的过程和结果，但人家硬是不承认文件有问题。最后也算不负有心人，在这个投标网站发现有些链接里也有提供这个插件使用的场景，进行了测试发现能够正常在 IE 中调用控件，在线打开并编辑 Word 文档，赶紧用手机录制了操作过程，发给对方网站运维人员，但是！！！人家还是不承认，用户最后也没办法托人买了新电脑直接去招标办公室让对方运维人员调试。后来听说招标办公室那边找后台的人重新上传了文档，问题解决！而这前后耽误了2天的时间，还好赶在开标前完成了所有的投标工作。
