Windows XP | Windows Vista | Windows 7 | Windows 8 | Windows 10

  

HOWTO: 禁用 Windows 10 首次打开 IE 时弹出的设置界面

  

        企业 IT 人员通常都会定制系统映像,以提供适用于本企业适用的操作系统环境,也称之为企业标准化系统映像。但是会发现部署的这些映像在首次运行 IE 时会弹出一个“设置 Internet Explorer  11”的界面,会影响最终用户的操作体验,那么我们该如何配置参考映像以禁用这个设置界面呢?!

  

DisableFirstRunWizerd_W10

  

        方法很简单,修改 Unattend.xml 应答文件,在 “Specialize” 阶段增加 “amd64_Microsoft-Windows-IE-InternetExplorer_neutral”,将其下的 ”DisableFirstRunWizard“ 设置为 ”true“。(PS:Windows 10 下 IE 的 x64 和 x86 时混合模式,所以只添加 amd64 类型模块即可!

  

DisableFirstRunWizard

  

        对于 Windows 7 系统,在首次运行 IE 时将会自动访问一个微软网址(http://go.microsoft.com/fwlink/?linkid=691688),对于仅在企业内网使用的电脑,打开这个页面且无法正常访问是很多余的事情,而且严重影响用户的体验,所以也可以通过 ”DisableFirstRunWizard“ 来阻止,方法同上,但需要注意还需要为 Windows 7 x64 架构的映像添加  “wow64_Microsoft-Windows-IE-InternetExplorer_neutral”模块,做与 amd64 同样的配置。

  

DisableFirstRunWizerd_W7

Windows 7 支持将于 2020 年 1 月 14 日终止

        微软承诺为 Windows 7提供自其 2009年10月22日发布以来为期 10年的产品支持。在支持期限结束后,微软将停止为 Windows 7 提供支持,这些支持包括为产品提供帮助和有助于保护电脑的自动更新以及微软客服服务,而 Windows 7 的终止支持具体日期将是 2020年1月14日。

        微软强烈建议大家在2020年1月前升级到 Windows 10!!!作为企业 IT ,留给我们的时间已经不多,2018年将是非常重要的一年,我们需要评估企业业务系统的兼容情况,并提出升级计划已保障后续客户端系统顺利的升级;建立完善的评估和测试机制,以满足未来 Windows 10 部署需求;可考虑在企业内部建立分圈升级机制,以提供最佳的用户体验,也可避免因批量升级产生的一系列问题。而在硬件预算方面,由于已经临近年底中国大部分企业的来年预算申请都已完毕,如果之前你没有新硬件的采购计划,那么也不用担心,Windows 10 还是能够很好的兼容现有硬件,并提供良好的运行性能的,此外通过实践为旧电脑加装固态硬盘,要比升级内存更能获得质的提升。最后就是企业 IT 环境的安全应用软件,这部分是最为重要,也是最拖后腿的,由于涉及层面较深这里略过,有需求的可单独联系 gOxiA 可提供顾问咨询。

        以下是微软官方针对 Windows 7 终止支持服务的常见问题解答:

  • 终止支持对我来说意味着什么?
    在 2020 年 1 月 14 日之后,如果你的电脑运行的是 Windows 7,则将不再收到安全更新。因此,你必须升级到现代的操作系统(例如 Windows 10),以便获得最新的安全更新,帮助确保你和你的数据更加安全。此外,Microsoft 客户服务将不再提供 Windows 7 的技术支持。
  • 我该怎么办?
    对于大多数 Windows 7 用户,改用安装有 Windows 10 的新设备会是明智之举。当今的电脑不仅速度更快、更轻便,而且功能强大、更安全,平均价格比 8 年前的电脑便宜得多。我们的指南可以帮助你选择新的电脑,你只需完成几个简单步骤。是否想要了解有关 Windows 10 的详细信息?请查看我们的概述页面以了解详细信息。
  • 我能够将现有的电脑升级 Windows 10?
    为了充分利用最新硬件功能,我们建议改用安装有 Windows 10 的新电脑。或者,可通过购买并安装完整版的软件升级兼容的 Windows 7 电脑。有关详细信息,请参阅 Windows 10 升级常见问题解答
  • 如果我继续使用 Windows 7 会出现什么情况?
    你可以继续使用 Windows 7,但是,当支持终止后,你的电脑更容易遭受安全风险和病毒的攻击。Windows 将继续启动并运行,但你将不再收到 Microsoft 的软件更新,包括安全更新。
  • 在 2020年1月14日之后,是否仍能激活 Windows 7?
    在支持终止后,仍能安装并激活 Windows 7;但是,由于缺少安全更新,它将更容易遭受安全风险和病毒的攻击。在 2020 年 1 月 14 日之后,Microsoft 强烈建议你使用 Windows 10,而不是 Windows 7。
  • Windows 7 是否仍将支持 Internet Explorer?
    2020年 1 月 14 日,Windows 7 设备也将停止支持 Internet Explorer。作为 Windows 的组件,Internet Explorer 遵循安装其的 Windows 操作系统的支持生命周期。有关详细信息,请参阅生命周期常见问题解答 - Internet Explorer
  • 如果我运行的是 Windows 7 企业版该怎么办?
    如果 Windows 是你工作环境的一部分,我们建议你首先联系 IT 部门,或者参阅 Windows 10 部署支持以了解详细信息。
  • 如果我运行的是 Windows 7 Embedded 呢?
    对于用于 ATM 或燃气泵等嵌入设备的 Windows,其生命周期日期有时不同于电脑设备上使用的 Windows 版本。请参阅 Windows Embedded 产品生命周期页面,以了解有关 Windows 7 Embedded 生命周期的详细信息。

troubleshooting

HOWTO: 解决 远程桌面连接已停止工作 的故障问题

        故障现象是用户打开“远程桌面连接”程序去登录一台计算机,连接过程中该程序发生错误,提示“远程桌面连接 已停止工作”,如下图所示。

rdp_crash

        对于此类应用程序发生崩溃的故障问题,通常可展开详细信息查看故障程序中具体的出错模块进行排查。也可以在事件查看器中的应用事件日志中查找具体错误信息。

event

        但是本案例中,导致 mstsc.exe(远程桌面连接)的错误模块是 ntdll.dll,由于是系统核心文件,且系统未出现其他异常,故怀疑是 ntdll.dll 加载和处理其他驱动动态链接库文件时发生了错误。

        但是该如何查看 mstsc.exe 加载的动态链接库呢?!好在 Windows Error Reporting(WER) 为我们记录了相对详细的信息,可用于进一步的排错。首先通过事件查看器找到“Windows Error Reporting”日志,打开日志查看 WER 存储的具体位置,通常位于当前用户配置文件目录下: “\AppData\Local\Microsoft\Windows\WER\ReportAchive”。

event1

        文件名为 Report.wer,此文件使用 UTF-16LE有签名 编码,可以使用一些第三方的文本编辑器打开查看,当然也可以用系统自带的记事本,但是显示效果惨不忍睹!

emeditor

        此外,还可以使用第三方的 WER  查看器,比较有名的是 NirSoft 出品的 AppCrashView 工具。(PS:使用参数 /ReportsFolder <Folder> 可以直接定位打开 WER 目录)

AppCrashView

        通过分析发现,mstsc 在载入 HP1005 驱动时发生了错误,是导致本次崩溃的罪魁祸首!解决方法是在通过远程桌面连接前,修改本地资源选项,不要勾选打印机。如果此打印机不再使用,建议直接卸载驱动!

rdp_localsources

MsftAuth

使用 Microsoft Authenticator 轻松管控 Microsoft Account

        微软旗下很多产品和服务都已经支持双重身份验证,而 Microsoft Authenticator(Microsoft验证器)应用适合于使用双重验证来保护个人或工作账户的用户,或者想要不输入密码即可登录到个人 Microsoft Account(Microsoft 账户)的Android 和 iOS 用户。

        当启用双重验证后,使用账户登录时,第一步会输入密码,第二步是使用手机上的应用进行验证。这样可以起到保护账户安全的作用,即一旦账户密码丢失,被人盗用去访问敏感信息时仍旧需要通过手机再次进行身份验证,这样安全性就会提高。

        此外,借助 Microsoft Authenticator 还能实现免密码输入进行账户的登录,这一特性是 gOxiA 非常喜欢的!由于要在一些非受信任设备上使用Microsoft Account 或 Office 365 Account 登录微软产品或在线服务,输入密码会非常不安全,但在登录界面选择“改为使用 Microsoft Authenticator 应用”则会非常轻松和安全,只需通过 Microsoft Authenticator 应用验证即可,而无须输入账户密码。

loginbymsftauth

20180117_063030000_iOS

        如果要对双重验证以及Microsoft Authenticator 应用进行设置,可以访问微软官方站点(https://account.live.com/proofs/Manage/additional)进行配置。

setupmsftauth

        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

iOS: https://itunes.apple.com/app/id983156458

troubleshooting

  

HOWTO: 解决无法打开 Excel 表格中 URL 的故障问题

  

        最近遇到一个比较典型的故障问题,排错过程跌宕起伏,事后感觉挺有代表性,决定拿出来与大家分享。故障环境是一台 Windows 10 + Office 2016 的加域设备。用户打开一个 Excel 文档,表中有一列文本包含 URL 超链接,可通过点击该文本启动 IE 去访问指定的网址。但是实际在点击链接后会提示“无法打开http://……无法下载您要求的信息。”

  

image

  

        对其他链接进行了尝试,均提示相同的警告,但是手工新增加一个文本链接,却访问正常。之后将故障网址复制出来,粘贴到 IE 中再次访问,发现能够到达对方的服务器,但返回了“403 Forbidden”,可是将网址复制到其他浏览器,如:Edge、Chrome 中访问却是正常的。再回顾 IE 访问故障界面,发现地址栏中的中文路径在403反馈中显示的是一段乱码。说明故障的原因是由网址中包含的中文字符导致的,通常这类问题是由字符编码错误引发的。

  

image

  

        为了求证错误,gOxiA 对正常和异常访问的 Web 数据进行了抓包,以做进一步的分析。如下结果,分析发现中文字符确实被进行了编码,但是异常访问的 Web 数据中所包含的第二次 URL 请求出现了变化,编码字符有异常,前后不符。

  
      
  • 正常访问:
  

image

  
      
  • 异常访问:
  

image

  

        另外比较奇怪的是为什么会发起两次 HTTP 请求呢?!对两次访问的发起代理程序进行了分析,发现用户在 Excel 中点击 URL 时,Excel 发起了 HTTP 请求,且提交的 URL 编码是正确的。

  

image

  

        但是,在传递给 IE 后,却被 IE 重新编码成了错误的 URL 。

  

image

  

        至此,可以判定是因为 IE 提交的含中文字符 URL 的编码问题引发的此次故障。而中文编码问题通常出在 Windows 和 Linux 系统之间,多数原因是 Windows 提供的中文编码默认为 GB2312,而 Linux 使用的是 UTF-8,所以需要强制 IE 使用 UTF-8 来提交 URL,即可解决该问题。

  

        但是,在执行配置操作时发现,IE 的“以 UTF-8 形式发送 URL 路径”选项被锁定了,无法修改!且明确提示“某些设置由系统管理员进行管理”。做进一步分析,确认系公司域下发的组策略所谓,不知道为什么要禁用这个选项,实属奇葩!

  

image

  

        通知 AD 运维团队修改 GPO 不切实际,只能另寻出路!于是对 Excel 中点击 URL 的操作进行了抓包,筛选出来4000多行数据,“功夫不负有心人”在位于“HKCU\Software\Microsoft\Office\16.0\Common\Internet”下发现了一个有价值的注册表键“Encoding”,既然隶属于 Office,也就意味着可以通过 Office 选项对文档的编码进行定义。

  

image

  

image

  

        最后,在 Excel 高级选项的 Web 选项中找到了切换文档编码的设置。即,进入 Excel 选项,依次点击“文件-选项-高级”,在右侧窗口中向下拖动至“常规”,找到“Web选项”,进入。

  

image

  

        在“Web选项”下,切换至“编码”选项卡,找到“将此文档另存为”选项,从下拉框中找到“Unicode(UTF-8)”,点击“确定”完成设置,保存当前文档重新打开再点击 URL 尝试,故障消失。

概览 Windows 10 内置的 OpenSSH 功能

        回顾 gOxiA 早在2005年撰写的一篇日志,曾提到 SSH 才是王道,现在看来也不为过,命令行的魅力和实用性无法替代,不会随着科技的发展而消亡。对于管理 Linux 系统,命令行则更加至关重要,SSH 也是最佳的远程管理方式。过去要在 Windows 上使用 SSH Client 通常要找第三方工具,如 Putty,或者 Xshell,前者官方访问受阻,还被搞出过一次安全事件;后者又是需要付费的产品,实在令人难以选择。

        但是现在 Windows 10 原生支持 OpenSSH Client,此外还支持 OpenSSH Server,也就是说我们无需再借助第三方的 SSH 软件去管理 Linux。需要注意的是由于 Windows 10 内置的 OpenSSH 还处于 Beta 阶段,所以微软并不建议你应用在生产环境。

        迫不及待,那么我们该如何启用 OpenSSH 功能呢?!非常简单,通过系统栏的通知图标选择”所有设置“导航至”应用-应用和功能“,点击”管理可选功能“-”添加功能“,选择”OpenSSH Client (Beta)“。

ssh0

        如果希望借助命令行方式来安装,有两种方法可以参考:

一、 通过 PowerShell,可以使用如下命令行获取 OpenSSH 功能的完整名称,然后再进行安装。

Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'

get-windowscapability

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

二、通过 DISM 进行安装,过程与 PowerShell 类似,都要先找到 OpenSSH 对应的安装组件名称,再进行安装。

dism /Online /Get-Capabilities | findstr OpenSSH

dism_get-capabilities

dism /Online /Add-Capability /CapabilityName:OpenSSH.Client~~~~0.0.1.0

        OpenSSH Client 安装完毕后,可以通过 CMD 执行 SSH 调用,例如要远程登录 name.cloudapp.net 的 SSH,则执行” ssh account@name.cloudapp.net“,域名首部附加 account@ 是告知所要登录的用户名,等同于 -l 参数,否则将会使用当前的 Windows 登录账号去执行 SSH 验证。

        如下图所示,gOxiA 通过 ssh 命令行登录到了 远在墙外的 Azure Ubuntu 虚拟机。

ssh1

        Windows 10 当前内置的 OpenSSH Client 版本,满足基本的操作还是没问题的,但是诸如 nano、rz  等程序指令还不能完好的支持。考虑是不是可以尝试给 Azure Ubuntu VM 添加个简单的图形界面,能够以 RDP 协议登录?!

troubleshooting

定制 Windows10 开始界面时 Import-StartLayout 的常见问题

        在部署 Windows 10 前,IT人员通常会生成自定义的 Windows 10 参考映像,为了提升用户体验并满足企业桌面标准化,都会对 Windows 10 的开始界面进行定制,添加符合规范的程序图标并进行分组排列和组合。想必大家已经踩坑,自 16299 开始通过在应答文件中启用 CopyProfile 来实现开始界面的统一已经失效,所以必须借助组策略强制部署 StartLayout,或通过 PPKG 实现。当然,也可以使用 Import-StartLayout 导入 StartLayout.xml 为用户指定默认的开始界面布局,但是该方法对已生成用户配置文件的用户是无效的。对于不能通过组策略实现开始界面统一部署的用户,在 OOBE 阶段使用 Import-StartLayout 也是一个不错的选择,gOxiA 就是通过这个方法实现所有新登录用户使用统一的开始界面布局。

        但是在实践 Import-StartLayout 过程中,也遇到一些比较典型的问题,会比较常见,特以此文分享于大家。

import-startlayout

        Import-StartLayout 命令行通常为“Import-StartLayout -LayoutPath C:\startlayout.xml -MountPath C:\”,其中 -LayoutPath 是指定开始界面布局配置文件所在路径,-MountPath 是指定系统卷。在上面的截图中有展示的是三个常见故障:

  • Import-StartLayout :文件 不是有效的布局文件
    该问题通常是因为修改了 StartLayout.xml 导致的,其中包含了未满足规范的语句,这就需要进行具体的检查。
  • Import-StartLayout :未能找到路径 的一部分
    其中路径类似“D:\Users\Default\AppData\Local\Microsoft\Windows\Shell\LayoutModification.xml”,通常这个故障是因为 IT人员在 Unattend 中重新指定了用户配置文件目录导致的,开始界面定制文件默认会应用到 Default 对应目录中,所以处理该故障就要先确定 Default 所在的卷。
  • Import-StartLayout :对路径 的访问被拒绝
    此故障很容易理解,要执行 Import-StartLayout 需要管理员权限运行,如果系统启用了 UAC,要执行它就必须提权运行。

        最后,额外分享一下开始界面布局文件中需要注意的事项,有些 IT人员会在布局配置中添加任务栏图标的定制(CustomTaskbarLayoutCollection),那么必须要对 CustomTaskLayoutCollection 进行声明,即添加“xmlns:taskbar="http://schemas.microsoft.com/Start/2014/TaskbarLayout"”。

troubleshooting

HOWTO: 解决 Outlook 邮件正文无法正确插入UNC类型快捷方式链接的问题

        实在想不出更准确的题目,所以在分享前,gOxIA 觉得很有必要详细描述一下这个故障现象。用户环境是 Windows 7 + Office 2010(经典组合),在其桌面上有一个文件夹快捷方式(.lnk),目标指向到的是一个 UNC 路径,结构基本就是“\\\\10.0.0.1\\aaa\\bbb\\ccc\\ddd\\eee”这个样子,当然示例路径中的字母在实际环境下是中文+符号。如下图所示:

1

        故障现象:用户在 Outlook 中撰写一封邮件,在正文部分使用“插入——超链接”功能,添加这个桌面快捷方式的地址。正常情况下,“插入超链接”窗口中的“地址”中显示的应该是这个快捷方式(lnk)的实际 UNC 路径,确定后邮件正文中添加的也应该是这个 UNC 路径。

2

        但是在用户故障环境下,显示和插入的结果却是这个快捷方式(lnk)的本地路径,如下图所示:

3

        问题虽小,但用户重视程度之高,在其他用户电脑上测试发现显示的确实为 UNC 路径,那么说明这个问题是一个故障。在打 Office 补丁,甚至重装了 Office 后,故障仍未解决。从故障看很可能是一直问题,所以决定寻求官方支持,但结果是 by design,或第三方插件干扰,实在无法接受这个解释!从经验来看这个问题很明显是一个故障,并且很可能是产品的已知问题。

        看来必须要在自己的测试环境下重现故障,才能更好的寻找根因!随即开了一台虚拟机配置好了环境,但未重现故障,对比版本后得到如下信息:

用户环境:系统6.1.7601.17567    Office14.0.7015.1000

测试环境:系统6.1.7601.23537    Office14.0.7181.5000

        基本可以确认用户环境肯定是缺少了什么补丁所致,因为Office 2010也有安装 SP2,而后续的零星补丁又太琐碎,也尝试直接覆盖文件,但并未解决,可以判定该问题与 Office 补丁无关,那肯定就出在系统上面了。

        随后,重新搭建了测试环境,为虚拟机安装 RTM 版操作系统和 Office,果然重现了故障。RTM 环境下的版本信息如下:

RTM环境:系统6.1.7601.17514    Office14.0.7015.1000

        至此已经明确了故障问题,用户因缺少某个系统补丁,导致在插入一个 UNC 类型的快捷方式时,会出现未达预期的结果。通过测试,并不是所有的 UNC 快捷方式都会出现这个问题,难道是中文长路径所致?但长度并未超过 256,且字符也属常见类型,看来只能通过 Process Monitor 抓包进行分析。

4

        在抓包的数据中发现了问题!当添加超链接时,进程会遍历这个 lnk 所对应的 UNC 路径,但此时却出现了拒绝访问,如上图所示。根据分析的结果对这个 lnk 对应的 UNC 每一级目录进行了访问测试,果然如此!这个 UNC 路径“\\\\10.0.0.1\\aaa\\bbb\\ccc\\ddd\\eee”中,其中 DDD 和 EEE 是允许用户访问的,而上一级目录则禁止当前用户访问。

        这也进一步验证了,该故障属于一个 Windows 的已知问题,接下来就是对更新补丁进行验证。将 RTM 测试环境接入内网 WSUS,拿到了 103 个补丁,这些补丁包含了安全和质量更新,还有汇总更新补丁。在一次打完所有补丁后进行测试发现故障消除! Great,可算有了里程碑式的进展,那么这 100 多个补丁中哪个才是修复当前故障问题的补丁呢?

        要对 103 个补丁进行测试真的是一个巨大、枯燥,令人抓狂的工作,最终锁定 KB4022722 这个补丁!!!至此故障彻底解除,结尾要与大家分享一个重要的经验,在处理 Windows 故障,尤其涉及更新补丁时,在关键节点判断问题类型十分重要,如果分析归类为已知问题,应确认该问题是属于安全的还是质量的,这样才能有效减少工作量!!!(:-P)

troubleshooting

  

HOWTO: 解决 外部数据库驱动程序 (1) 中的意外错误

  

        前几天遇到一个用户故障,Windows 7 系统运行一个第三方开发的打印小工具,之前运行正常,这几天总是在选择 Excel 文件后报错,导致无法正常打印。具体的报错提示“外部数据库驱动程序(1)中的意外错误”,如下图所示:

  

Snipaste_2017-11-10_13-18-27

  

        将该工具拷贝到我的环境下运行(Windows 10)也一样报错,即使设置兼容性模式也无济于事。用户反馈之前只更新过补丁,没有做过任何系统变更。为了快速定位根因所以先从补丁入手,经过测试基本锁定了三个更新补丁,后来在虚机测试环境下锁定了 KB4041678,并重现了故障。

  

        在 KB4041678 中微软声明了该补丁存在已知问题,会导致基于Microsoft JET 数据库引擎(Microsoft Access 2007 和更低版本或非 Microsoft 应用程序)的应用程序无法创建或打开 Microsoft Excel.xls 文件。错误消息为“外部数据库驱动程序 (1) 中的意外错误。(Microsoft JET 数据库引擎)。

  

        微软提供的临时解决方案是下载并安装 Microsoft Access 数据库引擎 2010 可再发行软件包,然后在 Microsoft Excel 中修改 DB 连接字符串以将 ACE 用作提供程序。示例:将 Provider=Microsoft.Jet.OLEDB.4.0 更改为 Provider=Microsoft.ACE.OLEDB.12.0。

  

        同时微软也正寻求一种解决方案,相信在不久的将来就会提供更新。但是,当下要解决用户问题,只能卸载 KB4041678,因为内网用户通过 WSUS 更新补丁,意味着将会有更多的用户遇到这个问题!是否可以找到被更新的文件做替换来解决这个故障呢?!尝试方法这样展开,先用 Application Verifier 和 WinDBG 去找验证这个应用程序,并截获断点。

  

        结果是,Application Verifier 收集到的日志中,并未发现什么异常,反而在 WinDBG 中发现了断点,如下图所示在载入模块“msexcl40.dll”时出现了问题。检查文件日期确实是10月份有更新过,尝试用正常 Windows 7 环境下的 msexcl40.dll 对故障Windows 7 系统和 Windows 10 系统进行替换,故障解除!

  

Snipaste_2017-11-10_13-28-20

  

        使用 Process Monitor 抓包观察,发现 msexcl40.dll 开始到操作结束出现了一系列的错误,具体可参考下图。

  

Snipaste_2017-11-10_15-06-00

  

Snipaste_2017-11-10_15-05-18

windows-10-fall-creators-update

HOWTO: 解决 Your Organization used Windows Defender Application Control to block this app

        gOxiA 前段时间为手上的 Dell Venue 8 Pro 全新安装 Windows 10 v1709(Fall Creators Update),没想到装完后竟然无法运行 EXE 程序,期间重装系统进行测试无数次(话说现在Windows安装起来实在太轻松了)。本以为是最初安装了 Windows 10 S 版导致的,后来又单独安装 Home、Pro 或者断网执行 OOBE,或者直接从 Home 升级到 Pro,清理组策略,几乎能想到的办法都试过了,可结果都令人失望。

        具体的错误信息如下图,提示“您的组织使用 Windows Defender 应用程序控制限制了该应用”,系统上几乎所有的 EXE 程序都无法正常运行,就像是安装 Windows 10 S 一样。

defender_warning

        最后向微软开了 Case,沟通中提到之前一些硬件需要关闭主板的 Secure Boot,才能正常运行 Windows 10,果然!在禁用 Dell Venue 8 Pro 后,EXE 程序可以启动了。

dell_venue_8_pro_sysinfo

        这款设备是个平板,采用了 Intel Atom Z Series 架构,记得早前就有公告提到过 Windows 10 与 Intel Atom Z3xxx 存在兼容性问题,没想到还真遇到了。虽然通过禁用 Secure Boot 能够运行系统内置的 EXE 命令,但是当安装其他应用软件时也会报 CPU 兼容性限制。

cpu_warning

        作为一款 4年前的 8寸 Windows 平板设备,还能有什么过高的要求呢?!现在倒是很期望微软后续的新型态移动 Windows 设备。

        如果大家跟我一样遇到了因 Windows Defender 限制 EXE 程序运行的问题,不妨尝试关闭 Secure Boot。此外利用固件限制 Windows 运行方式也是一种不错的选择,未来也许对企业非常用价值!

分页: 1/34 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]