UEFI Shell这东西平时不碰的人可能一辈子都用不上可一旦系统引导崩了、固件要刷、双系统启动项乱了它就是最后一道救命门。我前前后后帮人修过好几台开不了机的电脑最后都是靠一个放进U盘里的Shell文件救回来的。问题是网上教程一搜一大把但十篇里有八篇都让你下载EDK2源码自己编译要么是装Nasm、装Python、配置编译环境光看步骤就想关网页。这篇博文就是来终结这个麻烦的直接用别人已经编译好的Shellx64.efi和Shell32.efi双版本一次拿齐做成启动U盘几分钟就能进Shell干活。1. 先搞清楚UEFI Shell到底是什么1.1 一个跑在固件里的微型命令行如果你用过Windows的命令提示符或者Linux的Bash那UEFI Shell可以粗浅地理解为“电脑在进系统之前就能用的小命令行”。它不依赖硬盘里的Windows、Linux也不依赖任何驱动因为它是直接从主板固件UEFI Firmware加载并运行的程序。换句话说只要主板能点亮、CPU能跑Shell就能工作哪怕硬盘里的系统已经完全挂掉。它最大的特点是能直接访问UEFI运行时服务。比如读取内存映射、访问SMBIOS信息、读写NVRAM里的启动项变量、操作磁盘分区里的文件、执行其他的EFI程序。很多主板自带的诊断工具、固件刷新程序本质上也都是在Shell环境里跑的一个EFI文件。我自己的习惯是把它当成一个“系统没进之前的救援终端”。Windows挂掉进不去桌面Linux引导丢失或者双系统之间互相覆盖了引导项很多时候你不需要重装系统只需要在Shell里把正确的EFI文件拷贝到ESP分区或者用命令调整一下启动顺序机器就活过来了。1.2 为什么网上都在说“自己编译”UEFI Shell本身是开源项目TianoCore EDK2的一部分。EDK2是UEFI固件开发的标准框架想从源码编译Shell你得准备好一整套工具链Python、Nasm汇编器、VS或者GCC交叉编译环境、Nt32Pkg或者ShellPkg的构建脚本还要根据目标平台设架构、选编DEBUG还是RELEASE模式。我第一次按教程编译的时候光折腾环境就花了两个多小时中途遇到各种版本不匹配Nasm版本太新了报错Python位数不对又报错最后Build出来的Shell.efi还因为启用了不同的编译宏导致在部分机器上加载后直接黑屏。后来我才反应过来官方和其它开源项目其实早就放出了预编译好的Shell二进制包只是信息散落在Release页面和固件包里很多人不知道而已。所以“告别编译”这件事本质上不是偷懒而是把时间花在更有价值的地方。就像你装个数据库没必要从编译PostgreSQL源码开始一样Shell这种工具拿来就用才是正解。1.3 你到底在哪些场景下会用到它系统引导坏了开机黑屏只剩光标或者提示找不到启动设备进Shell把EFI\Microsoft\Boot\bootmgfw.efi拷回正确位置或用bcfg命令重建启动项。双系统管理装了Windows和Linux重启后启动菜单被某个系统更新吃掉在Shell里改BootOrder调整开机默认项。固件与硬件操作刷BIOS、跑内存测试工具、查看机器序列号、读取温度传感器很多厂商的诊断EFI工具都要从Shell里启动。分区和文件系统应急Windows磁盘管理进不去的时候在Shell里查看ESP分区内容、拷贝备份文件比挂载第三方PE系统更简单。这几类场景里维修人员用得最多的是前两个。我自己遇到最多的就是“用户手误用DiskGenius重建了ESP分区导致Windows起不来”这种问题在Shell下解决就是几分钟的事。2. 32位和64位双版本怎么选别再拿错文件2.1 x64与IA32的区别不只是CPU位数先说结论绝大多数普通台式和笔记本用64位UEFI Shell也就是x64版本少数老平板、Atom平台的设备固件是32位UEFI必须用IA32版本。这里有一个很常见的误区你以为64位CPU就要用64位Shell但事情没这么简单。UEFI固件本身也是分32位和64位的。有些老设备用的是32位UEFI固件就算CPU支持64位指令它在加载EFI程序时依然只能运行IA32格式的Shell。反过来64位UEFI固件能不能跑32位Shell文件大多数情况不行Shell加载时会直接报不兼容。所以拿到预编译文件的时候两个版本都应该留着Shellx64.efi对应64位UEFIShell32.efi对应32位UEFI。从命名上很多人以为Shell32是32位CPU用的、Shellx64是64位CPU用的实际上标准叫法是IA32和X64指的是固件架构不完全是CPU型号。把两个文件都放进同一个FAT分区用哪个就复制哪个出来改名这是最稳妥的。2.2 怎么快速确认你的机器用哪套UEFI如果机器还能进系统方法很简单Windows下按WinR输入msinfo32回车打开系统信息。看“BIOS模式”这一项如果显示“UEFI”再配合处理器架构判断基本上可以确定用x64版本。不过这个字段不会直接告诉你UEFI固件是32位还是64位所以更靠谱的方法是看系统类型64位操作系统通常对应64位UEFI但也不是100%老平板确实存在过64位系统配32位UEFI的怪异组合。最稳妥的办法是直接进主板固件设置开机按Del/F2/F10/F12在启动或者引导选项里看看有没有 “UEFI Shell” 这个启动项。如果有说明板上可能内置了Shell如果没有就做两个版本的启动U盘都试一下哪个能正常进入Shell界面就用哪个。如果机器已经无法进系统那就更难判断了。我的经验是先看CPU型号如果是Atom Z37xx、Bay Trail平台或者一些老款Intel平板优先用32位Shell如果是正常酷睿平台直接x64。反正两个文件都放U盘里启动时用哪个就选哪个成本很低。2.3 文件名、目录规范与FAT格式UEFI固件在启动时会按照标准路径查找引导文件。对于可移动设备U盘通用回退路径是64位固件\EFI\BOOT\BOOTX64.EFI32位固件\EFI\BOOT\BOOTIA32.EFI注意大小写不敏感但扩展名必须是.EFI。ESD分区和U盘的文件系统必须是FAT16或FAT32NTFS在多数UEFI固件里是不认的exFAT支持情况也参差不齐。还要注意一点Shell程序文件名虽然最常见的叫Shellx64.efi但你完全可以直接把它重命名为BOOTX64.EFI放到引导路径下这样开机时U盘就会被识别为可启动设备。原文件名更多是在你已经进入Shell之后再手动执行其它EFI文件时才需要区分。3. 不编译那可用的Shell文件从哪里来3.1 开源项目的Release页面TianoCore EDK2项目本身以及下游的一些组件会在发布新版本时附带预编译好的UEFI Shell二进制文件。你去GitHub上找到TianoCore的EDK2仓库切到Releases标签页在资产列表里找带“Shell”字样的zip压缩包通常里面会包含Shellx64.efi和Shell32.efi。这里有个重要提醒下载EFI文件跟下载安装包不一样你要尽量认准官方或官方衍生源的发布渠道不要从乱七八糟的小网站拿一个来路不明的efi。因为EFI程序在系统启动前运行拥有极高的权限一旦被植入恶意代码整个机器都在别人手里。我见过有人在“XX下载站”下载的所谓Shell工具包里面混着奇怪的inf文件怎么看都不对劲。下载之后我习惯用SHA256校验一下官方Release页面一般会贴出哈希值用PowerShell的Get-FileHash命令就能算出来。对不上就直接删掉重下。3.2 从主板厂商的固件包里提取这个方法知道的人相对少但非常实用很多主板厂商尤其是DELL、联想、HP这些品牌机在发布BIOS更新包时会把UEFI Shell程序一并打包进去用于固件刷新和诊断。这些固件包通常是PE格式的可执行文件或者压缩的exe你可以用7-Zip右键解压在解压出来的内容里找带有“Shell.efi”或“ShellX64.efi”字样的文件。为什么品牌机的固件包里会有Shell因为售后工程师需要用它做底层检测比如脱离操作系统跑内存测试、读取维修记录、刷新固件。这些文件都是厂商从官方渠道拿来的签名相对完整来源清晰。从固件包里提取Shell有一个额外好处有些机器对EFI程序的签名要求很严格厂商包里的Shell如果带签名在开着Secure Boot的情况下也能直接跑这比市面上散装的Shell文件省事得多。提取时注意用7-Zip而不是直接双击运行那个exe避免真的触发BIOS升级。我是先把整个exe解压到临时文件夹然后在里面搜索“*.efi”再把看起来像Shell的文件复制出来。有的固件包结构复杂可能要解压两层但整体不难。3.3 拿到EFI文件后先做这几件事再谈启动第一右键查看文件属性里的数字签名标签。正常的EFI文件应该有签名签名状态显示“正常”。如果完全没有签名或者签名损坏要慎重使用除非你清楚它来自哪里。第二把文件放到U盘之前先用7-Zip重新打开看看能不能正常解压——这是最粗糙但有效的文件完整性检查。很多下载工具下到一半断线了文件看起来还在实际已经损坏放进U盘后开机根本加载不了。第三建议同时保留两个版本。我自己的应急U盘里建了一个EFI\Shell文件夹里面同时放了Shellx64.efi和Shell32.efi再用EFI\BOOT放BOOTX64.EFI作为默认引导副本。这样不管是正常台机还是老平台都能应付。4. 制作一个能开机的UEFI Shell优盘4.1 最省事的做法改写BOOT路径如果你只需要一个纯粹的Shell启动盘做法非常简单准备一个U盘格式化成FAT32。U盘容量无所谓512MB的旧U盘都行。然后在这个U盘里建立一个EFI文件夹里面再建BOOT文件夹把你需要的Shell文件复制进去重命名为BOOTX64.EFI64位机器或BOOTIA32.EFI32位机器。实际操作时我常用的做法是先建一个完整的目录结构U盘根目录 ├── EFI │ ├── BOOT │ │ ├── BOOTX64.EFI (从Shellx64.efi复制后改名) │ │ └── BOOTIA32.EFI (从Shell32.efi复制后改名) │ └── Shell │ ├── Shellx64.efi │ └── Shell32.efi这个结构的好处是默认引导走EFI\BOOT\BOOTX64.EFI或者BOOTIA32.EFI进Shell之后如果你想再跑别的工具可以到EFI\Shell下面找原始文件。两个版本都放了去别的机器上也不用手忙脚乱改名字。4.2 开机进Shell的完整路径做完U盘之后开机进BIOS设置找到启动菜单或者启动顺序把U盘调成第一启动项。有些主板需要关闭Secure Boot才能引导自制的ShellU盘这个后面专门说。设置好之后重启UEFI固件会正常加载EFI\BOOT\BOOTX64.EFI进入Shell界面。如果看到类似这样的输出UEFI Interactive Shell v2.2 EDK II UEFI v2.70 (American Megatrends, 0xFFFF0000) Mapping table: FS0: Removable HardDisk - Alias (null)说明已经成功了。这时候你可以输入map看到设备映射表输入ver看版本信息输入help查看内置命令列表。这里有一个实用的排除技巧如果你把U盘插上去开机却直接进了系统没启动U盘先不要怀疑U盘坏了大概率是BIOS里的启动顺序不对或者Secure Boot拦截了。先去启动菜单里手动选择U盘一次看它能不能出现在启动列表里。4.3 不改U盘原有结构进Shell之后再加载有时候你不想把U盘格式化成Shell专用盘比如U盘里已经拷好了系统镜像和PE工具。这时候可以把Shell文件放进U盘某个角落开机先进入已有的引导环境再从那个环境里加载Shell。一个典型的场景U盘里原本有Windows PE开机后PE的启动菜单加载了bootx64.efi然后你进到PE桌面打开命令行手动执行U盘里的Shellx64.efi。不过这种方式走的已经不是纯UEFI的路径了是PE环境模拟加载实际用起来不如直接做成Shell启动盘顺手。更规范的做法是把Shell文件放进ESP分区并添加为固件启动项。具体在Shell环境下用bcfg命令操作下一节会详细讲。4.4 把Shell加到固件启动项里如果你经常要进Shell每次插U盘太麻烦不如直接把Shell装进电脑自身的ESP分区然后在NVRAM里登记一个启动项。前提是你能进入Shell一次比如用U盘启动。进入Shell之后先找到存放ESP分区通常是FS0或FS1把Shell文件复制到ESP的\EFI\Shell\目录下然后用bcfg命令添加启动项FS0: mkdir EFI\Shell cp FS0:\EFI\Shell\Shellx64.efi FS0:\EFI\Shell\Shellx64.efi如果你的Shell文件是从U盘加载的U盘可能叫FS0本机ESP叫FS1具体要结合map命令的输出判断。添加启动项的命令是bcfg boot add 0 FS1:\EFI\Shell\Shellx64.efi UEFI Shell这样固件启动项列表里就会出现一个名叫“UEFI Shell”的项排在第0位可能是默认首位。重启后按F12或者进BIOS启动菜单就能直接选它不用再插U盘。我第一次在朋友的机器上操作时因为ESP分区号判断错了命令写成了FS0结果后来启动菜单里出了两个同名项。所以建议你在执行bcfg之前先仔细用map确认盘符和目录都存在。不确定的时候就多打几遍map -r重新扫描。5. 进Shell之后最常用的几组命令5.1 先认识设备map / ls / cd / fs0:初进Shell界面很多人会被一堆输出搞懵。其实无需紧张最先学会的三件事就是看设备、切换设备、看文件。map -r这个命令会重新扫描所有连接的设备。重要的一行信息是形如FS0:、FS1:、BLK0:、BLK1:这样的映射。FS开头的一般表示带文件系统的分区你能直接进去操作文件BLK开头的是“裸块设备”通常没有可识别的文件系统命令行操作起来不直观。切换设备的方法是输入盘符加冒号FS0:然后就可以用熟悉的命令了ls cd EFI ls type path\to\file.txt比如想知道当前目录是哪里输入pwd想查看内存映射输入memmap想退出Shell重启电脑输入reset。这些命令跟DOS时代很像用起来没有学习成本。我刚接触Shell的时候犯过一个低級错误直接在根目录下用ls想看整个磁盘结果发现它只能看当前文件系统看不到别的分区。后来才知道要找ESP分区里的文件得先用map列出来再FS0、FS1一个个切进去看看到EFI文件夹的那个就是。5.2 修复Windows引导这是最高频的需求很多人进Shell就是为了修Windows引导。最常见的情况就是开机黑屏提示找不到启动设备或者出现了类似“文件\EFI\Microsoft\Boot\bootmgfw.efi状态0xc000000f”的报错。先解释一下Windows在UEFI模式下的引导链路主板加载ESP分区中的\EFI\Microsoft\Boot\bootmgfw.efi它再启动Windows Boot Manager接着引导操作系统。如果这个文件丢失了、ESP分区被误格式化、或者引导项错乱就会出现上面的报错。在Shell里修复的常规思路是先把ESP分区挂载出来。如果你能进Shell磁盘分区一般已经自动映射了FS0、FS1等。用ls一个一个找找到含EFI文件夹的那个盘就是ESP分区。假设它是FS0FS0: ls EFI如果能看到Microsoft文件夹说明文件其实还在问题多半出在启动项上。可以先用bcfg查看现有启动项bcfg boot dump如果显示启动项数量为0或者指向的错误文件就手动添加一个指向正确路径的启动项bcfg boot add 0 FS0:\EFI\Microsoft\Boot\bootmgfw.efi Windows Boot Manager这个做法比用PE盘启动再跑bcdboot轻量得多。如果文件真的丢了那么只能从Windows安装U盘的相同路径拷贝一份bootmgfw.efi或者用PE里的bcdboot重新生成引导文件。不过拷贝完文件之后依然要回到Shell里用bcfg重建启动项这一步避不开。5.3 管理双系统引导与启动顺序装了Windows和Linux双系统的人有时会遇到开机默认进Windows或者默认进Linux的问题。如果你进系统里改grub麻烦直接进Shell改BootOrder反而更快。命令格式是bcfg boot dump -v看到所有启动项的编号再调整顺序。比如要把Linux引导放到第一位可以先删掉再添加bcfg boot rm 2 bcfg boot add 0 FS0:\EFI\ubuntu\shimx64.efi Ubuntu不过实际操作时我很少删原有项因为误删之后还是得重建。我习惯先用dmpstore命令导出当前NVRAM里的BootOrder变量做个备份dmpstore BootOrder看到输出里那一串十六进制编号按照从高位到低位的顺序就是当前启动项的优先级。你先截图或记录下来万一改错了还能恢复。踩过一次坑之后现在凡是要动启动项我第一步永远是dmpstore备份。5.4 在Shell里运行硬件检测和固件工具Shell不只是修引导用的。很多硬件厂商提供独立的EFI诊断工具比如内存测试工具MemTest86的EFI版本、固态硬盘固件升级程序、主板BIOS刷新程序都可以放进U盘在Shell下用一条命令运行。操作逻辑很简单把工具EFI文件放到Shell启动盘根目录或者EFI\Tools目录重启进入Shell切换盘符后执行FS0: EFI\Tools\memtest.efi这里的“工具EFI文件”可以是直接从厂商官网下载的固件升级程序比如戴尔的BIOS升级包解压后可能有个BIOS_PRE.efi联想的主板诊断工具也可能是一个efi。使用原厂工具刷BIOS比Windows下刷更安全因为系统没有启动、没有驱动干扰固件刷新过程中的变量冲突少得多。需要注意的细节是运行某些工具之前可能需要加载对应的驱动或者设置正确的启动环境变量。好在多数EFI工具都做了封装双击式运行即可。如果遇到命令输入完没有任何输出可以先检查文件所在路径是否正确再用ls确认目录里的文件名大小写。6. 高频问题与踩坑记录6.1 一选Shell就报Security Violation这是最常见的一个坑。开机选择U盘Shell启动项屏幕上蹦出“Security Violation”或者“Verification failed: (0x1A) Security Violation”基本可以确定是Secure Boot在拦你。UEFI固件的Secure Boot机制只信任有合法签名的引导程序。微软签名的Windows引导器能过检但你自己做的ShellU盘如果用的Shell文件没有正确签名就会被拒之门外。这时候得当肯关闭Secure Boot开机进BIOS设置找到Security或者Boot菜单把Secure Boot设置为Disabled保存退出。注意有的主板还要先切到自定义模式才能改变Secure Boot状态这个因品牌而异。我自己试过一些号称带签名的Shell文件在有Secure Boot的机器上依然可能失败因为签名链不完整。所以最稳妥的方案仍然是进BIOS关掉Secure Boot再做应急维护修完之后再打开。如果你不想关那就优先从主板固件包里提取官方Shell文件成功率更高。6.2 U盘插上后Shell里看不到盘进了Shell输入map发现只有BLK设备没有FS设备U盘识别不了。这时候先排除两个问题第一U盘文件系统格式不对。NTFS格式的U盘在大多数UEFI环境里不被识别Shell下根本看不到FS映射。把U盘改成FAT32格式问题立刻解决。如果你非要存大文件可以先做一个小容量FAT32分区放Shell再用另一个分区放其他数据。第二U盘插在了非原生接口上。有些机器的USB 3.0扩展卡在UEFI阶段没有驱动识别不了U盘换个主板原生USB口或者前置USB2.0口再试。这个坑在旧主板上特别明显别怀疑U盘坏了先换接口。如果map里还是没显示U盘可以在Shell命令行输入map -r强制重新扫描设备映射。有时候设备插上但映射表没刷新运行这条命令之后FS0就出现了。6.3 32位Shell在64位机器上启动失败很多人会尝试在64位UEFI固件的机器上运行Shell32.efi结果Shell文件加载了一半就黑屏重启或者提示类似“Unsupported executable format”的信息。这是因为64位UEFI固件只认PE32格式的X64程序而Shell32.efi是PE32格式的IA32程序两者不兼容。反过来32位固件通常也无法运行64位Shell。判断方法很简单还是一样做两个启动文件开机选择能用的那个。如果你已经确定了机器是64位UEFI就直接用Shellx64.efi不用浪费时间试32位版本。还有一个相关的小坑从网上下载到的Shell文件本身可能也分“带SHELL_CERTIFICATE签名”和“不带签名”的版本来源不同加载行为也不同。功能上基本一致优先选带签名的。6.4 文件都在却执行后黑屏/重启ShellU盘能进目录也能看到文件但执行某个EFI工具时屏幕黑一下、机器直接重启了这个现象在运行一些老工具时特别常见。原因多半是版本兼容性问题工具EFI是为特定架构编译的你选错了版本或者工具依赖的主板服务在当前状态下不可用比如某些固件更新工具要求必须关闭CSMCompatibility Support Module。我遇到过一台老联想机器运行诊断EFI工具需要把BIOS里的CSM关掉否则工具启动直接崩溃。这个不试几次根本猜不到。另外一个可能原因是非原厂Shell环境缺少某些协议。正常来说EDK2 Shell自带的协议比较全但从固件包里提取的Shell可能与部分步骤不兼容而且提取的Shell可能被厂商裁剪过。遇到这样的问题换官方Release版的Shell再试很多时候就好了。6.5 启动项改乱了怎么恢复这是一个必须认真对待的风险。修改bcfg或者dmpstore之后启动项乱了重启机器可能直接黑屏找不到任何引导程序。好在这时候ShellU盘还能派上用场。插上U盘启动进入Shell重新用bcfg查看bcfg boot dump如果启动项列表是空的就逐个手动添加回正确的EFI路径。比如Windows的启动项重新指向\EFI\Microsoft\Boot\bootmgfw.efiLinux指向\EFI\ubuntu\shimx64.efi或者grubx64.efi。添加完之后用bcfg boot order设置一下就恢复原状了。如果U盘也进不去Shell了那就只能拆机或者用BIOS的恢复模式。所以我在前面一直强调执行任何修改NVRAM的操作之前先用dmpstore把BootOrder导出来存到文件里或者用手机拍照留存。这是我在修过太多“本来只想改一下启动项结果整台机器开不了机”的案例之后得出的血泪经验。最后分享一个我自己的习惯做好的Shell启动U盘上面贴上标签放进工具箱里常备。因为它的用途远不止“进Shell”这一个——里面既有Shellx64.efi和Shell32.efi又放了MemTest86和几个常用品牌机的固件刷写工具再配合一份Windows安装镜像基本可以应付九成以上的“电脑进不去系统”问题。平常不觉得真到哪天机器开不了机你会感谢这个几MB的小文件。