PowerShell 7.5 启动崩溃怎么排查：面向新手的完整修复指南
项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell PowerShell 7.5 是一款跨平台的命令行工具与脚本环境，很多 Windows 用户升级后遇到"PowerShell 7.5 启动崩溃"：窗口一闪就灭、没有报错、或者一敲命令就退出。本文按"先定位、再修复、后验证"的思路，帮你用最短路径把问题修好。
一分钟判断：你的症状属于哪一类
先打开任意可用的 PowerShell 窗口（比如 Windows 自带的 Windows PowerShell 5.1），对照下面几种典型表现，确认自己踩中哪一种。
- 窗口一闪而过，控制台没有任何输出
pwsh -v提示无法识别、或直接退出- 启动后报"找不到或无法加载 .NET 运行时"类错误
- 提示脚本被禁止运行（执行策略拦截）
- 只有个别命令报错，普通命令正常
不同症状对应的修复路径完全不同。闪退和策略拦截的修法不一样，先对号入座，后面的排查可以跳过不相关的步骤。
现象、原因与影响对照表
| 现象 | 最可能的原因 | 对你的影响 |
|---|---|---|
| 窗口一闪而过，无输出 | 配置文件执行出错，或 .NET 9 运行时缺失 | 完全无法进入 PowerShell 环境 |
| 明确提示找不到 .NET 运行时 | PowerShell 7.5 基于 .NET 9 构建（可以理解为程序的底层引擎），引擎不在就起不来 | 启动直接失败 |
| 提示"脚本被禁止运行" | 执行策略或组策略拦截 | 能进入窗口，但脚本/配置全部被拒 |
| 旧系统上启动即失败 | 低于最低版本要求：Windows 10 1607 / Server 2016+，不支持 Win 7/8.1 | 任何修复都无效，需升级系统 |
排查步骤 1：30 秒确认系统版本是否达标
PowerShell 7.5 在 Windows 上的最低要求是 Windows 10 1607 或更高版本（含 Windows Server 2016+），Windows 7、8.1 及 Server 2012 R2 以下版本不受支持。运行下面这条命令，把系统版本打印出来：
[System.Environment]::OSVersion.Version
预期看到类似 10.0.19045 的版本号。第一个字段是 10，第二个字段（Build 号）14393 以上即 1607。如果 Build 号低于 14393，先升级操作系统再继续，其他步骤在这个系统上无效。
排查步骤 2：确认 PowerShell 7.5 本身装好了没
确认实际安装的版本，并找到主程序位置：
pwsh -NoProfile -v
Get-Command pwsh -ErrorAction SilentlyContinue
第一条命令预期返回 7.5.x。如果提示"无法将 'pwsh' 项识别为……"，说明程序没装好或不在当前 PATH 中——直接重新安装即可，后面所有步骤都可以跳过。重装时注意：用你当初首次安装相同的方式安装，升级方式与安装方式要保持一致。
排查步骤 3：检查 .NET 运行时是否齐全
这是"PowerShell 7.5 启动崩溃"最常见的原因。运行下面命令列出系统里已安装的全部 .NET 运行时：
dotnet --list-runtimes
预期在输出中看到 Microsoft.NETCore.App 9.x.x 这一行。PowerShell 7.5 运行在 .NET 9 之上，缺 9.x 或只剩低版本，进程会在启动早期直接退出，而且往往不留任何报错——这正是"闪退"的典型来源。
处理方式按简单到复杂排序：
- 打开"设置 → 应用 → 已安装的应用"，找到 PowerShell 7 卸载后重新安装，安装程序会带上配套的运行时。
- 重新安装后关闭所有终端窗口再重试（PATH 变化需要新进程才能生效）。
- 仍报错时，对照
dotnet --list-runtimes的输出再装一次 .NET 9 桌面运行时，确保版本 ≥ 9.0。
排查步骤 4：用"免配置启动"排除 $PROFILE 干扰
配置文件（每次启动 PowerShell 时自动执行的个人脚本）语法写错或调用了已卸载模块的命令，都会让窗口刚打开就退出。先用跳过配置的方式启动，这是判断问题归属最快的一步：
pwsh -NoProfile
如果这样能正常进入，问题基本可以锁定在配置文件上。接下来备份旧配置，为回退留好后路（把 Microsoft.PowerShell_profile.ps1 重命名为 .old）：
Rename-Item -Path (Join-Path (Split-Path $PROFILE) 'Microsoft.PowerShell_profile.ps1') -NewName 'Microsoft.PowerShell_profile.ps1.old'
然后正常执行 pwsh 打开 PowerShell 7.5。启动不再闪退，说明就是旧配置作的怪。把改名后的旧文件用记事本打开，重点检查两类问题：调用了已被卸载模块的函数、以及过时的赋值或拼写语法。修好之后把 .old 后缀去掉即可恢复配置；想快速对比新旧差异，可以跑：
Compare-Object (Get-Content $PROFILE.old) (Get-Content $PROFILE)
排查步骤 5：执行策略与安全软件拦截
如果窗口能打开，但提示"无法加载，因为在此系统上禁止运行脚本"，说明是执行策略在拦截。先查看当前策略：
Get-ExecutionPolicy -List
在 LocalMachine 或 CurrentUser 级别看到 Restricted 就会触发此类拦截。普通用户的稳妥做法是把当前用户的策略调成 RemoteSigned（本机脚本可执行，网上下载的脚本需签名）：
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
如果公司电脑上这条命令不生效，说明策略来自组策略或第三方安全软件。此时打开"组策略编辑器"（gpedit.msc），依次查看：计算机配置 → 管理模板 → Windows 组件 → Windows PowerShell，确认"允许本地 PowerShell 脚本运行"相关项没有被设为禁止；再查看安全软件的拦截日志，把 pwsh.exe（通常位于 C:\Program Files\PowerShell\7）加入信任。
排查步骤 6：事件查看器里翻"死亡现场"
前面都排不掉时，让系统日志说话。按 Win + X 选择"事件查看器"，展开"Windows 日志 → 应用程序"，在右侧点"筛选当前日志"，把来源过滤为 Application Error 或 .NET Runtime，时间范围选到今天，就能找到 pwsh 崩溃时记录的具体模块与异常信息，把它作为修复依据或反馈材料。
顺带解释：崩溃信息里经常出现的 System.Management.Automation 是 PowerShell 的核心引擎程序集（源码见 src/System.Management.Automation/），看到它的名字不代表你的配置文件错了，只是说明进程在引擎加载阶段就退出了。
怎么确认问题已经修好
修复动作做完后，按顺序过一遍下面三步，全过才算解决：
- 运行
pwsh -v，返回7.5.x而不是报错。 - 运行
$PSVersionTable.PSVersion | Format-List，看到Major 7、Minor 5等字段完整输出。 - 直接执行
pwsh正常打开，静置 30 秒以上不闪退，并且你备份恢复过的配置文件也能正常执行。
防复发：升级与日常维护
- 升级时保持安装方式一致（当初用 MSI 就用 MSI 升级），混用安装方式是环境错乱的常见来源。
- 修改
$PROFILE前先复制一份备份，改完立即启动一次验证，不要攒一堆改动再试。 - 关注项目内的版本动态：7.5 变更日志 记录了 7.5.x 各次修复的内容，官方变更日志总目录 可以查到全部历史版本。
- 环境信息随手可查：
$PSVersionTable能输出版本、平台、主机等完整信息，反馈问题时附上它，定位会快很多。
资源汇总
| 资源 | 路径/入口 |
|---|---|
| 各版本变更日志 | CHANGELOG/README.md |
| 7.5 版本修复明细 | CHANGELOG/7.5.md |
| Windows 环境搭建参考 | docs/building/windows-core.md |
| 常见问题 FAQ | docs/FAQ.md |
| 核心引擎源码 | src/System.Management.Automation/ |
到这里，从系统版本、.NET 运行时、配置文件到执行策略的排查链路就走完了：先对症状、再按步骤修、最后按清单验证，绝大多数 PowerShell 7.5 启动崩溃都能在这条路径上解决。如果照做仍闪退，把事件查看器里的崩溃记录和 pwsh -NoProfile -v 的输出整理好，去官方仓库的 Issue 区提交反馈即可。祝你的 pwsh 从此秒开不闪退。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
