企业官网建设流程全解析

pwsh 7.5 启动闪退排查：从 .NET Runtime 到 $PROFILE 的逐层定位

【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell

Windows 上升级 PowerShell 7.5 后，pwsh启动即退出、窗口一闪而过是常见现象。本文按三条排查路径展开：确认崩溃签名、核对 .NET Runtime 版本、隔离$PROFILE与模块缓存，帮你在十几分钟内定位故障层。

复现启动闪退并确认崩溃签名

打开cmd，用最小参数启动一次，判断崩溃发生在配置层还是核心运行时层：

pwsh -NoProfile -NonInteractive -Command "Write-Output hello" echo $ERRORLEVEL

• 窗口一闪而过、hello未打印、$ERRORLEVEL非 0：确认闪退，继续下一节。
• 正常输出hello且ERRORLEVEL为 0：崩溃由 Profile 或模块触发，直接跳到第 4 节。

再确认机器是否满足 7.5 的系统要求（最低 Windows 10 1607 / Windows Server 2016，参考 构建文档 的测试环境说明）：

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

如果版本号低于 10.0.14393，7.5 本身就不支持，换用 7.4 或更低版本即可。

确认签名时看事件查看器：eventvwr.msc→Windows 日志 → 应用程序，在右侧筛选"错误"级别并搜索pwsh。重点看两条事件：

• ID 1000（应用程序错误）：含"故障模块名称"。若含coreclr或pwsh，指向运行时层，走第 3 节。
• ID 1026（.NET Runtime）：含未处理异常的完整堆栈，能直接看到出问题的程序集，是价值最高的信息。

若两条都没有记录，说明进程在托管代码加载前就退出，优先怀疑安装损坏，跳第 5 节重装。

用 dotnet --list-runtimes 核对 .NET Runtime 版本

PowerShell 7.5 依赖 .NET Runtime 7.0。如果上一节的事件 1026 堆栈里出现System.IO.FileNotFoundException或AssemblyLoadException，先核对本机运行时列表：

dotnet --list-runtimes

输出应包含类似Microsoft.NETCore.App 7.0.x的行。如果列表里没有 7.x、或dotnet命令本身报错，说明运行时缺失：安装官方 .NET 7.0 运行时，重新打开一个终端（PATH 变化不会反映在旧会话里）再跑一次第 1 节的启动命令。仍崩溃就跳到第 5 节。

如果 7.x 存在，用$PSVersionTable确认 pwsh 实际加载的运行环境是否符合预期：

图：正常启动后$PSVersionTable输出，核对 PSVersion、PSEdition 与 OS 三个字段

pwsh -NoProfile -Command "$PSVersionTable | Format-List PSVersion, PSEdition, OS"

预期输出中 PSVersion 为7.5.x、PSEdition 为Core、OS 为 Windows 10/11。字段不符或该命令同样闪退，说明运行时与 pwsh 版本不匹配，转第 5 节。

隔离 $PROFILE：备份后用最小配置文件启动

如果-NoProfile启动正常、带 Profile 就崩溃，问题在配置文件里（升级后旧语法、已移除 cmdlet 的引用）。先看当前配置文件路径和内容首尾：

echo $PROFILE Get-Content $PROFILE -TotalCount 3 -ErrorAction SilentlyContinue

路径形如C:\Users\<you>\Documents\PowerShell\Microsoft.PowerShell_profile.ps1。如果Get-Content无输出，说明文件缺失，$PROFILE这条线排除，跳第 5 节。

文件存在时，备份并换一份最小配置再启动：

Copy-Item $PROFILE "$PROFILE.bak" Set-Content -Path $PROFILE -Value "# minimal profile"

此时启动pwsh：能进交互界面即确认是 Profile 引起的解析失败。用下面命令对比新旧差异，定位到具体语句：

Compare-Object (Get-Content $PROFILE.bak) (Get-Content $PROFILE)

常见元凶：旧版独有 cmdlet、路径不存在的模块Import-Module、PowerShell 7 中语义变化的变量。把可疑语句逐条拷回新 Profile 验证，保留可工作的部分。

清理 ModuleAnalysisCache 排除模块缓存干扰

如果第 2、3 节都没命中，但pwsh正常启动后仍间歇性报错或加载缓慢，怀疑模块分析缓存残留。先列出加载模块，锁定可疑对象：

Get-Module -ListAvailable | Select-Object Name, Version, ModuleBase

然后清空分析缓存（只删缓存，模块本体不受影响），再重启pwsh验证：

Remove-Item "$env:LOCALAPPDATA\Microsoft\PowerShell\7\ModuleAnalysisCache" -Recurse -Force

如果Remove-Item报"找不到路径"，说明目录从未生成，可排除缓存因素，直接跳第 5 节。缓存清空后启动恢复正常，则用Get-Module -ListAvailable输出里版本号异常或路径跨盘的模块逐个排查，重点看第三方模块。

根治：重装对齐版本并固化最小启动环境

确认安装损坏（进程未进托管层、事件无 1026）时，干净重装比修补可靠：

winget uninstall Microsoft.PowerShell winget install Microsoft.PowerShell

要点：用当初的安装方式重装（winget/MSI/DevDiv feed 各渠道注册表状态不同），并确保装完后 .NET Runtime 与 pwsh 版本对齐——7.5 配 7.0 运行时，不要把 7.5 装在只有 8.0 运行时的最小化环境里。装完跑一遍第 1、3 节的验证命令闭环。

长期规避两条：把$PROFILE精简到核心配置，第三方模块的加载挪进独立脚本按需调用，降低升级时的冲突面；升级前查 CHANGELOG/7.5.md 与 CHANGELOG/7.6.md 里的已知问题和回滚建议。

若以上路径走完仍未解决，收集事件查看器的 1026 完整记录和pwsh -NoProfile -Command ...的输出，在仓库 issue 区提交，维护者可据此复现。平时保持 pwsh 发行版与 .NET Runtime 同步更新，是这类启动故障最主要的预防手段。

【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell