windbg调试CPU占用过高

runaway num：让调试器显示每个线程消耗的用户模式时间(user time)默认不加num就是0x1，还有更多的num组合，这边就不做扩展了，默认就够用了。该扩展命令可以用来快速找出哪些线程循环失去控制消耗了太多CPU时间。输出中以调试器的内部线程号和16进制线程ID来标识每个线程。还会显示调试器ID。如上图，我们通过~跳到想要分析的线程，然后kbn可以查看具体线程的堆栈信息。当然，想要更加详细的堆栈信息，需要添加pdb，这边就不过多赘述了，网上很多教程。

分析高CPU的关键是找到哪个线程是持续运行，占用CPU时间。 可以隔上两分钟连续抓两个dump文件，使用 !runaway 查看线程运行的时间 通过对比两个dump文件的线程时间，看看哪个线程运行的时间持续增加。 最后通过切换到问题线程上，查看堆栈信息，如果两个dump的问题线程堆栈一致，基本上就可以推断了出问题的代码。 转载于:https://www.cnblogs.com/5061409...

WinDBG（Windows Debugger）是一个功能强大的调试工具，最初是为Windows NT系统设计的，现在可用于Windows全系列操作系统。它以命令行界面为主，可对本地或远程的Windows操作系统进行调试。WinDBG能够调试用户模式和内核模式的应用程序，是解决复杂软件问题不可或缺的工具。工作空间在WinDBG中是一个用于组织项目文件、符号文件和其他调试相关文件的逻辑容器。创建一个工作空间是为了确保调试环境的有序性，并且便于针对特定调试任务快速切换和管理相关配置。

在一个任务中使用多线程编程，程序运行一段时间后就占满了CPU，严重拖慢系统运行速度。这里所说的高CPU，意思就是一个线程占用了一个CPU的大部分运行时间，如果是单核的CPU，表现为CPU占用近100%；相应的双核的话一个线程会占到50%的CPU。 我的电脑是双核四线程的CPU，所以当一个线程死循环的时候会占用掉25%的CPU时间。具体表现为：运行程序的最开始表现正常，随后会看到CPU占用上升

下载WinDbg , http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx 我是 win10, 下载了这个： http://download.microsoft.com/download/6/3/B/63BADCE0-F2E6-44BD-B2F9-60F5F073038E/standalonesdk/SDKSETUP.EXE 安装WinDbg， 这个就不赘述了。 需要注意的是有 WinDbg (X64) 和 WinDbg (X.

1、首先下载Windbg 2、打开Windbg 设置 File-〉Symbol Search Path 地址如下 C:\ Symbols; SRV*C:\MyLocalSymbols*http://msdl.microsoft.com/download/symbols";SRV*c:\mysymbol* http://msdl.microsoft.com/down...

本文详细介绍如何使用Process Explorer、System Informer（Process Hacker）和Windbg工具排查项目中遇到的高CPU占用问题。

使用Process Explorer/Process Hacker和Windbg高效排查软件高CPU占用问题

通过在Windbg中查看变量的值去快速定位软件高CPU占用问题。

.loadby sos clr //查看所有线程占用的cpu时间 !runaway //切换到cpu占用高的线程 ~13s //打印堆栈 !clrstack

windbg attach上去 通过!runaway命令来列出各线程所耗费的时间 找到时间较高的，通过 Processes and Threads 窗口双击线程切换到目标线程上下文 F10跑一段看看调用堆栈 即可。

使用命令 kv 查看当前线程的调用堆栈，可以看到线程中使用到了一个封装的网络通讯库，一直在RecvFrom，猜测可能就是此线程在死循环在等待接收数据，中间没有等待时间，根据这个线索，然后继续定位代码模块。函数内部是在不断的调用循环接收客户端数据，查看调用了通讯库的函数声明，最后一个参数就是等待的时间（单位ms），正常如果设置了阻塞等待的时间应该就不会产生如此高的CPU，那么肯定就是该通讯库的该参数无效，问题大概已经能定位，修改代码，在调用RecvFrom的函数后面，如果没有接收到网络数据就等待10ms。

一、概述在Window服务器部署程序后，可能因为代码的不合理或者其他各种各样的问题，会导致CPU暴增，甚至达到100%等情况，严重危及到服务器的稳定以及系统稳定，但是一般来说对于已发布的程序，没法即时看到出问题的代码，而微软提供了一个很好的工具“WinDbg”，使得我们能够回溯问题。下面讲一下操作步骤。二、操作步骤1.下载软件：2.安装只需要选择：Debugging Tools for Win...

一、概述在Window服务器部署程序后，可能因为代码的不合理或者其他各种各样的问题，会导致CPU暴增，甚至达到100%等情况，严重危及到服务器的稳定以及系统稳定，但是一般来说对于已发布的...

https://blog.csdn.net/yenange/article/details/62886988 https://blog.csdn.net/zhushentian/article/details/79589344 转载于:https://www.cnblogs.com/132818Creator/p/10036274.html

症状： 　　下班前，收到报警邮件。一个应用的两台服务器CPU 过高。打开监控一看CPU都100了。没找到原因之前，先抓好DUMP 然后重启应用程序池。 　　!threadpool 可以看到CPU 利用率 　　 　　!runaway 查看运行的线程和运行时间 　　   http://m.sh85yygk.com/jibingzhengzhuang/1446427