前几天有个朋友发个了在windows server 2008跑的IIS 跑的程序w3wp程序dmp,要我帮忙分析为何线程都挂起不运行 经过查阅资料用windbg可以调试可以输出线程的调用堆栈,但是准备调试之前费了不少功夫和时间 主要碰到是SOS.DLL和DMP 文件运行时候的CLR.DLL不匹配问题,那就需要从w3wp运行的机器上拷贝到对应.net版本下面的sos.dll,clr.dll,mscordacwks.dll文件 然后给windbg 加载,主要是通过.load 命令,卸载扩展DLL命令

上一篇博文给大家分享了使用Windbg分析内存泄露问题: Windbg程序调试系列2-内存泄露问题 本篇我们继续跟大家分享,如何分析解决线程阻塞问题. 从根本上讲,线程阻塞属于程序Hang的一种,其表现主要有: 1. 随着请求的增加,线程数一直增加,可能会把线程池打爆 2. 低CPU使用率(被阻塞后的CPU使用率降低) 3. 请求没有返回,客户端一直在等待,直至Timeout. 那么,从线程状态上看,什么是阻塞? 一个线程经历的5个状态,创建,就绪,运行,阻塞,终止.各个状态的转换条件如下图:

最近发布在windows  server2012  IIS8.0上的一个WebAPI项目,才几十个人在线,CPU就会出现过百情况,并且CPU一旦过百应用程序池就自动暂停掉,看到这个问题我感觉应该是程序哪个地方出了问题, 8盒16G 应该配置还是可以的.打算使用windbg找到这个问题. 为了快速定位问题我就直接在生产环境安装了windbg,为了采集dump文件,我选择Procdump.Procdump无需安装,下载下来直接放到一个目录下即可.以下是解决问题的过程+截图: 步骤一: 安装windb

简单整理一个测试Demo,抓取dump并验证,步骤如下: Symbol File Path:SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols Procdump每20秒抓取一次,连续抓三个:procdump -ma -s 20 -n 3 TestCPU.exe Ctrl + D 打开刚才收集的dump文件: 加载sos,命令:.loadby sos clr 检查所有线程的堆栈:~* e!clrstack 查看线程阻塞:!syncbl

https://www.cnblogs.com/startpoint/p/4194052.html https://www.cnblogs.com/lyl6796910/p/7613664.html https://www.cnblogs.com/dubing/p/3878591.html https://blogs.msdn.microsoft.com/alejacma/2009/08/13/managed-debugging-with-windbg-managed-heap-part-1/

第一章 准备 1.1.    环境配置 _NT_DEBUGGER_EXTENSION_PATH=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 _NT_SYMBOL_PATH=SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols Path add: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 C:\Program Files\Debugging

windbg简介 Windbg是在windows平台下,强大的用户态和内核态调试工具.相比较于Visual Studio,它是一个轻量级的调试工具,所谓轻量级指的是它的安装文件大小较小,但是其调试功能,却比VS更为强大.它的另外一个用途是可以用来分析dump数据.哈哈,这是我们最需要的,可以用来分析并发测试场景或生产环境的性能及稳定性问题.它能够通过dump文件轻松的定位到问题根源,学会使用它,将有效提升我们的问题解决能力和效率. windbg版本和符合表 不同版本的程序需要对应版本的抓取工具及

一.背景 先说下windbg使用场景.各位coder在工作中或多或少都会遇到下面四种情况 1.本地代码好好的,放服务器上运行一段时间后,IIS服务突然占用 w3wp.exe CPU突然100% ,不得不回收应用程序池,如果哪次回收晚了,被客户发现,后果很痛苦~ 2.你的w3wp.exe 内存高居不下 并且逐步上升 3.cpu很低,内存也很低,但你的网页打开却越来越慢,而你该做的优化都做过了,却没有任何效果.. 4.你的程序本地运行好好的,但是到服务器上了,在某个时候会突然报错,再次刷新却又好了.

[问题描述]:       前段时间有一项目反馈,常用的审批功能有时的响应较慢,多个管理员功能不定期的出现客户端无响应的状况,并且管理员功能一旦出现卡死,也会影响到普通的业务用户致使很多用户无法操作.该系统为混合场景,管理员功能使用的CS客户端,业务用户使用的是WEB. [环境信息]:       应用服务器:Windows Server 2008 R2 IIS7  .NET 4.0       数据库服务器:AIX Oracle 10.2.0.4 [处理过程]:       经过跟踪发现两个情

此前遇到一个项目反馈系统宕机问题,摘要描述如下: 系统不定期出现卡死现象,在多个模块不同功能上都出现过,未发现与特定功能相关的明显规律: 当系统出现卡死现象时,新的用户无法登陆系统: 跟踪应用服务器,未发现资源不足的情况(CPU.内存使用正常) 数据库服务器资源占用也正常(CPU不高,也未发现死锁.SQL阻塞等情况) 在问题再次发生时,使用ProcDump联系抓取多个dump文件:procdump -ma -s 20 -n 3 w3wp.exe 使用windbg命令(!tp)查看线程池发现,10

Windbg程序调试是.Net高级开发需要掌握的必备技能,分析内存泄露.分析高CPU.分析线程阻塞.分析内存对象.分析线程堆栈.Live Dedugging.这个领域可以说一个技能+场景化应用的结合,如果单学Windbg命令,不理解实际Troubleshooting中的作用,是没有意义的.所以,准备搞个系列文章,3~5篇,分享给大家: 工欲善其事必先利其器,我们先从常用的命令和示例说起. 1. 先准备一个Dump文件,建议使用64位应用程序.例如:64位IIS应用的w3wp进程,64位exe进程

.NET  开发注意 线程安全性问题.弄不好可能会导致CPU满载 特别主要 Dictionary作为静态变量使用的情况. 解决方法: Dictionary 换成  ConcurrentDictionary 例如下图: 下面是参考网上的相关资料: 一.背景 先说下windbg使用场景.各位coder在工作中或多或少都会遇到下面四种情况 1.本地代码好好的,放服务器上运行一段时间后,IIS服务突然占用 w3wp.exe CPU突然100% ,不得不回收应用程序池,如果哪次回收晚了,被客户发现,后果很

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方式运行w3wp进程.这个可以通过查看IIS Application Pool 的高级选项进行设置: 好了,接下打开Windbg看看这个w3wp进程占用了376M内存,启动的54个线程. 1. 加载 WinDbg SOS 扩展命令 .load C:\Windows\Microsoft.NET\Fram

返回目录 最近怪事又开始发生了,IIS的应用程序池无做挂掉,都指向同一个矛头,async,threadPool,Task,还有一个System.NullReferenceException,所以这些都让我们感觉,我们的异步程序出现了问题,事实也是如此,我们的异步调用引用了对“上下文”的非空引用,最后导致w3wp进程死掉!通过其它前辈的分享,找到了问题产生的原因,大叔也总结一下1 async方法需要使用await等待它的结果,这样可以保证你的SynchronizationContext上下文不为空

在此之前项目有发生过两次类似的状况,都得以解决,但最近又会发现偶尔CPU会跑满,虽然之前使用过WinDbg解决过两次问题但人的记忆是不可靠的,今天处理同样问题的时候还是遇到了一些障碍,这一次希望可以记录的更全面些. 上两次的博文链接:记一次w3wp占用CPU过高的解决过程(Dictionary和线程安全).EntityFramework中的线程安全,又是Dictionary. 首先请大家不要喷我,因为这一次还是关于Dictionary的一些低级错误,我自己看到都无语了... 抓取Dump 使用任

本文为 Dennis Gao 原创技术文章,发表于博客园博客,未经作者本人允许禁止任何形式的转载. 系列博文 <WinDbg 命令三部曲:(一)WinDbg 命令手册> <WinDbg 命令三部曲:(二)WinDbg SOS 扩展命令手册> <WinDbg 命令三部曲:(三)WinDbg SOSEX 扩展命令手册> 导航目录 内置帮助命令 调试会话命令 一般信息命令 符号加载命令 模块加载命令 异常分析命令 进程信息命令 线程信息命令 堆栈信息命令 扩展帮助命令 日志扩

最近花了好几周解决一个WPF高内存的问题,问题的表象是内存不断增加.未被回收,根源是GC的FinalizeThread被阻塞,导致整个GC挂掉.从以下几步来分析这个问题: 1.用ANTS Memory Profiler去掉强引用 既然是高内存,肯定要先从内存着手.这里必须要赞一下ANTS的这个工具,图形化做的非常好,一目了然,个人觉得比SciTech的.net memory profiler好用.找个基准点take一个SnapShot,打开关闭窗口后再take一个snapshot,比较2个快照里

IIS的工作进程(w3wp.exe)只提供了有限的工作线程(Work Thread)来处理请求.如果这些线程都因为要等待长时间运行的任务而阻塞,则运行时会将新来的请求排队,而不是立即执行,Web服务器的吞吐量也将骤降.这时,也许有一个长长的请求队列等待处理,而此时服务器的CUP利用率确非常低.减少工作线程的阻塞的时间是构建可扩展性网站的重中之重.可以利用以下技术来处理: 异步页面 异步HttpModule 异步I/O 异步数据库请求 后台工作线程 Service Broker

项目上线以来一直存在一个比较揪心的问题,和一个没有信心处理的BUG,那就是在应用程序启动时有可能会导致cpu跑满99%或持续在一个值如50%左右,这样一来对服务器的压力是非常大的,经常出现服务器无法远程的状态,唯有通过PowerShell杀掉对应的w3wp进程才可以解决这个问题. 为什么没有信心处理这个问题 原因非常简单,这个问题是间歇性的,不容易重现的,只会在项目启动时有一定的可能性会发生CPU跑满的问题. 所有可以重现的BUG的处理都不会太难,而类似这种无法重现的BUG是最让人头疼的,因为它

原文地址: http://www.cnblogs.com/Lawson/archive/2011/01/23/1942692.html 很早看到windbg+sos方面的知识,一直没仔细学习,也许因为自己做的系统还不够复杂,也没线上真实环境查看的权限,一直没学习这方面的知识,最近几天仔细找了这方面的资料,自己也写了个可能造成高CPU高内存的测试web页面,发现确实不错,即使一个生手,也可以用工具连蒙带骗的猜出哪里出了问题,当然对一些命令和内部标示更熟悉了后,可以更好的找出问题所在,非常值得学习.