如何定位树莓派上运行的dotnet应用卡死的代码位置？

所有操作都通过命令行完成，不需要安装GUI IDE，适配树莓派设备环境。

• 优先使用轻量实时栈打印方案
  安装.NET官方命令行栈查看工具：
  dotnet tool install -g dotnet-stack
  安装完成后将~/.dotnet/tools加入当前用户的PATH环境变量。
  等应用再次出现卡死、无法响应SIGINT的情况时，先执行ps aux | grep 你的应用入口dll文件名获取应用进程ID，随后直接执行：
  dotnet-stack report -p 拿到的进程ID
  命令会直接输出当前进程内所有托管线程的完整调用栈，对运行中进程的性能影响极小，不需要生成大体积转储文件，适合树莓派这类存储、性能有限的设备。输出结果中过滤掉线程池空闲等待的线程，剩下的处于阻塞、等待状态的工作线程对应的栈顶代码，就是卡死位置的直接线索。

注意：发布应用到树莓派时，不要删除编译生成的pdb后缀符号文件，和应用dll放在同一目录即可，否则栈信息只能显示方法名，无法定位到具体代码行。

• 若需要更详细的运行时状态分析，用转储文件离线排查
  安装转储收集工具：
  dotnet tool install -g dotnet-dump
dotnet tool install -g dotnet-sos
  应用卡死时执行以下命令生成转储文件：
  dotnet-dump collect -p 应用进程ID
  生成完成后即可用kill -9终止进程，转储文件不会受进程终止影响。
  分析转储时执行dotnet-dump analyze 转储文件路径进入交互界面，依次执行：
  1. setsospath ~/.dotnet/sos 加载SOS调试扩展
  2. clrthreads 列出所有托管线程，标记出非空闲状态的工作线程
  3. 切换到对应可疑线程后执行clrstack，即可打印该线程的完整托管调用栈，配合pdb符号文件可以直接显示卡滞对应的代码行号。
• 偶发卡死无人值守场景配置
  如果卡死复现概率低、没有条件人工蹲守，可以写简单的定时shell脚本，每隔固定周期检测应用状态：比如检查应用日志文件的最后修改时间，若超过设定阈值没有新日志写入，就自动触发dotnet-stack或者dotnet-dump命令收集现场信息，收集完成后自动重启应用即可。
• 拿到调用栈后的常见卡滞原因对照
  • 若栈显示卡在Monitor.Enter、lock相关调用，优先排查死锁：检查两个及以上工作线程是否存在互相持有对方需要的锁、且未释放的逻辑
  • 若栈显示卡在[Native Method]标记的非托管方法，优先排查树莓派硬件相关的调用：比如GPIO、串口、SPI等硬件IO操作是否没设置超时，是否存在硬件返回异常导致原生调用无限阻塞的情况
  • 若多个线程栈显示卡在Task.Result、Task.Wait()这类同步阻塞异步代码的调用，优先排查线程池耗尽问题：检查是否存在异步方法同步阻塞导致线程池线程被全部占满、后续工作项无线程可用的情况

内容的提问来源于stack exchange，提问作者mnj