Windows Setup 错误 Module_Init_HWRequirements
Windows Setup 错误 Module_Init_HWRequirements
在执行 Windows Setup 后系统实例首次启动时，在 Specialize 阶段发生错误，具体如下图所示。这是一个极为罕见的问题，常规情况下几乎不可能发生。
从报错信息看 “
panthr initializemodule - failed to find entry point module_init_hwrequirements[gle=0x0000007f]
” 应该是系统在初始化模块时未能找到名为“module_init_hwrequirements”的入口点，通常可能存在以下几个原因：
- 缺少依赖项：模块可能需要依赖于其他组件或库，而这些依赖项可能缺失或损坏。
- 不兼容的系统架构：模块可能是针对特定的系统架构编辑的。
- 模块本身损坏：模块文件可能损坏或不完整，导致无法正确加载和初始化。
- 版本不匹配：模块可能需要特定版本的系统。
这份 Windows Setup 是 gOxiA 一直在用的，难道是加载的安装源太新或下载的数据有问题？新的安装源是 W10 22H2 LCU12，于是换成 LCU10再试，依旧报之前的错误。分析当前的 Windows Setup 可见版本基于 19041，PE 下可见版本为 19041.1288，Bing 搜索了一下并未发现有效的线索，关于 Module_init_hwrequirements 的介绍也未能找到。
不懈努力，再次尝试 W10 22H2 LCU8 这次成功安装，怀疑与最近 Windows 恢复环境的更新有一定关系，果断替换手里的 PE 将其改为最新的 Windows Setup PE，再次安装测试问题消失。
微软公布 Windows App 预览
微软公布 Windows App 预览
微软最近公布了一款新的应用 - Windows App，从官方介绍看 Windows App 是通往 Azure Virtual Desktop、Windows 365、Microsoft Dev Box、Remote Desktop Service、Remote Desktop 的网关，旨在安全地连接到 Windows 设备和应用。
简单理解，gOxiA 认为 Windows App 是一款 RDP 应用的大统一版本，在未来我们仅需要这一款应用便可以在不同的平台（Windows、macOS、iOS、iPadOS、Android、Web 浏览器）和设备（台式机、笔记本、平板、手机）上访问 Windows 或 Windows 应用。 也类似网上其他媒体讲的 Windows 像一个应用一样允许被访问和使用。Windows 运行在云端了，RDP 客户端支持所有主流平台，可不 "any where, any way access Windows."!!!
由于当前还处于公共预览阶段，并非所有版本和功能都可用，下表为当前的支持情况。
现在 Windows App 可以通过 Web 方式访问，或者从 MSStore 安装 Windows App，但 iOS 等平台版本还是需要申请测试名额，只能再等等！
- Windows 10/11
- macOS
- iOS/iPadOS
- Web 浏览器
打开 Windows App 并成功登录，可以看到在界面下主要分为两种资源类型：设备 和 应用。其中设备主要包含了“W365、AVD、DevBox”这里的资源，而应用主要包含的是“Remote App”。
因 gOxiA 的测试账号仅分配了 AVD 和 Remote App 资源，如下图所示。在连接应用时可以看到运用了 RemoteApp 技术。
对于 Windows App 还是有很多期待的，除了支持主流平台，尽可能的提供最优的连接体验外，也希望能支持更多的企业需求。
HOWTO: 为单网卡 Windows 10/11 配置多路由网关
HOWTO: 为单网卡 Windows 10/11 配置多路由网关
网络环境还是比较简单的，常见的组网方式，要求无线路由（192.168.2.1）下的网络增加一个网络设备（192.168.2.254），且所有客户端都需要经由该网络设备。
实际安装调试时发现，由于是定制版无线路由，DHCP 不支持高级配置功能，无法指定网关。如果通过关闭路由自带的 DHCP 服务，则 PPPOE 将自动切换为桥接模式，导致无法正常上网，后续配置也就无法再继续下去，考虑多方因素，决定改为客户端手动添加路由的方式。
因为是 Windows 10/11 系统，手动添加路由比较简单，通过网卡的“高级 TCP/IP 设置”即可。注意：这里有两个跃点数：手动添加的网关跃点数和自动跃点。
使用命令对于 IT 人员来说是最为便利的，这里推荐使用 PowerShell，可以先 Get-NetAdapter 获取当前系统的网卡基本信息，确认网卡索引号便于后续操作。
然后使用 New-NetRoute 来手动添加路由，将 192.168.2.254 添加到额外的网关中，参考如下命令行：
New-NetRoute -DestinationPrefix 0.0.0.0/0 -NextHop 192.168.2.254 -InterfaceIndex 19
但在添加后使用 Route Print 或 Get-NetRoute 查看会发现两个网关的跃点要么相同，要么额外添加的网关跃点无法优先于默认网关。此时如果我们去修改前面“高级 TCP/IP”设置中的跃点数和自动跃点数会发现也无济于事。
而且当修改额外网关跃点数为0时还是报错，只能设置为1-9999间的跃点数；如果修改了自动跃点还会发现网关的实际跃点数会被累加。
那该如何解决的？其实可以用 Set-NetRoute 对现有路由表进行修改，参考如下命令：
Set-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 19 -NextHop 192.168.2.254 -RouteMetric 0
执行后结果如下所示。
接下来，再调整默认网关的跃点数，将其优先级调后即可。那么什么时候需要修改自动跃点呢？当 Windows 系统有多块网卡，需要对网卡优先级进行调整时才需要使用自动跃点。经 gOxiA 学习梳理，在“高级 TCP/IP 设置”中的网关跃点数其实对应的就是 routemetric，而自动跃点数则对应的 interfacemetric。两者数值会进行累加，形成最终的跃点总数，进行优先级的排列，在 Route Print 中会得以体现。两个跃点的说明参考如下。
两者都是用于网络路由和网络接口的度量值，用于确定数据包的传输优先级和路径选择。虽然它们都是用于网络通信的度量标准，但他们的应用对象和作用范围有所不同。
- RouteMetric，应用于路由的度量值，用于确定通过特定路由传输数据包的优先级。当存在多个路由可供选择时，操作系统将使用具有最低路由度量值的路由来传输数据包。如果路由度量值相同，操作系统会使用其他策略（如最长前缀匹配 - PrefixLength / DestinationPrefix）进行决策。
- InterfaceMetric，应用于网络接口的度量值，用于确定通过特点接口传输数据包的优先级。如果有多个网络接口可供选择，操作系统将使用具有最低接口度量值的接口来传输数据包。如果接口度量值相同，操作系统会使用其他策略（如接口绑定顺序）进行决策。
