Quantcast
Channel: gOxiA=苏繁=SuFan Blog
Viewing all 289 articles
Browse latest View live

分享一例 IE 浏览器插件故障排错过程

$
0
0

troubleshooting

分享一例 IE 浏览器插件故障排错过程

        前段时间 gOxiA 做了一例 IE 浏览器插件的故障排错,感觉挺有收获!特写出来与大家分享,希望能够帮助大家扩宽排错思路。

        故障现象是这样,一位用户的 Windows 7 x86 操作系统,安装的 Office 2007,使用 IE11 浏览器访问一个官方电子投标网站,在编辑电子标书时提示“文件存取错误”的故障,见下图,导致无法正常编写标书。

1

        其实这一类插件问题在国内还是非常突出的,太多陈旧的插件仍在被使用,迫使用户不得不使用过时的系统和应用程序。所以 gOxiA 的第一反应就是查找该插件的需求说明。

        经确认需要 Windows 7 x86 系统,这点满足;Office 支持 2007/2010,但要求是非删减过的原版,且系统上不得安装过 WPS,而该用户的机器上安装的 Office 2007 还果真是一套精简版(PS:随机的原版 Win10 和 Office 365 因为要满足国内众网站的需求,被买电脑的给改装成了盗版精简版!);浏览器方面支持 IE11,建议 IE8!(典型的现状问题)

        OK,为了满足插件需求,卸载并清理了 Office 2007,并全新安装了 Office 2010;也将 IE11 降级到了 IE8,但经过测试发现仍旧报之前的错误。怀疑是网站问题,也打电话给对方的运维人员,被告知网站正常,其他人使用正常,还是找自身问题!

        为了排除是系统问题,创建了一台虚拟机,干干净净的环境,开始测试。在不安装插件的情况下访问,会提示要求下载安装这个文档控件,且需要按照说明修改可信任站点的安全配置,并将网站添加到信任中。

2

        作为10多年的“老司机”这些再简单不过的操作肯定不会有什么失误,但故障依旧!再次打电话求助网站运维人员得到的答案仍旧是网站正常!无奈,只能走高级排错的途径了,看看到底是什么原因。

        首先捕获了操作轨迹,既然是文件存取错误,那么先搜索文档扩展名,发现果然有线索。浏览器会下载一个临时的DOC文档,并传递给Word打开。从下图找到临时文件所在位置,手动去打开看看结果!

3

        尝试打开这个 Word 文件时提示“此文档中的某个表格已损坏”。看来问题已经与这个损坏的 Word 文档有关。

4

        强行打开后可以确认文档内容确实有损坏,难道是 IE 下载过程发生了什么问题?!

5

        随后对 IE 访问过程进行了抓包,分析结论是 IE 成功获取到了该 Word 文档,并未发生意外错误。

6

        既然 IE 获取文件没有问题,传递给 Word 的过程也未有异常,说明这个插件的工作运行是正常的,唯独是这个 Word 文件自身损坏。为了能证明插件安装正常,又重新分析了操作轨迹,发现浏览器在调用 OCX 控件时确实是正常的!

7

        至此,心里已经有谱!再次联系网站运维人员,告知分析的过程和结果,但人家硬是不承认文件有问题。最后也算不负有心人,在这个投标网站发现有些链接里也有提供这个插件使用的场景,进行了测试发现能够正常在 IE 中调用控件,在线打开并编辑 Word 文档,赶紧用手机录制了操作过程,发给对方网站运维人员,但是!!!人家还是不承认,用户最后也没办法托人买了新电脑直接去招标办公室让对方运维人员调试。后来听说招标办公室那边找后台的人重新上传了文档,问题解决!而这前后耽误了2天的时间,还好赶在开标前完成了所有的投标工作。


在 Azure 中创建 Upgrade Readiness 以管理 Windows 10 升级

$
0
0

在 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”,并创建该资源。

0

        随后跟随向导创建OMS 工作区,如下图所示。

1

2

        等待片刻待 Upgrade Readiness 创建完毕后,便可进入 Upgrade Readiness solution 面板,在 Upgrade Readiness Settings 中我们能够获取到“商用 ID 键”,复制它到后面的 Upgrade Readiness 部署脚本中,即可在客户端计算机上执行以收集相关数据。此外,我们还可以根据需要选择 Windows 10 的版本,如当前最新的为 1809,待客户端上执行脚本后,便可以执行“生成报告”。

4

        Upgrade Readiness 部署脚本可从微软下载中心获取到,其下载地址是:

https://go.microsoft.com/fwlink/?LinkID=822966&clcid=0x409

        下载到 Upgrade Readiness 部署脚本后,解压缩对于较小规模的环境,可以选择使用 Pilot 版本的脚本,并需要编辑 RunConfig.bat 将前面提到的商业ID 填写到“set commerciallDValue”中。

5

        最后在一台准备升级到 Windows 10 的 Windows 7 设备上执行 Pilot 版本的脚本,如果运行成功,则回到 Azure Portal 的 Upgrade Readiness Settings 页面下,点击生成报告。(PS:通常需要等待一段时间报表才会生成数据。)

3

        如下图所示便是 Upgrade Readiness 生成的分析报表,我们可以基于它管理我们的 Windows 10 升级过程。

6

排查 Windows 必须关闭所有会话框才能关闭 MMC 的故障问题

$
0
0

troubleshooting

排查 Windows 必须关闭所有会话框才能关闭 MMC 的故障问题

        在 Windows 系统的日常操作中,我们经常会遇到这样一种故障问题,当要关闭基于 Microsoft 管理控制台(MMC)的程序时,会提示我们必须先关闭所有会话框,但实际上我们已经关闭了 MMC 下对应设置的属性对话框,当反复切换几次后,才能正常关闭 MMC。

hyper-v_mmc_error

        这种问题在 Hyper-V 管理器、服务管理器中尤为突出。那么造成这种问题出现的原因是什么呢?!使用何种工具能协助我们排查这类故障?!

        我们可以使用微软官方工具 Spy++ 来排查这类问题,Spy++隶属于 Visual Studio 的组件,它支持绿色方式运行,利用 Spy++ 可执行下列任务:

  • 显示系统对象之间关系的图形树,这些对象包括:进程、线程和窗口。
  • 搜索指定窗口、线程、进程或消息的属性。
  • 直接从视图中选择窗口、线程、进程或消息。
  • 使用查找程序工具,通过鼠标指针定位选择窗口。
  • 使用复杂消息日志选择参数设置消息选项。

        对于本案例要使用 Spy++ 排查原因,需要在故障重现时启动 Spy++,然后切换到线程视图,再点击工具栏上的“Find Window”图标,通过拖拽标靶图标到要监视的 Windows 对话框上来定位窗口。

FindWindow

        之后在弹出的 Property Inspector 对话框中单击 Synchronize 按钮,即可在 Spy++ 的线程列表视图中,同步定位到这个窗口。

PropertyInspector

        接下来便可审查这个进程中的子线程,看看是否存在可疑项。本例中发现的可疑线程是必应输入法,当尝试切换输入法后,故障消失,可正常关闭 MMC。

Trouble

        而对于大多数安装了第三方输入法,尤其是使用搜狗输入法的朋友,相信这类问题更为常见,所以可切换关闭搜狗输入法,该问题便会消失。此外,如果你尝试使用 Spy++ 进行排错,需要注意它区分 32 和 64 位版本。有关 Spy++ 的详细信息可参考微软官方资料。

https://docs.microsoft.com/en-us/visualstudio/debugger/spy-increment-help?view=vs-2017

为什么我的 Windows 10 系统会有很多 SVCHOST 进程

$
0
0

为什么我的 Windows 10 系统会有很多 SVCHOST 进程

        有不少网友反应自己 Windows 10 的系统中会运行很多 svchost.exe 进程,怀疑自己的系统有问题?!其实相对于现在来讲,这是一个正常的现象。

1

         因为微软自 Windows 10 1703 开始重新设计了 Windows 服务的运行机制。对于内存超过 3.5GB 的 Windows 10 系统,其运行的服务将以独立运行的方式通过 Svchost.exe 进程运行。如果你的内存少于 3.5GB,那么这些服务将会自动分配到共享的 Svchost.exe 进程中运行,这也是 1703 版本以前 Windows 服务默认的运行方式。

        分离 Svchost 运行服务所带来的好处是显而易见的:

  • 通过将关键网络服务与主机中的其他非网络服务的隔离,并在网络组件崩溃时添加无缝恢复网络连接的能力,提高了可靠性。
  • 通过消除与隔离共享主机中的行为不当服务相关的故障排除开销,降低了支持成本。
  • 通过提供额外的服务间隔离来提高安全性。
  • 通过允许每项服务设置和权限来提高扩展性。
  • 通过按服务CPU,I/O和内存管理改进资源管理,并增加清晰的诊断数据(报告每个服务的CPU,I/O和网络使用情况。)

        在过去,Windows 将服务与匹配的安全性要求相结合来确定共享的服务主机组。

  • 本地服务
  • 本地服务无网络
  • 本地服务网络受限制
  • 本地系统
  • 本地系统网络受限制
  • 网络服务

        下图是分离和共享服务主机(Svchost.exe)进程的运行对比。

23

        虽然分离机制已经在 1703 及之后版本的 Windows 10 上应用,但是某些服务仍将继续通过分组方式共享服务主机(Svchost.exe)进程。例如,Windows 防火墙(mpssvc - Windows Defender Firewall)和基本筛选引擎(BFE - Base Filtering Engine),远程过程调用(RpcSs - Remote Procedure Call)和 RPC 终结点映射器(RpcEptMapper - RPC Endpoint Mapper)。

        如果需要识别这些分离和继续分组的服务,除了可以通过任务管理器的进程选项卡来查看 Service Host(服务主机)信息意外,还可以通过详细信息选项卡查阅 svchost.exe 的命令行。

4

        此外微软也提供了通过注册表项检查的办法,打开注册表编辑器定位到“HKLM\SYSTEM\CurrentControlSet\Services”下,查看每个服务下“SvcHostSplitDisable”的值即可,当值为“1”时则表示服务禁止拆分。

Windows 10 支持自动卸载有问题的更新补丁

$
0
0

Windows 10 支持自动卸载有问题的更新补丁

        微软在3月12日发布了一篇知识库文章 - KB4492307,指出当安装更新后,由于新软件不兼容或出现问题,这些更新可能会失败。用户会收到“我们删除了一些最近安装的更新,以便从启动失败中恢复您的设备”这类的通知。当发生这一情景时,便是 Windows 检测到更新引发了问题,会自动尝试卸载最近安装的更新来解决故障问题。

        在卸载更新后,Windows 还可以在接下来的30天内自动阻止安装这些有问题的更新,而这之后才会再次尝试安装更新。

image

        在实际使用中,应该是在安装更新重启后,如果发生启动失败的情况,才会自动触发这一机制。如果真的在启动后发生应用程序运行失败等常见问题,恐怕不会触发自动卸载最近更新的动作。如果有实际体验过的朋友,不妨反馈至 gOxiA 这边分享给大家。

[Edge] 微软发布基于 Chromium 内核的 Microsoft Edge 测试版

$
0
0

Edge_Banner

微软发布基于 Chromium 内核的 Microsoft Edge 测试版

        gOxiA 早先加入了 Microsoft Edge TAP,满怀激动之情,今天终于迎来了 Microsoft Edge 测试版。只要你有兴趣即可访问 Microsoft Edge Insider 网站即可下载安装包,并提供反馈。

        目前 Microsoft Edge Insider 提供三个服务通道:Beta,Dev,CAN


BetaChannelBeta:每6周更新一次,适用于哪些需要稳定预览的用户,该版本即将推出。

DevChannelDev:每周更新,即过去一周改进的版本,通常比每日更新通道更稳定。

CanaryChannelCan:每日更新,如果希望获得 Edge 的最新进展,那么选择 Canary 最为合适。


Microsoft Edge 价值体现

hero.5bd0ab96

  • Microsoft Edge 基于 Chromium 内核,如果你重视开源价值,那么不要错过。
  • Microsoft Edge 使用独立的账户同步系统,使用 Microsoft Account 登录,如果你跟 gOxiA 一样信赖微软并重视数据安全,Microsoft Edge 真是最佳的选择。
  • Microsoft Edge 提供多版本且跨平台的支持,除了 Windows 10,它仍将提供对 Windows 8/8.1 以及 Windows 7 的支持,并且它还支持 MacOS,iOS 以及 Android 系统,对于企业用户终于不必再纠结基于何种浏览器来开发内部业务网站。
  • Microsoft Edge 提供独立的扩展应用平台,但为了提供更好的用户体验,用户可自行开启设置,安装 Google Chrome 应用扩展。
  • Microsoft Edge 安全性更高,支持 Windows Defender SmartScreen,相信未来会提供更多适用于企业的安全和管理特性。

        gOxiA 随后会做一个较详细的使用体验分享,敬请关注!

[Edge] Microsoft Edge (Chromium) 价值体验

$
0
0

Microsoft_Edge_Logo

Edge_Banner

Microsoft Edge (Chromium) 价值体验

        Chromium 内核的 Microsoft Edge 发布之后,gOxiA 就进行了较为全面的体验测试,如果你还未下载,可以参考之前的日志《微软发布基于 Chromium 内核的 Microsoft Edge 测试版》。

        Microsoft Edge 目前的使用感觉非常之好,基本满足日常使用的需求,但是如果你要同步 Edge 数据可能还需要等待一段时间,诸如此类的一些功能特性问题也确实都存在,但官方表示都在开发进度中,即将到来!

        从 Microsoft Edge Insider 网站下载到的安装包目前只有 EXE 格式,且未提供安装参数,如果执行 “/?” 会提示 0x80040c01 错误。

Edge_SetupOptions_0x80040c01

        此外,在安装过程中还需要访问微软网站下载安装数据,所以企业 IT 人员可能暂时无法大范围的对其进行测试和评估。

Snipaste_2019-04-09_08-08-26

        Microsoft Edge 在首次运行时会弹出向导,如果当前系统安装有 Chrome,默认会导入它的数据(Start with your data),如果你希望开始全新的数据体验,则可选择“Start from scratch”。

Snipaste_2019-04-09_08-09-07

        随后向导会提供三种全新的选项卡模式供用户选择,Inspirational 将提供带有美丽背景,且提供搜索框和常用网站图标的布局模式;Informational 则在前述的基础上增加瀑布流布局的各类资讯;Focused 与 Inspiration 的区别则是去除了背景图片。

Snipaste_2019-04-09_08-09-29

        Microsoft Edge 整体界面与 Chrome 并未太大区别,不论你之前常用 Chrome 还是 IE 以及其他浏览器都将非常容易上手 Microsoft Edge,对于界面部分 gOxiA 不做特别介绍,但首先一定要登录账户,Microsoft Edge 使用 Microsoft Account 作为同步账户(情理之中),即独立的数据同步系统,现在 gOxiA 终于敢将 MSID 信息保存在浏览器中。(PS:出于整体安全考虑,在使用 Chrome 时从未将 MSID 的密码存储在其数据同步系统中。)

AddProfile

        在上图中我们能够看到目前的 Microsoft Edge 版本已经提供了众多常用的设置选项,不过可惜!虽然在 Languages 中可以添加中文,但仍无法将程序界面切换为中文。

        Microsoft Edge 支持应用扩展,微软为其提供了独立的扩展应用商店,我们可以从中安装扩展以增强其功能。由于使用了 Chromium 内核,这意味着我们还能够使用 Google Chrome 的应用扩展,为此我们只需启用 “Allow extensions from other stores” 选项,然后访问 Google Chrome extensions StoreChrome Web Store)即可,具体请参考下图。

Extensions

        昨天的文章 gOxiA 提过 Microsoft Edge 将更加安全,除了目前集成的 Defender SmartScreen 功能,还增强了安全提示特性,假如你当前是管理员权限,且关闭了 UAC,则每次启动 Microsoft Edge 时都将看到一则安全提示。

Snipaste_2019-04-09_08-13-19

        微软 Edge 产品组表示更多的企业管理特性在未来都会相继提供,所以正如 gOxiA 所讲的,如果你所在的企业仍在纠结内部网站基于什么浏览器来进行开发,那么现在已经有结果了……

        Microsoft Edge 对 PWA 提供了更人性化的支持,我们可以随时将喜欢的 Web 转换为桌面应用,gOxiA 就喜欢将一些支持 Mobile Mode 的网站转换为 PWA,固定到 Windows 的开始界面或任务栏中使用。(PS:目前 Edge 还不支持强制一键切换到 Mobile Mode,否则体验可就更好了,但 gOxiA 已经向产品组提交了建议。)

PWA

        整体评价,Microsoft Edge 非常不错,即使是 Canary 版本也能满足 gOxiA 的期望!从目前掌握的资讯和测试结果,Microsoft Edge 未来将对用户和企业具有极大的使用价值,我们拭目以待!

HOWTO: 手动删除 Windows.old 目录

$
0
0

HOWTO: 手动删除 Windows.old 目录

        当我们通过 Windows Update 或 Windows Setup 执行新版本的就地升级后,在系统卷会留下一个 Windows.old 目录,该目录为回滚到升级前的操作系统提供了备份,如果你决定保留当前的升级,那么可以使用 Windows 存储设置中提供的“配置存储感知或立即运行”设置,使用“立即释放空间”选项来清理删除 Windows.old 这个备份。

        但有时我们可能会遇到一个情况,就是清理完毕后发现系统卷下(C:\)仍然存在 Windows.old 这个目录,这是因为清理工具无法完全删除掉其中的所有数据导致的。这个问题 gOxiA 早先曾有遇到过,在 Windows 10 先前的版本时,执行就地升级后发现微软键鼠驱动没有被成功迁移,导致被关联在 Windows.old 的对应目录中,由于是加载状态,所以只能手动先卸载驱动,然后引导至 PE 状态,在脱机环境下手动删除 Windows.old。

        而本次遇到的情况与上述类似,不过是 Temp 目录中有文件无法被删除,如下图所示:

clean_previously_1

        在 Windows 10 TAP 其他成员的帮助下,这次 gOxiA 没有引导至 PE 执行手动删除,而是直接在联机状态下操作成功。其方法就是先获得 Windows.old  目录的所有权,然后再重新分配目录权限,为此将执行以下命令行:

1. takeown /f c:\windows.old /r

2. icacls c:\windows.old /grant computer\name:(OI)(CI)(IO)(F)

3. rd /s /q c:\windows.old

takeown_icacls

        上图是执行的过程可供参考,期间有遇到错误,可暂时忽略尝试执行第三步的删除,如果最后确实失败,则可以再选择进入 PE 执行手动删除。


HOWTO: 解决因 0x80004005 引发的无法还原虚拟机状态的故障

$
0
0

HOWTO: 解决因 0x80004005 引发的无法还原虚拟机状态的故障

        Windows 10 May 2019 Update(1903)率先在 MSDN 订阅发布了,gOxiA 之前走 Preview Release 通道就地升级到了 1903,但是发现 Hyper-V 在启动虚拟机时发生了问题,提示“无法还原虚拟机状态:未指定的错误 (0x80004005)”。

hyper-v_0x80004005

        发生此故障的极大概率是在操作系统跨功能版本升级前,或导入虚拟机前,虚拟机处于“保存”状态所致。要解决这个故障最简单的办法是在 Hyper-V 管理器中选择该虚拟机,鼠标右键单击,并在弹出的菜单中选择“删除已保存状态..."即可。

del_Saved_state

Windows 10 1903面向 IT 专业人员的新功能

$
0
0

Windows 10 1903 面向 IT 专业人员的新功能

        Windows 10 1903 (Windows 10 May 2019 Update)于2019年5月21日正式发布,用户可通过 Windows Update 获取到更新,对于商业用户可通过 WSUS 推送该版本。

        如果你正打算全新安装该版本的系统,可从以下三个途径获取安装源:

        截至发稿的当前内部版本号为:18362.116,其生命周期将于2020年12月08日结束。微软建议企业可以开始在整个组织中分阶段部署 Windows 10 1903,以确保在广泛部署前够能验证应用程序、设备和基础架构是否与新版本配合良好。

        对于企业中的 IT 专业人员,有必要了解 Windows 10 1903 如下的更新信息,使之能够从智能安全性,简化更新,灵活管理和提升生产力中受益。

智能安全

Microsoft Defender Advanced Threat Protection (ATP) - Defender 高级威胁防护:

  • 减少攻击层面 - IT 管理员可以配置具有高级 Web 保护的设备,使其能够为特定 URL 和 IP 地址定义允许和拒绝列表。
  • 下一代保护 - 控制已扩展到防止勒索软件,凭证滥用,以及通过移动存储传输的攻击。
    • 完整性强制执行功能 - 启用 Windows 10 平台得以u安城运行时证明。
    • 防篡改功能 - 使用基于虚拟化的安全性将关键的 ATP 安全功能与操作系统和攻击者进行隔离。
  • 平台支持 - 端点检测(EDR)和端点保护平台(EPP)功能现已支持 Windows 7 和 8.1 环境。
  • 先进的机器学习 - 通过先进的机器学习和 AI 模型进行改进,使其能够防御使用新的漏洞利用技术、工具和恶意软件的攻击者。
  • 紧急疫情保护 - 当发现新疫情时,将自动向设备更新情报。
  • 符合 ISO 27001 标准 - 确保云服务能够分析威胁、漏洞和影响,并确保风险管理和安全控制措施到位。
  • 地理定位支持 - 支持样本数据的地理定位和主权,以及可配置的保留策略。

Threat Protection - 威胁防护:

  • Windows Sandbox - 隔离的桌面环境,您可以在其中运行不受信任的软件,而不必担心会对设备造成持久影响。
  • 麦克风隐私设置 - 通知区域中会出现麦克风图标,让您可以看到哪些应用正在使用麦克风。
  • Windows Defender Application Guard 功能增强 - 独立用户可以安装和配置其 Windows Defender Application Guard 设置,而无需更改注册表。企业用户可以检查其设置,以查看其管理员为计算机配置的内容,以便更好地了解其行为。

Identity Protection - 身份保护:

Security management - 安全管理:

  • 适用于 WSL 的 Windows Defender Firewall,它允许用户为 WSL 过程添加规则,就像 Windows 一样。
  • Windows 安全应用程序 - 包含保护历史记录,包括有关威胁和可用操作的详细且易于理解的信息,受控文件夹访问现在位于保护历史记录,Windows Defender 脱机扫描工具操作,以及任何待处理的建议。
  • 防篡改 - 可以防止他人篡改重要的安全功能。

简化更新

  • 交付优化 - 提高具有复杂网络的企业和教育机构的同行效率(通过一系列新政策)。现在支持 Office 365 ProPlus 更新和 Microsoft Intune 内容; System Center Configuration Manager 内容即将推出
  • 预留存储 - 预留存储留出了更新,应用程序,临时文件和系统缓存使用的磁盘空间,通过确保关键操作系统功能始终可以访问磁盘空间来改善 PC 的日常功能。此功能将在预安装​​了Windows 10 1903 以及全新安装的新 PC 上自动启用。(从以前版本的Windows 10更新时不会启用此功能。)
  • 自动重新启动登录(ARSO) - 对于 Azure Active Directory 加入的设备,Windows 将自动以用户身份登录并锁定设备以完成更新,从而确保当用户返回并解锁设备时更新已完成。
  • Windows Update for Business - 现在将有一个统一的分阶段部署开始日期(不再有SAC-T指定)。此外,还将为最终用户提供新的通知和重新启动计划体验,实施更新安装和重新启动截止日期的能力,以及在特定时间段内为重新启动提供最终用户控制的能力。
  • 更新回滚改进 - 如果在安装驱动程序或每月质量更新后设备无法正常启动,Windows 将自动卸载更新以将设备恢复到正常运行状态。
  • 暂停更新 - 所有版本的 Windows 10(包括Windows 10 Home)用户都可以暂停功能更新和每月更新。
  • 智能活动时间 - 用户现在可以选择让 Windows Update 根据设备特定的使用模式智能地调整活动时间。
  • 改进的更新编排 --Windows 10 1903 通过智能地协调 Windows 更新和 Microsoft Store 更新来提高系统性能,以便在用户远离其设备时才开始运作,从而最大限度地减少中断。
  • 改进的更新通知 - 当需要重新启动设备的更新时,用户将在“开始”菜单中的“电源”按钮和任务栏中的Windows图标上看到彩色圆点。
  • SetupDiag - 使用此命令行工具对失败的功能更新进行故障排除。


灵活管理

  • Windows Autopilot - 注册状态页面(ESP)增强功能提供企业就绪设备,其中包括跟踪通过 Intune Management Extensions 提供的 Win32 应用程序。您现在还可以选择在注册期间通过 Intune 阻止哪些应用。此外,Windows Autopilot 功能和关键更新将在开箱即用体验(OOBE)期间自动开始下载。现在,对于 Windows 10 Pro 以及 OOBE 中的 SKU,默认情况下禁用 Cortana 配音。而且,通过 Windows Autopilot 白手套部署,合作伙伴或 IT 人员可以预先配置 Windows 10 PC,以便在交付给 新的Microsoft Mechanics视频 之前进行完全配置和业务就绪。
  • 移动设备管理策略 - Windows 10 1903 提供了用于管理 Microsoft Edge 的新组策略和移动设备管理(MDM)策略。您可以为标准 Azure Active Directory 加入的用户静默启用 BitLocker。您还可以使用 Microsoft 365 管理中心更轻松地为用户管理整个 Microsoft 365 体验。
  • Intune安全基准(预览) - 现在包括 Intune 支持的许多设置,您可以使用这些设置来帮助保护和保护您的用户和设备。您可以自动将这些设置设置为安全团队建议的值。

提高生产力

  • 更智能地工作 - Windows Shell 现在允许您搜索 WSL 发行版中包含的Linux文件。此外,当您在搜索栏中单击时,将显示热门应用程序和最近的文件。我们还将 搜索和 Cortana 分开,允许 Cortana 充当数字助理,同时使用 Windows 搜索文件,图片,文档等。新的Chrome扩展程序将Google Chrome 活动添加到时间轴视图中。
  • 增强工作方式 - 新的辅助功能包括讲述者改进,更多声音和阅读控制,以及易于访问改进,如11个新的鼠标指针大小。Windows 10 1903 还包括 Narrator QuickStart,这是一个新用户的简短教程。此外,您可以点击WINDOWS + .或 ;号,访问新的 kaomojis 和 emojis 表情符号
  • Windows Virtual Desktop - 作为公共预览版提供,Windows Virtual Desktop 允许您提供多会话 Windows 10 体验,Office 365 ProPlus 优化以及对 Windows Server 远程桌面服务(RDS)桌面和应用程序的支持。


以上内容引用自:

What’s new for IT pros in Windows 10, version 1903

HOWTO: 收集 DeviceID 用于测试 Windows Autopilot

$
0
0

HOWTO: 收集 DeviceID 用于测试 Windows Autopilot

        时代在进步,技术在发展,日新月异,所有的事务都不可能长青永驻。Modern Desktop 已经到来,作为传统桌面 IT 人员,是时候开始转变,跟上大局步伐,迎接这个以服务为核心的云时代!

        在未来一段时间,gOxiA 将撰写一系列有关 Microsoft Intune 以及 Windows Autopilot 相关的内容,通过自身的了解和学习,与大家一同进步和提高,并分享和交流其中的心得体会。

        在系列的开篇,gOxiA 想先分享的是在测试和体验 Windows Autopilot 前,需要做的一些准备,而这项准备就是提取 DeviceID(设备标识)。

        DeviceID(设备标识)是什么?!

        在微软的官方文档中对设备标识的说明是这样的:“若要将设备添加到 Windows Autopilot,需要捕获设备的唯一硬件ID并将其上传到服务。虽然此步骤应由硬件供应商(OEM、经销商)或CSP(云解决方案合作伙伴)完成,但用户也可以从运行的 Windows 10 中收集设备的设备标识。

        所以用户手动收集设备标识,应仅适用于测试和评估环境。此外,还需要注意,硬件哈希还包含有关何时生成的详细信息,因此它将在每次生成时进行更改。当 Windows Autopilot 尝试匹配某个设备时,它会考虑所作的更改,并仍能够成功匹配。但对硬件的重大更改无法匹配时,将需要重新生成并上传设备标识。

        以上的信息包含一些重要的细节,这对于日后我们在遇到问题时排错至关重要!

        为了方便用户手动收集硬件标识,微软的 Michael Niehaus 编写了一个 PowerShell 脚本,用户能够很方便地在当前 Windows 10 上获取到,并执行它。

        首先,为了确保我们能够在当前系统环境下运行获取到的脚本,需要对 PowerShell 的执行安全策略进行调整,为此进入 PowerShell 环境,并执行如下命令。

PS> Set-ExecutionPolicy Unrestricted

        然后,从 PowerShell Gallery 获取这个脚本,其名称为“Get-WindowsAutoPilotInfo.ps1”,我们可以使用 Install-Script 来安装这个脚本,在获取前请确保我们能够访问互联网。

PS> Install-Script -Name Get-WindowsAutoPilotInfo -force

        最后,执行脚本将获取到的设备标识以 csv 格式保存到指定位置。

PS> Get-WindowsAutoPilotInfo.ps1 -OutputFile c:\deviceid_filename.csv

        执行过程可参考下图:

get-windowsautopilotinfo

Windows 应用程序的用户默认值和计算机默认值

$
0
0

        是时候写一篇日志进行这个问题的总结了,毕竟拖得时间太久,久到连 gOxiA 自己都要遗忘掉!背景是这样的,在某个案例中需要使用“start apps”调用某个应用,也就是说某个程序内部会通过 Windows 的 Start 命令调用一个应用程序,这个应用程序可能是 chrome 也可能是 msedge,这里以msedge 早期版本为例进行说明。

        当我们在 cmd 命令提示符下使用“start msedge”后,正常情况应该会默认启动基于 Chromium 开发的 Edge 浏览器,但是却遇到了错误提示,内容为“Windows 找不到文件 'msedge',请确定文件名是否正确,再试一次”。当然现在的版本已经解决了这个问题,但是在某些极端环境下,不论是 msedge 还是 chrome ,甚至其他应用,也都可能会遭遇到该问题。

start_msedge_err

        起初发现这个问题时,首先想到的分析方法就是抓取轨迹进行分析。确实有所收获,gOxiA 发现在执行“Start msedge”时会遍历注册表,并最终读取“HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\msedige.exe”路径下定义的值,而结果是未能找到该值。

hklm_no_msedge

        此时,问题已经很明朗了,修复该路径定制的值,问题即可解决!但其实该问题却引出了更底层的一些知识,而且非常有价值。

        在早先的排错过程中,gOxiA 尝试了重装应用程序,排除了安装问题。由于最早遇到的类似案例就是基于 Chrome 的,所以是先对 Chrome 进行了分析。下图是当时对 Chrome 分析时的截图,会发现执行“Start chrome”后,会遍历注册表但最终会以“HKCU\Software\MicrosoftWindows\CurrentVersion\App Paths\chrome.exe”定义的值为准。

HKCU_Process

        此时,不论 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,目前已经修复!)

hkcu_msedge_error

        而对于之前在 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

微软发布 Windows 7 等多平台版 Microsoft Edge

$
0
0

Edge_Banner

        微软于今日发布了面向 Windows 7/8/8.1 版的 Microsoft Edge 预览,至此 Microsoft Edge 已完成了全平台版本的发布,不论您是移动设备用户,使用的是 Android 或 iOS;还是 PC 设备用户,使用的是 Windows 家族(7 ~ 10)或 macOS,现在都可以免费享用这款全新的 Microsoft Edge 浏览器。

Msedge_platforms

        虽然目前还是预览版,但是对于日常使用几乎是没有影响的,而且在最近发布的版本上,已经提供了中文界面的支持。

msedge_flags_enablelanguage

        任何人只要您愿意,就可以加入到 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:

https://app.adjust.com/a6xya4i

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

$
0
0

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.” 生翻这句话,貌似是一个具有恢复能力的客户端发生了响应失败。

PDC_WATCHDOG_TIMEOUT_14F

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

dam_sys

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

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

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

PDC_WATCHDOG_TIMEOUT_14F_STACK1

        综上,并结合栈的轨迹,导致 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 10 排错 PHASE1_INITIALIZATION_FAILED

$
0
0

troubleshooting

Windows 10 排错 PHASE1_INITIALIZATION_FAILED

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

bsod_phase1_initialization_failed

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

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

WindowsBootProcess

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

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

        然后逐个审查“HKLM\SYSTEM\CurrentControlSet\Services”下的项,要识别启动类型则需要通过“Start”键值,这是一个 DWORD 值,具体表示如下:

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

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

image

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

0xc0000001

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


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

$
0
0

troubleshooting

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 的升级工作,以减少不必要的维护成本。

HOWTO: 使用 Windows 10 安装程序 Setup.exe 执行升级验证

$
0
0

HOWTO: 使用 Windows 10 安装程序 Setup.exe 执行升级验证

        当我们要在 Windows 7 或 Windows 8.1 系统环境上升级安装 Windows 10 时,可能会因为现有系统环境的一些兼容性问题,导致升级安装失败,这会耗费很多的时间和精力。所以,建议先使用 Windows 10 的安装程序 - Setup.exe 执行升级验证,以便在未正式升级安装 Windows 10 前进行评估,并对发生的错误进行分析和排错。

        Setup.exe 位于 Windows 10 安装源根目录下,我们可以附加一系列的命令参数执行升级验证,为此请执行如下指令:

setup.exe /auto upgrade /quiet /noreboot /dynamicupdate disable /compat scanonly

        其中 upgrade 表示以就地升级的方式来执行 Windows 10 安装;而 scanonly 则表示 Windows 安装程序通过兼容性扫描运行,然后退出并带有退出代码,以指示是否存在兼容性问题。如果返回的退出代码是 0xC1900210,则表示没有发现兼容性问题;如果发现兼容性问题将返回 0XC1900208,或其他代码。

        那么我们该如何获取退出代码呢?!最为简单的办法就是编写一个批处理脚本,执行升级验证命令行,然后输出退出代码,如下图所示:

echo_errorlevel

        在本例中,执行升级验证后得到的退出代码是“-1047526896”,其代表“0xC1900210”。如果得到的是其他异常代码则需要进行分析和排错,所以建议使用如下的命令行收集日志,当然我们也可以直接查找相关目录下产生的日志文件进行分析。

setup.exe /auto upgrade /quiet /noreboot /dynamicupdate disable /compat scanonly /copylogs c:setuplog

        命令执行完成后会在指定的目录收集相关日志,我们便可以做进一步的分析,有关如何分析日志的方法将在下次与大家分享。

Setup_Compat_Scanonly

Windows 10 Setup.exe 命令参数:https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-command-line-options

本文参考了 Michael Niehaus 的文章:“Windows 10 Pre-Upgrade Validation using SETUP.EXE

HOWTO: 分析 Windows 10 安装日志

$
0
0

HOWTO: 分析 Windows 10 升级安装日志

        如果你在关注 gOxiA 前几天分享的日志“HOWTO: 使用 Windows 10 安装程序 Setup.exe 执行升级验证”,那么应该已经收集到了相关的日志,我们会重点分析“MoSetup”下的“BlueBox”日志,以及“Panther”下的“setuperr”和“setupact”日志。

setuplog

        如下面截图中 BlueBox 日志记录了 0xC190010A,它表示“MOSETUP_E_UNKNOWN_CMD_LINE”,即命令行未知,排查后发现是 gOxiA 执行的 Setup.exe 命令行参数存在错误。

BlusBox_log

        当然以上的错误并不常见,只是为了本文说明,但是在遇到具体的升级故障时我们还需要分析 setuperr.log,该日志中包含了很多错误信息,但并不是所有的错误都会导致升级失败,如下图所示:

setuperr_log

        虽然包含了很多错误日志,但并不会真正影响 Windows 10 升级安装,所以我们需要查找那些会导致“Shell 应用程序请求终止”,或“由于对象的错误而放弃应用”的错误,此外 IT 人员还需要根据实际情况对 setupact.log 进行分析。这些日志通常包含四个等级的日志:Info, Warning, Error, Fatal Error;组件主要包含:CONX (Compatibility Information), MOUPG (Modern Upgrade), PANTHR, SP (Setup Platform), IBSLIB, MIG (Migration Engine), DISM, CSI, CBS。

HOWTO: 使用 SetupDiag Tool 诊断 Windows 10 升级故障

$
0
0

HOWTO: 使用 SetupDiag Tool 诊断 Windows 10 升级故障

        之前我们已经了解如何使用 Windows 10 安装程序 Setup.exe 执行升级验证,并学习了如何分析 Windows 10 安装日志,如果你无法专注于那些错误信息,那么不要气馁!微软为我们带来了 SetupDiag 工具,它是一个独立的诊断工具,可获取有关 Windows 10 升级失败原因的详细信息。(PS:微软真是太贴心了,记住这款诊断工具是免费的!)

        SetupDiag 支持 Windows 7 SP1 to Windows 10;Windows 8.1 同 Windows 10;以及 Windows 10 to Windows 10。

        SetupDiag 会检查 Windows 安装程序的相关日志,并识别出导致 Windows 10 安装或升级失败的关键日志信息。此外,SetupDiag 还支持离线模式,对于那些已经遭遇安装或升级失败的设备,我们也可以使用 SetupDiag 找出失败的根因。

        SetupDiag 需要 .NET Framework 4.6,如果你在为满足需求的环境下执行,则会遇到错误提示,所以请先确保您的系统环境已经安装了 dotNET4,对于 Windows 7 是需要额外安装该组件的。

Req_dotNet4

        从微软官方下载:SetupDiag,可直接双击运行,但 gOxiA 建议你以管理员模式在 CMD 下手工执行,如下图所示:

setupdiag

        SetupDiag 会从相关的目录下查找日志以进行自动化的诊断,如果找到匹配的信息,则会给出诊断结果,在本例中 SetupDiag 找到了“Processing rule: CompatScanOnly”,并给出了相关的建议和参考信息,最后还会生成名为 SetupDiagResults.log 的日志文件,以供我们事后参考。此外,还会生成一个 Logs.zip 的压缩包,其中包含了相关的日志文件。

SetupDiagResults

        如果要执行脱机诊断,需要收集相关的日志到一个文件下,并为 SetupDiag 附加命令参数,参考如下:

SetupDiag.exe /LogsPath:c:\setuplog

        在 SetupLog 文件夹下应该包含相关的日志文件,你可以从以下位置复制。

\$Windows.~bt\sources\panther

\$Windows.~bt\sources\rollback

\Windows\panther

\Windows\Panther\NewOS

Intel 存储控制器驱动版本引发的 Windows 蓝屏故障 0xC0000098

$
0
0

troubleshooting

Intel 存储控制器驱动版本引发的 Windows 蓝屏故障 0xC0000098

        最近在评估一款 PC 设备,由于通过 WDS 部署评估映像,并使用了 DDP(Dynamic Driver Provisioning)注入驱动,发现在部署操作系统后第一次启动时会发生 0xC0000098 故障,提示由 iaStorAC.sys 文件引起。

        iaStorAC.sys 文件很常见,是 Intel 存储控制器的驱动模块,经查隶属于 iaAHCIC.inf,随即排查 WDS 驱动库,发现包含两个版本的 iaAHCIC,分别是16.8.0.1000 和 15.2.0.1020。

DriverGroup1_iaAHCIC

其中 16.0.8.1000 包含的驱动模块为:iaStorAC.sys

DriverGroup1_iaAHCIC_W10

而 15.2.0.1020 包含的驱动模块为:iaStorA.sys 和 iaStorF.sys

DriverGroup1_iaAHCIC_W7

        猜测 DDP 注入了当前匹配硬件的驱动后,发现还有该硬件的新版本驱动,并包含旧版以外的文件,所以也一同安装了这个新版驱动。在实际排错过程中 gOxiA 也发现系统同时加载了 iaStorA、iaStorF 和 iaStorAC,可预料 iaStorAC 与当前系统不兼容,所以引发 0xC0000098 故障,之后尝试禁用 iaStorAC 发现会导致系统蓝屏,看来要彻底解决只能卸载该驱动。

        在脱机状态下,使用 DISM 维护映像,通过 get-drivers 参数获取该驱动分别对应 OEM2.inf 和 OEM16.inf,此时除了对比两个驱动的版本外,也可使用 get-driverinfo 来获取驱动程序的详细信息。当确认影响系统的驱动是 OEM16.inf 后,可通过 remove-driver 将该驱动从脱机系统中移除。

        现在重新启动,系统会先执行短暂的初始化,之后便能正常引导系统完成后续的安装。

        现在很多品牌机的驱动交付质量都已经大大不如从前,也可能驱动程序更加复杂,导致经常以标准化方式注入驱动后,发现系统出现故障,或驱动未能正常安装的情况,这对于桌面标准化交付来说确实是一个挑战,因为每一批设备可能都需要进行完整的评估和测试。

Viewing all 289 articles
Browse latest View live