Build 2022 微软公布 Project Volterra
Build 2022 微软公布 Project Volterra
Microsoft Build 2022 已于中国当地时间 24 日晚 11 时正式拉开序幕，本次大会提供了 300 多个内容的分享，其中公布的 Project Volterra 吸引了 gOxiA 的注意。
从发布的视频了解到这是一款类似于 NUC 一样的 PC，但与众不同的是 Project Volterra 由 Snapdragon 计算平台和神经处理单元（NPU）组成，即 Snapdragon Neural Processing Engine（SNPE），可以理解为是一种用于执行深度神经网络的加速运行器。
如此看来 Project Volterra 就是一款 ARM 架构的设备，从目前信息所了解到的微软正在加大对 ARM 生态的投入，正将 NPU 的支持构建到 Windows 平台中，在本次公布的 Project Volterra 就能看出，首先它作为 DevKit 发布，并非一款实际意义的成型商业产品，如果性价比高，也会吸引更多的开发者回归 Windows 生态。此外，在 Project Volterra 上微软提供了丰富的开发支持，意味着未来开发者可以在这个平台上原生运行 Visual Studio 和 VS Code 开发工具，支持 .Net，并且还提供了 Windows Terminal、 WSL，以及 WSA 的支持。
Project Volterra 目前硬件相关的信息还非常少，但从视频中可以看到它的一些主要硬件特性。首先，它具备了有线网络和 MiniDP 接口，并且还提供了三个 USA-A 和 两个 USB-C 端口。
很新颖的是 Project Volterra 还支持堆叠设计，意味着它可以部署在桌面和机架环境中。（细思极恐！！！）
此外，它的外壳也是环保设计，使用了可回收的海洋塑料制成。从视频看还支持外接 3个显示器，真是令人向往！
虽然 gOxiA 不是一位开发者，但对于微软的此波上市操作，感觉是非常令人称赞，并深深被吸引，迫不及待想买一台把玩把玩！虽然没有公布具体的硬件参数，但从已经发布的现有产品推测，Project Volterra 应该也是款 Microsoft 的 ARM 处理器，如果没猜错应该就是 SQ2 了（记得好像媒体介绍是此款是骁龙 8cx 级别的），那 GPU 应该就是 Adreno 690 了，既然支持 WSL 和 WSA 的开发环境，内存起码也要 16GB，如此存储应该也能达到 512GB 或者更高了。希望最终的 DevKit 发售价能控制在 400 ~ 1000 刀左右（毕竟是面向开发者的……），期待！
[Tips] HOWTO: 为 MMC 管理器无法关闭进行排错
HOWTO: 为 MMC 管理器无法关闭进行排错
今天 gOxiA 跟大家分享一个 MMC 管理器无法关闭的排错案例，具体故障现象是使用 Hyper-V 管理器后关闭时会遭遇其管理控制台无法关闭的故障问题，具体提示内容是“关闭 Hyper-V 管理器前你必须关闭所有会话框”。
常规排错时，我们可以使用 ProcessMonitor 工具进行分析，从 Procmon 的日志来看管理器关闭失败的原因，它检测到了有 PropertySheets 的窗口还开着，可能的原因是有 Invisible 的窗体被归到了 Hyper-V 管理器的进程上。
接下来我们可以打开任务管理器确认当前发生故障问题的 MMC 的 PID 值，然后将其转换为16进制。之后使用 Microsoft Spy++，将视图改为 Process 模式，通过前面的16进制值，定位 MMC 的进程，并展开它来排查具体线程。
在本例中可看到一个可疑的线程包含 GDI+ Hook Windows Class 以及 Default IME。尝试切换输入法重新关闭 Hyper-V 管理器，已经可以正常关闭。日常当我们遇到 Windows 的一些异常问题时可以借鉴这个案例进行排查。
[Tips] HOWTO: 手动创建 Windows To Go
HOWTO: 手动创建 Windows To Go
Windows To Go 有些朋友应该并不陌生，它早先是内置在 Windows 中的一项功能，允许在 U盘上创建一个 Windows 运行实例，当然肯定是有诸多前提条件和限制的，而且因为无法支持功能更新，所以在 Windows 10 的 2004 及更高版本中删除了 Windows To Go。那为什么 gOxiA 今天又来分享它呢！？原因很简单，假如我想在当前一个设备上临时跑个操作系统（Windows Server），但设备的存储空间有限，并且也不希望对现有系统环境，如引导信息做任何更改，该怎么办？
这时 Windows To Go（以下简称 WTG）就发挥了它的优势，手头正好有个 SSD 的移动硬盘，基于 UEFI 方案创建了磁盘分区，本例只创建了 EFI (S:)、MSR 和 Windows (W:) 分区，与我们平常的系统盘是一样的。
然后将 Windows 安装盘中的 Install.wim 释放到 Windows 分区，具体步骤不再复述，使用 DISM 高效快捷。
映像释放完毕，使用 bcdboot 生成 BCD 即可，如下所示：
看到这里是不是觉得很简单，这不跟手动安装 Windows 一样？！没错，就是这么简单，但要想工作正常还需要做额外的准备，使用 Windows ADK 中的 WSIM 创建一个应答文件，对如下组件进行配置：
1. 将 Microsoft-Windows-PartitionManager 下的 SanPolicy 配置为 4，这样在 WTG 启动和运行时就不会加载设备本机的存储。有关 SanPolicy 的详细说明可以参考：https://docs.microsoft.com/zh-cn/windows-hardware/customize/desktop/unattend/microsoft-windows-partitionmanager-sanpolicy
2. 将 Microsoft-Windows-WinRE-RecoveryAgent 下的 UninstallWindows 配置为 true，这样将会从已安装的实例中删除 WinRE。
两项组件配置完毕后可将应答文件（Unattend.xml）保存到“W:\Windows\Panther”下，然后实行如下命令将应答文件应用到脱机实例。
为了确保 WTG 能正常驱动硬件设备，还请考虑使用 DISM 的 /Add-Dirver 参数提前将驱动注入到脱机实例中，最后将 WTG U盘连接到目标设备，从 U盘启动即可完成后续的初始化，直至系统进入正常使用状态。整个过程大家会注意到没有使用任何第三方工具，所以不论从便捷性还是安全性都有保障。如果你当前也遇到类似的使用场景不妨一试！
官方的最佳实践建议：
- 始终关闭 Windows 并等待关机完成，然后再移除 WTG U盘。
- 不要将 WTG U盘插入正在运行的计算机。
- 不用通过 USB Hub 连接 WTG U盘，应直接与设备端口连接。
- 使用 USB 3.0 端口。
- 不要在 WTG 实例中安装非 Microsoft 核心 USB 驱动。
本文结束前友情提示，如果你打算将 WTG 运行在 BIOS 和 UEFI 两种类型的设备上，需要在执行 bcdboot 生成 BCD 时附加“ /f ALL”参数，这样会生成两组启动组件，该模式支持的磁盘布局如下：
