1、基于BCDEDIT的方案是不可靠的。一些情况下bcdedit根本就运行不了。
2、基于setupact.log判断的 ...
方案1貌似有点问题，win7 x64 的 UEFI 启动它判断成 BIOS 启动了。 本帖最后由 liuzhaoyzz 于 2019-3-26 10:05 编辑
adef 发表于 2019-3-26 09:45
方案1貌似有点问题，win7 x64 的 UEFI 启动它判断成 BIOS 启动了。
兄弟你说得对，他这个方案，UEFI-WIN7确实判断是错误的，我刚才亲测。UEFI-WIN7下面根本就没有那个主键HKLM\HARDWARE\UEFI，看样子2010hook的方案，还是不靠谱。还是要靠windows api。 本帖最后由 dos时代菜鸟 于 2019-3-26 10:38 编辑
说到 api
刚测试 powershell 3.0 有一句 可以成功
(Get-SecureBootuefi -name setupmode)>$nul
$?
还有 ，如果用 rundll32.exe 调用 kernel32.dll 中的 GetFirmwareEnvironmentVariableA 函数，句柄应该怎么写？ dos时代菜鸟 发表于 2019-3-26 10:28
说到 api
刚测试 powershell 3.0 有一句 可以成功
基于powershell的方案是不可靠的，很多系统早已精简powershell。 liuzhaoyzz 发表于 2019-3-26 10:31
基于powershell的方案是不可靠的，很多系统早已精简powershell。
还有 ，如果用 rundll32.exe 调用 kernel32.dll 中的 GetFirmwareEnvironmentVariableA 函数，句柄应该怎么写？ dos时代菜鸟 发表于 2019-3-26 10:39
还有 ，如果用 rundll32.exe 调用 kernel32.dll 中的 GetFirmwareEnvironmentVariableA 函数，句柄应该怎 ...
frg521是不是在楼上给出的有例子，我没有试过。 liuzhaoyzz 发表于 2019-3-26 10:57
frg521是不是在楼上给出的有例子，我没有试过。
rundll32 kernel32.dll,GetFirmwareEnvironmentVariableA "","{00000000-0000-0000-0000-000000000000}","",0
可以运行但无法取结果
本课题 脚本解决方案 是 调用 pecmd 加载 kernel32.dll 的 api 句柄
pecmd 脚本内容如下：
CALL $**c **ret:* C:\windows\system32\Kernel32.dll,GetFirmwareEnvironmentVariableW, mode1,,{00000000-0000-0000-0000-000000000000},,4096
CALL $ **ret:mode1 C:\windows\system32\Kernel32.dll,GetLastError
IFEX $%mode1% = 1 ,ENVI MODE1=BIOS! find $%mode1%=998 ,ENVI MODE1=uefi ! ENVI MODE1=Unknow
MESS %mode1% frg521 发表于 2019-3-27 09:38
...
主要是 编程序需要编译，所以 第一考虑 用 脚本。
本帖最后由 liuzhaoyzz 于 2019-3-27 11:06 编辑
2010hook兄，你说的Win7不支持UEFI，我的判断结果是对的 ，这让我很惊讶。。。这不是强词夺理吗？
我有个电脑就是UEFI启动的WIN7，Bootice判断正确，bootmode判断正确，detectefi判断正确，就是按你的批处理方案判断错误的。
另外，个人感觉调用PECMD来判断，我觉得还不如直接用adef推荐的detectefi来判断，我的潜意识里面，更觉得PECMD应该生活在PE里面，正常的windows系统，从文件体积来说，是不是用编译好的成品更好，detectefi只有23KB，这个文件体积可以忽略不计了，PECMD.EXE还有482KB呢，对于正常的windows，也算是个外置命令，个人的爱好吧，权当瞎聊。 本帖最后由 dos时代菜鸟 于 2019-3-27 11:44 编辑
我这个 win10 ltsc 2019 是通过 legacy 方式安装的，然后 主板支持 uefi 我就 在另一个 gpt 硬盘上弄了个 引导他的 bcd ，用来通过 uefi 引导这个 win10 ，就是为了 研究两种启动方式，这样通过uefi 启动进入 ltsc2019 确实 注册表中没有 HKLM\HARDWARE\UEFI 这个分支。
另外
detectefi.exe 这个程序 小巧实用，确实不错
我觉得吧，
如果是 pe环境 用一个 pecmd 脚本 应该是最好的，可以嵌入其它 pecmd 脚本
对于 win 10 系统下，用 powershell 一句话就能搞定，win7 就 不知道了。
把几个 方案 都放到 1楼 了，pecmd 脚本方案 也做了些 改进。 frg521 发表于 2019-3-30 23:36
...
你这是干啥，怕出名吗？ frg521 发表于 2019-3-30 23:36
...
收下，谢谢 可以通过diskpart 检测有没有esp分区来测试嘛 收下了，谢谢楼主分享成果。 dsxmg1990 发表于 2019-4-5 15:52
可以通过diskpart 检测有没有esp分区来测试嘛
不准确，uefi 模式下也可以通过 mbr 方式启动，调用 mbr 硬盘上 Fat32 分区上的 efi ，
所谓的 3 启 u 盘 就是这个原理。 adef 发表于 2019-3-26 09:40
网上有小工具，https://github.com/xcat2/xcat-core/tree/master/xCAT-server/share/xcat/netboot/windows
...
adef兄，
你提供的detectefi有问题，只适用于64位系统，这个detectefi.exe是64位VC8.0编写的，因此用于32位系统会出错。这里有个问题：
32位系统下面有UEFI启动吗？结果是有的，虽然32位的UEFI固件很少，问题是：我在32位系统下运行这个64位的detectefi.exe，直接报错，如果在批处理中调用，会影响后面的判断。期待提供32位的detectefi程序。
直接上图吧。
liuzhaoyzz 发表于 2019-4-14 23:23
adef兄，
你提供的detectefi有问题，只适用于64位系统，这个detectefi.exe是64位VC8.0编写的，因 ...
本帖最后由 liuzhaoyzz 于 2019-5-15 19:05 编辑
adef 发表于 2019-4-15 07:06
感谢！试了下你提供的32位的DetectEFIx86.exe用于32位和64位，我测试了用于64位的UEFI-WIN7 8 10，没问题。32位的只测试了32位的BIOS启动WIN7也没问题，因为没有32位的UEFI固件没法测试。这样说来，64位的detectefi完全没必要存在了，32位的适用性更好！ 友请楼主"DOS时代高手"{:1_193:} 把他这个DetectEFIx86.exe放到一楼进行替换。
我编译的bootmode也只编译了32位的版本，用于64位的系统没有问题。bootice也是这样子的，x86版本就可以准确地判断出当前BIOS/UEFI启动模式。 本帖最后由 liuzhaoyzz 于 2019-5-15 19:12 编辑
adef 发表于 2019-4-15 07:06
还是要再次麻烦下adef兄弟，你的DetectEFIx86在xp下面根本运行不了啊，提示出错。是怎么回事？vc2008等运行库已经安装过了。
是不支持XP吗？
分享
本帖最后由 liuzhaoyzz 于 2019-5-18 18:24 编辑求人不如求己啊！我下载了adef兄的https://github.com/xcat2/xcat-core/tree/master/xCAT-server/share/xcat/netboot/windows源代码，然后用VS2008重新编译，编译的时候选择静态编译，右键项目，属性->配置属性->常规->MFC的使用，选择“在静态库中使用MFC”。编译为32位程序，编译后exe文件52KB，亲测适用于XP，64位的WIN7 10，检测BIOS/UEFI启动模式正确无误。为了区别于adef兄的detectefiX86.exe（45KB），特地改名字为detectefi32.exe（52KB）。现奉上源代码和编译后的exe文件。
多谢分享，，，，，，，，，，，，，， 多谢分享，，，，，，，，，，，，，， 1楼的PECMD代码已经不能适应 Windows 10.0.0.19041，无论是UEFI环境还是LEGACY环境，检测出来的结果都是“1314”，而不是“1”或者“998”。
Anson4 发表于 2020-3-19 14:27
1楼的PECMD代码已经不能适应 Windows 10.0.0.19041，无论是UEFI环境还是LEGACY环境，检测出来的结果都是“1 ...
特意 弄个 1909 的 win10 测试了下，没问题。
有图有真相。
dos时代菜鸟 发表于 2020-5-7 09:47
特意 弄个 1909 的 win10 测试了下，没问题。
有图有真相。
1909的版本号是Windows 10.0.0.18363，2004的版本号才是Windows 10.0.0.19041，其正式版即将到来。 本帖最后由 dos时代菜鸟 于 2020-5-8 07:08 编辑
Anson4 发表于 2020-5-7 22:51
1909的版本号是Windows 10.0.0.18363，2004的版本号才是Windows 10.0.0.19041，其正式版即将到来。
好吧，好吧，看来 还要等正式的出来了，才能再确定下。
还要看看，那几个 exe 方案能否有效。另外 1314 码 对应的应该是 权限问题，你不妨 用管理员权限 运行 再试试。
dos时代菜鸟 发表于 2020-5-8 07:01
好吧，好吧，看来 还要等正式的出来了，才能再确定下。
还要看看，那几个 exe 方案能否有效。另外 1314...
已经用了管理员权限了 Anson4 发表于 2020-5-8 12:29
已经用了管理员权限了
pe 下呢？