PowerShell 核心调试完全指南VS Code、Trace-Command 引擎追踪、LLDB/SOS 与 CoreCLR 原生调试【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell本文为 PowerShell 仓库官方调试指南的深化版覆盖从 C# 源码级调试VS Code OmniSharp、运行时子系统追踪Trace-Command/Get-TraceSource到 Linux 下 LLDB SOS 插件、corehost 宿主追踪、CoreCLR PAL 调试通道以及为 .NET Core 构建调试版运行时的完整链路。读完之后你可以独立搭好跨平台的 PowerShell 开发调试环境并能针对引擎内部行为命令发现、参数绑定、类型转换、模块加载等做定点取证。用 VS Code 调试 C# 源码PowerShell 的 C# 引擎源码支持跨平台调试这在很大程度上依赖 VS Code 的 C# 扩展OmniSharp 提供语言服务与 .NET Core 调试器。除能正常构建 PowerShell 外还需要满足以下前提已安装 VS Code 的 C# 扩展已安装 .NET Core 调试器首次调试时半自动完成powershell即pwsh可执行文件在 PATH 中——非 Windows 平台需先自举构建一份。一个容易踩的坑是 .NET CLI 工具必须在 PATH 中VS Code 才能调用。Start-PSBootstrap会把 .NET 工具安装到~/.dotnet非 Windows或$env:LocalAppData\Microsoft\dotnetWindows但不会把该目录加入PATH。你可以自行补充# Bash export PATH$PATH:$HOME/.dotnet# PowerShell $env:path $env:path ;$env:LocalAppData\Microsoft\dotnet另外扩展安装后必须先打开任意一个 C# 文件VS Code 才会真正安装 .NET Core 调试器若跳过这一步直接调试编辑器会提示你补做。仓库内置的.vscode调试配置仓库根目录提交了.vscode文件夹内含launch.json与tasks.json提供开箱即用的调试配置和构建任务.vscode/extensions.json 还推荐了ms-dotnettools.csharp、ms-vscode.PowerShell等配套扩展。构建任务见 .vscode/tasks.json共有三个任务作用Bootstrap执行Import-Module build.psm1; Start-PSBootstrap拉取/安装 .NET 工具链Clean BuildStart-PSBuild -Clean -Output workspace/debug先清理再构建BuildStart-PSBuild -Output workspace/debug是默认构建任务isDefault: trueBuild任务把产物输出到统一的debug目录保证调试器在任意平台都知道可执行文件在哪里。注意这些任务通过-NoProfile -Command调用pwsh执行构建脚本Windows 用pwsh.exeLinux 用/usr/bin/pwshmacOS 用/usr/local/bin/pwsh。如果你本地修改了这份配置请勿提交——默认配置的目标是“对任何人都直接可用”。启动/附加配置见 .vscode/launch.json当前仓库中实际包含四套{ name: .NET Core Launch, type: coreclr, request: launch, justMyCode: false, stopAtEntry: true, program: ${workspaceRoot}/debug/pwsh, preLaunchTask: Build, externalConsole: true, cwd: ${workspaceRoot} }要点解析justMyCode: false——允许单步进入 .NET 基础库和引擎源码内部调试 PowerShell 引擎时几乎必开stopAtEntry: true——进程一启动就停在Main入口需要手动点绿色箭头F5继续执行preLaunchTask: Build——启动前先跑上面的Build任务程序路径锁定为${workspaceRoot}/debug/pwsh。官方调试指南docs/debugging/README.md中写的是“输出到PowerShell/debug/powershell”而当前仓库launch.json实际指向debug/pwsh以当前配置文件为准。{ name: .NET Core Attach, type: coreclr, request: attach, justMyCode: false, processId: ${command:pickProcess} }.NET Core Attach配置则改为监听并附加到已运行的powershell进程当前实现通过pickProcess命令在进程列表中选择目标。若需要更精细的控制可以把processId直接写死为某个 PID文档明确提醒这类本地改动不要提交。此外launch.json还内置了PowerShell Launch Current File与带参数提示的变体用于在调试 C# 之外直接跑当前.ps1脚本。最后交互控制台依赖外部终端配置了externalConsole: true后启动配置会借助 Gnome Terminal 或 XTerm 拉起一个外部控制台在其中以交互方式运行 PowerShell若两者都未安装编辑器会提示你安装其一。用 Trace-Command 追踪引擎子系统Trace-Commandcmdlet 可以对 PowerShell 引擎的特定子系统开启追踪配合Get-TraceSource可以列出进程中所有已实例化的追踪器。官方指南列出的子系统包括CmdletProviderClasses、CommandDiscovery、CommandSearch、ConsoleHost、ConsoleHostRunspaceInit、ConsoleHostUserInterface、ConsoleLineOutput、DisplayDataQuery、ETS、FileSystemProvider、FormatFileLoading、FormatViewBinding、LocationGlobber、MemberResolution、Modules、MshSnapinLoadUnload、ParameterBinderBase、ParameterBinderController、ParameterBinding、PathResolution、PSDriveInfo、PSSnapInLoadUnload、RunspaceInit、SessionState、TypeConversion、TypeMatch。使用示例Trace-Command -Expression { Get-ChildItem . } -Name PathResolution -PSHost参数含义-Expression被追踪的脚本块即你要观察的目标操作-Name选择要启用的追踪器可多个对应上面列出的子系统名-PSHost指定追踪消息的输出接收器sink这里选控制台宿主消息会直接打到终端。也可换成TraceListener等其它接收器写入文件等目标。源码印证追踪器从何而来Get-TraceSource的实现在 GetTracerCommand.cs其ProcessRecord通过基类TraceCommandBase的GetMatchingTraceSource按名称支持通配符*筛选并输出PSTraceSource对象Trace-Command本身则在 TraceCommandBase.cs 与 TraceExpressionCommand.cs 中实现。从源码结构看每个追踪器都是引擎类中用PSTraceSource.GetTracer(name, description)静态创建的实例追踪器名称与文档列表一一对应例如类型转换LanguagePrimitives.cs 中PSTraceSource.GetTracer(TypeConversion, Traces the type conversion algorithm, false)模块加载ModuleIntrinsics.cs 中Modules, Module loading and analysis成员解析MshObject.cs 中MemberResolution用于追踪“从成员名到属性/方法”的解析过程会话状态SessionState.cs 中的SessionState追踪器。因此当你遇到“命令找不到”“参数绑定报错”“类型转换失败”这类问题可以先用Get-TraceSource确认对应追踪器存在再用Trace-Command对相关表达式开一次追踪即可看到引擎内部每一步的决策细节。LLDB 与 SOS 插件Linuxtools/debug.sh 脚本用于在 Linux 下把 PowerShell 放进 LLDB 运行并加载 .NET 自带的 SOS 调试插件。这提供了独立于 VS Code 之外的原生调试通道日常开发仍推荐 VS Code体验更好且支持单步执行。脚本的前置检查与启动逻辑tools/debug.shhash lldb-3.6 2/dev/null || { echo 2 No lldb-3.6, please run sudo apt-get install lldb-3.6; exit 1; } test -x debug/powershell || { echo 2 No debug/powershell, please run Start-PSBuild -Publish -Output debug; exit 1; } test -x debug/libsosplugin.so || { echo 2 No debug/libsosplugin.so, please run Start-PSBuild -Publish -Output debug; exit 1; }即需要系统已装lldb-3.6需要先执行Start-PSBuild -Publish -Output debug让debug/powershellpwsh二进制和debug/libsosplugin.so就位最终通过lldb-3.6 -o plugin load libsosplugin.so -- ./pwsh $启动脚本支持把额外参数透传给pwsh。脚本启动后会打印操作提示输入run或r启动 PowerShell按 Ctrl-C 中断后可执行 LLDB 命令exit退出。SOS 插件提供的最常用命令是clrstack查看当前托管线程调用栈clrthreads列出所有托管线程pe查看托管对象按地址。corehost 宿主追踪.NET CLI 生成的原生可执行文件自带宿主corehost追踪能力只需设置环境变量即可看到宿主解析配置、加载运行时、定位 DLL 的全过程COREHOST_TRACE1 ./powershell当你怀疑“进程起来之前”就失败如找不到运行时、runtimeconfig 解析异常时这是第一手取证手段。CoreCLR PAL 调试通道CLR 原生代码内置了调试通道可把分类的调试信息选择性输出到控制台由PAL_DBG_CHANNELS环境变量控制格式定义在 CoreCLR 的dbgmsg.h头文件中export PAL_DBG_CHANNELSall.all注意开启all.all会极其啰嗦实际使用必须收窄通道范围只开启关心的类别。调试 .NET Core 本身构建并部署调试版运行时一个重要的前提从 NuGet 下载、随 PowerShell 一起发布的 .NET Core 库是发布版Release其中不包含调试通道支持PAL_DBG_CHANNELS对它们无效。要让 CLR 原生调试通道工作必须自行构建并部署调试模式的 .NET Core。官方指南说明这些步骤不追求完整覆盖只作为 Linux 上的调试快捷手段。构建并部署 CoreCLR克隆 CoreCLR文档以release/1.0.0分支为例按 CoreCLR 的 Linux 构建文档完成构建等待./build.sh完成覆盖 PowerShell 目录中的库cp bin/Product/Linux.x64.Debug/*{so,dll} /path/to/powershell/构建并部署 CoreFX克隆 CoreFX同样以release/1.0.0分支为例按其 Unix 构建文档执行构建等待./build.sh skiptests完成覆盖 PowerShell 库注意必须按从最通用到最具体的顺序逐层覆盖且每一层都要允许覆盖前一层的同名文件dest/path/to/powershell/ find bin/AnyOS.AnyCPU.Debug/*/*.dll -exec cp -p {} $dest \; find bin/Unix.AnyCPU.Debug/*/*.dll -exec cp -p {} $dest \; find bin/Linux.AnyCPU.Debug/*/*.dll -exec cp -p {} $dest \; find bin/Linux.x64.Debug/ -name *.so -exec cp -p {} $dest \;文档特意解释了这段顺序与 glob 的讲究-exec cp保证后续阶段可以覆盖前面的产物glob 只允许深入一层目录因为更深层的子目录可能存在同名但“非预期实现”的库误拷会破坏运行时。需要说明的是这一段指导是文档按早期 .NET Core 1.0 时代编写的release/1.0.0分支、独立构建 CoreCLR/CoreFX。在当前仓库对应的 .NET 版本中运行时已整合为单一的 .NET Runtime 项目实际调试现代版本时应以当前 .vscode 配置的托管调试为主把本节当作原理性参考理解“Release 版运行时不含调试通道、需要 Debug 构建才能启用 PAL 输出”这一核心限制。小结调试目标工具/手段关键入口C# 引擎源码VS CodeOmniSharp .NET Core 调试器.vscode/launch.json、.vscode/tasks.json引擎子系统行为Trace-CommandGet-TraceSourcetrace 命令实现Linux 原生托管调试LLDB SOS 插件tools/debug.sh宿主启动阶段COREHOST_TRACE1环境变量CLR 原生通道PAL_DBG_CHANNELS需调试版运行时运行时本身构建并部署 Debug 版 .NET Core见上文 CoreCLR/CoreFX 步骤原始指南见 docs/debugging/README.md以上各节均与其内容对齐并结合当前仓库的实际配置与源码实现做了补全。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PowerShell 核心调试完全指南：VS Code、Trace-Command 引擎追踪、LLDB/SOS 与 CoreCLR 原生调试
PowerShell 核心调试完全指南VS Code、Trace-Command 引擎追踪、LLDB/SOS 与 CoreCLR 原生调试【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell本文为 PowerShell 仓库官方调试指南的深化版覆盖从 C# 源码级调试VS Code OmniSharp、运行时子系统追踪Trace-Command/Get-TraceSource到 Linux 下 LLDB SOS 插件、corehost 宿主追踪、CoreCLR PAL 调试通道以及为 .NET Core 构建调试版运行时的完整链路。读完之后你可以独立搭好跨平台的 PowerShell 开发调试环境并能针对引擎内部行为命令发现、参数绑定、类型转换、模块加载等做定点取证。用 VS Code 调试 C# 源码PowerShell 的 C# 引擎源码支持跨平台调试这在很大程度上依赖 VS Code 的 C# 扩展OmniSharp 提供语言服务与 .NET Core 调试器。除能正常构建 PowerShell 外还需要满足以下前提已安装 VS Code 的 C# 扩展已安装 .NET Core 调试器首次调试时半自动完成powershell即pwsh可执行文件在 PATH 中——非 Windows 平台需先自举构建一份。一个容易踩的坑是 .NET CLI 工具必须在 PATH 中VS Code 才能调用。Start-PSBootstrap会把 .NET 工具安装到~/.dotnet非 Windows或$env:LocalAppData\Microsoft\dotnetWindows但不会把该目录加入PATH。你可以自行补充# Bash export PATH$PATH:$HOME/.dotnet# PowerShell $env:path $env:path ;$env:LocalAppData\Microsoft\dotnet另外扩展安装后必须先打开任意一个 C# 文件VS Code 才会真正安装 .NET Core 调试器若跳过这一步直接调试编辑器会提示你补做。仓库内置的.vscode调试配置仓库根目录提交了.vscode文件夹内含launch.json与tasks.json提供开箱即用的调试配置和构建任务.vscode/extensions.json 还推荐了ms-dotnettools.csharp、ms-vscode.PowerShell等配套扩展。构建任务见 .vscode/tasks.json共有三个任务作用Bootstrap执行Import-Module build.psm1; Start-PSBootstrap拉取/安装 .NET 工具链Clean BuildStart-PSBuild -Clean -Output workspace/debug先清理再构建BuildStart-PSBuild -Output workspace/debug是默认构建任务isDefault: trueBuild任务把产物输出到统一的debug目录保证调试器在任意平台都知道可执行文件在哪里。注意这些任务通过-NoProfile -Command调用pwsh执行构建脚本Windows 用pwsh.exeLinux 用/usr/bin/pwshmacOS 用/usr/local/bin/pwsh。如果你本地修改了这份配置请勿提交——默认配置的目标是“对任何人都直接可用”。启动/附加配置见 .vscode/launch.json当前仓库中实际包含四套{ name: .NET Core Launch, type: coreclr, request: launch, justMyCode: false, stopAtEntry: true, program: ${workspaceRoot}/debug/pwsh, preLaunchTask: Build, externalConsole: true, cwd: ${workspaceRoot} }要点解析justMyCode: false——允许单步进入 .NET 基础库和引擎源码内部调试 PowerShell 引擎时几乎必开stopAtEntry: true——进程一启动就停在Main入口需要手动点绿色箭头F5继续执行preLaunchTask: Build——启动前先跑上面的Build任务程序路径锁定为${workspaceRoot}/debug/pwsh。官方调试指南docs/debugging/README.md中写的是“输出到PowerShell/debug/powershell”而当前仓库launch.json实际指向debug/pwsh以当前配置文件为准。{ name: .NET Core Attach, type: coreclr, request: attach, justMyCode: false, processId: ${command:pickProcess} }.NET Core Attach配置则改为监听并附加到已运行的powershell进程当前实现通过pickProcess命令在进程列表中选择目标。若需要更精细的控制可以把processId直接写死为某个 PID文档明确提醒这类本地改动不要提交。此外launch.json还内置了PowerShell Launch Current File与带参数提示的变体用于在调试 C# 之外直接跑当前.ps1脚本。最后交互控制台依赖外部终端配置了externalConsole: true后启动配置会借助 Gnome Terminal 或 XTerm 拉起一个外部控制台在其中以交互方式运行 PowerShell若两者都未安装编辑器会提示你安装其一。用 Trace-Command 追踪引擎子系统Trace-Commandcmdlet 可以对 PowerShell 引擎的特定子系统开启追踪配合Get-TraceSource可以列出进程中所有已实例化的追踪器。官方指南列出的子系统包括CmdletProviderClasses、CommandDiscovery、CommandSearch、ConsoleHost、ConsoleHostRunspaceInit、ConsoleHostUserInterface、ConsoleLineOutput、DisplayDataQuery、ETS、FileSystemProvider、FormatFileLoading、FormatViewBinding、LocationGlobber、MemberResolution、Modules、MshSnapinLoadUnload、ParameterBinderBase、ParameterBinderController、ParameterBinding、PathResolution、PSDriveInfo、PSSnapInLoadUnload、RunspaceInit、SessionState、TypeConversion、TypeMatch。使用示例Trace-Command -Expression { Get-ChildItem . } -Name PathResolution -PSHost参数含义-Expression被追踪的脚本块即你要观察的目标操作-Name选择要启用的追踪器可多个对应上面列出的子系统名-PSHost指定追踪消息的输出接收器sink这里选控制台宿主消息会直接打到终端。也可换成TraceListener等其它接收器写入文件等目标。源码印证追踪器从何而来Get-TraceSource的实现在 GetTracerCommand.cs其ProcessRecord通过基类TraceCommandBase的GetMatchingTraceSource按名称支持通配符*筛选并输出PSTraceSource对象Trace-Command本身则在 TraceCommandBase.cs 与 TraceExpressionCommand.cs 中实现。从源码结构看每个追踪器都是引擎类中用PSTraceSource.GetTracer(name, description)静态创建的实例追踪器名称与文档列表一一对应例如类型转换LanguagePrimitives.cs 中PSTraceSource.GetTracer(TypeConversion, Traces the type conversion algorithm, false)模块加载ModuleIntrinsics.cs 中Modules, Module loading and analysis成员解析MshObject.cs 中MemberResolution用于追踪“从成员名到属性/方法”的解析过程会话状态SessionState.cs 中的SessionState追踪器。因此当你遇到“命令找不到”“参数绑定报错”“类型转换失败”这类问题可以先用Get-TraceSource确认对应追踪器存在再用Trace-Command对相关表达式开一次追踪即可看到引擎内部每一步的决策细节。LLDB 与 SOS 插件Linuxtools/debug.sh 脚本用于在 Linux 下把 PowerShell 放进 LLDB 运行并加载 .NET 自带的 SOS 调试插件。这提供了独立于 VS Code 之外的原生调试通道日常开发仍推荐 VS Code体验更好且支持单步执行。脚本的前置检查与启动逻辑tools/debug.shhash lldb-3.6 2/dev/null || { echo 2 No lldb-3.6, please run sudo apt-get install lldb-3.6; exit 1; } test -x debug/powershell || { echo 2 No debug/powershell, please run Start-PSBuild -Publish -Output debug; exit 1; } test -x debug/libsosplugin.so || { echo 2 No debug/libsosplugin.so, please run Start-PSBuild -Publish -Output debug; exit 1; }即需要系统已装lldb-3.6需要先执行Start-PSBuild -Publish -Output debug让debug/powershellpwsh二进制和debug/libsosplugin.so就位最终通过lldb-3.6 -o plugin load libsosplugin.so -- ./pwsh $启动脚本支持把额外参数透传给pwsh。脚本启动后会打印操作提示输入run或r启动 PowerShell按 Ctrl-C 中断后可执行 LLDB 命令exit退出。SOS 插件提供的最常用命令是clrstack查看当前托管线程调用栈clrthreads列出所有托管线程pe查看托管对象按地址。corehost 宿主追踪.NET CLI 生成的原生可执行文件自带宿主corehost追踪能力只需设置环境变量即可看到宿主解析配置、加载运行时、定位 DLL 的全过程COREHOST_TRACE1 ./powershell当你怀疑“进程起来之前”就失败如找不到运行时、runtimeconfig 解析异常时这是第一手取证手段。CoreCLR PAL 调试通道CLR 原生代码内置了调试通道可把分类的调试信息选择性输出到控制台由PAL_DBG_CHANNELS环境变量控制格式定义在 CoreCLR 的dbgmsg.h头文件中export PAL_DBG_CHANNELSall.all注意开启all.all会极其啰嗦实际使用必须收窄通道范围只开启关心的类别。调试 .NET Core 本身构建并部署调试版运行时一个重要的前提从 NuGet 下载、随 PowerShell 一起发布的 .NET Core 库是发布版Release其中不包含调试通道支持PAL_DBG_CHANNELS对它们无效。要让 CLR 原生调试通道工作必须自行构建并部署调试模式的 .NET Core。官方指南说明这些步骤不追求完整覆盖只作为 Linux 上的调试快捷手段。构建并部署 CoreCLR克隆 CoreCLR文档以release/1.0.0分支为例按 CoreCLR 的 Linux 构建文档完成构建等待./build.sh完成覆盖 PowerShell 目录中的库cp bin/Product/Linux.x64.Debug/*{so,dll} /path/to/powershell/构建并部署 CoreFX克隆 CoreFX同样以release/1.0.0分支为例按其 Unix 构建文档执行构建等待./build.sh skiptests完成覆盖 PowerShell 库注意必须按从最通用到最具体的顺序逐层覆盖且每一层都要允许覆盖前一层的同名文件dest/path/to/powershell/ find bin/AnyOS.AnyCPU.Debug/*/*.dll -exec cp -p {} $dest \; find bin/Unix.AnyCPU.Debug/*/*.dll -exec cp -p {} $dest \; find bin/Linux.AnyCPU.Debug/*/*.dll -exec cp -p {} $dest \; find bin/Linux.x64.Debug/ -name *.so -exec cp -p {} $dest \;文档特意解释了这段顺序与 glob 的讲究-exec cp保证后续阶段可以覆盖前面的产物glob 只允许深入一层目录因为更深层的子目录可能存在同名但“非预期实现”的库误拷会破坏运行时。需要说明的是这一段指导是文档按早期 .NET Core 1.0 时代编写的release/1.0.0分支、独立构建 CoreCLR/CoreFX。在当前仓库对应的 .NET 版本中运行时已整合为单一的 .NET Runtime 项目实际调试现代版本时应以当前 .vscode 配置的托管调试为主把本节当作原理性参考理解“Release 版运行时不含调试通道、需要 Debug 构建才能启用 PAL 输出”这一核心限制。小结调试目标工具/手段关键入口C# 引擎源码VS CodeOmniSharp .NET Core 调试器.vscode/launch.json、.vscode/tasks.json引擎子系统行为Trace-CommandGet-TraceSourcetrace 命令实现Linux 原生托管调试LLDB SOS 插件tools/debug.sh宿主启动阶段COREHOST_TRACE1环境变量CLR 原生通道PAL_DBG_CHANNELS需调试版运行时运行时本身构建并部署 Debug 版 .NET Core见上文 CoreCLR/CoreFX 步骤原始指南见 docs/debugging/README.md以上各节均与其内容对齐并结合当前仓库的实际配置与源码实现做了补全。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考