三板斧如下: 使用windbg打开dump文件,设置好对应进程的 pdb 文件(这个很关键.为了避免releas优化导致符号文件错乱,我发布的所有                      release 版都是关闭代码优化的). 在windbg的"edit"->"open/close log file"  设置log 路径 “d:\a.log” 输入命令 “~*er?$t1=((ntdll!_NT_TIB*)@$teb)->StackLimit;r?$

1. 背景 在开发过程中,我们可能遇到应用程序线程占用过大的问题,可以通过windbg命令去定位哪些类型,哪些内存一直占用堆资源,从而查出问题,解决问题. 2. 准备工作 工具: 抓取DUMP文件的工具,任务管理器(最简单),DebugDiag,ProcessExplorer等(网上很多) 分析工具windbg PS:使用任务管理器的时候需要强调一下如何抓包:根据你的进程是多少位的,然后使用对应位数的任务管理器去抓, 不然抓到的DUMP文件是无效的. 如果在下面分析过程中出现"SOS does

项目介绍:asp.net mvc + angular +iis(windows)+windows server 系统莫名崩溃 最近有个系统默认奇妙崩溃50x,服务整体变成无响应,当运维告知我只有重启应用程序池项目才能正常. 我问他如何重现,得到的回复是我这里无法重现,但客户使用一段时间后,就会崩溃. 于是我崩溃了.因为查日志没有任何错误,查windows系统日志上也只有一个错误 System.AccessViolationException 尝试读取或写入受保护的内存.这通常指示其他内存已损坏,

1.简单配置在windbg程序目录下有个gflags.exe,运行后设置: 运行CMD.EXE,输入"D:\Debugging Tools for Windows (x86)\gflags.exe" /i test.exe +ust,如果设置成功则显示: 如果设置失败,说明注册表被禁用了,可以尝试解除所有对注册表的禁用.这个注册表位置为:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File

操作系统对死锁的描述如下: 所谓死锁:是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去. 那么为什么会产生死锁呢? 1.因为系统资源不足. 2.进程运行推进的顺序不合适. 3.资源分配不当. 而产生死锁的条件有四个: 1.互斥条件:所谓互斥就是进程在某一时间内独占资源. 2.请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放. 3.不剥夺条件:进程已获得资源,在末使用完之前,不能强行剥夺. 4.循环等待条件:若干进程之

测试环境 服务器:II服务器 网站:门户网站 条件 并发: 2000 LoadRunner思考时间:1s 表现 CPU:100% 对应w3wp进程 WebService–>Current connections:2300 DB:CPU 10% 无压力 压力降低后表现 随着并发量下降,CPU 和 WebService–>Current connections 随着下降,随后恢复正常: 分析 1)IIS的CPU达到100%,DB的CPU只有10%,瓶颈可能在WEB程序端: 2)压力降低后,CPU

作为一个程序员,解BUG是我们工作中常做的工作,甚至可以说解决问题能力是一个人工作能力的重要体现.因为这体现了一个程序员的技术水平.技术深度.经验等等. 那么在我们解决BUG的过程中,定位问题是非常重要的.有句话叫"发现问题是解决问题的一半. 本文讲述就快速定位异常(专指.NET程序异常)的方法.包括在本机定位异常,在客户环境定位.net程序异常,在客户环境定位SilverLight异常. 一:定位本机异常 在我们本机定位异常很容易.假设我们都是使用的的VisualStudio,那么只需要在调试

作为一个程序员,解BUG是我们工作中常做的工作,甚至可以说解决问题能力是一个人工作能力的重要体现.因为这体现了一个程序员的技术水平.技术深度.经验等等. 那么在我们解决BUG的过程中,定位问题是非常重要的.有句话叫"发现问题是解决问题的一半. 本文讲述就快速定位异常(专指.NET程序异常)的方法.包括在本机定位异常,在客户环境定位.net程序异常,在客户环境定位SilverLight异常. 一:定位本机异常 在我们本机定位异常很容易.假设我们都是使用的的VisualStudio,那么只需要在调试

分享下我的debug的经验 1. 优先解决那些可重现的,可重现的bug特别好找,反复调试测试就好了,先把好解决的干掉,这样最节约时间. 2. 对于某些bug没有头绪或者现象古怪不知道从哪里下手,找有经验的同事问一下思路,因为在那种开发多年的大型系统里,经常会反复出现同样原因的bug,原因都类似,改了一处,过一阵子另外一处又冒出来,而且无法根治.比如:我那个系统里有个特别危险的API,接口参数比较难用,一旦有人用错了某些情况下就会出诡异的现象,解决很简单,找到调用这个API的地方把调用方式写对就好

分享下我的debug的经验 1. 优先解决那些可重现的,可重现的bug特别好找,反复调试测试就好了,先把好解决的干掉,这样最节约时间. 2. 对于某些bug没有头绪或者现象古怪不知道从哪里下手,找有经验的同事问一下思路,因为在那种开发多年的大型系统里,经常会反复出现同样原因的bug,原因都类似,改了一处,过一阵子另外一处又冒出来,而且无法根治.比如:我那个系统里有个特别危险的API,接口参数比较难用,一旦有人用错了某些情况下就会出诡异的现象,解决很简单,找到调用这个API的地方把调用方式写对就好

作者:姚冬  遇到bng的分享 我曾经做了两年大型软件的维护工作,那个项目有10多年了,大约3000万行以上的代码,参与过开发的有数千人,代码checkout出来有大约5个GB,而且bug特别多,open的有上千,即使最高优先级的showstopper也有上百. 分享下我的debug的经验 1. 优先解决那些可重现的,可重现的bug特别好找,反复调试测试就好了,先把好解决的干掉,这样最节约时间. 2. 对于某些bug没有头绪或者现象古怪不知道从哪里下手,找有经验的同事问一下思路,因为在那种开发多

我曾经做了两年大型软件的维护工作,那个项目有10多年了,大约3000万行以上的代码,参与过开发的有数千人,代码checkout出来有大约5个GB,而且bug特别多,open的有上千,即使最高优先级的showstopper也有上百.分享下我的debug的经验1. 优先解决那些可重现的,可重现的bug特别好找,反复调试测试就好了,先把好解决的干掉,这样最节约时间.2. 对于某些bug没有头绪或者现象古怪不知道从哪里下手,找有经验的同事问一下思路,因为在那种开发多年的大型系统里,经常会反复出现同样原因

作为公司的公共产品,经常有这样的需求:就是新建一个本地服务,产品线作为客户端通过 tcp 接入本地服务,来获取想要的业务能力. 与印象中动辄处理成千上万连接的 tcp 网络服务不同,这个本地服务是跑在客户机器上的,Win32 上作为开机自启动的 windows 服务运行: Linux 上作为 daemon 在后台运行.总的说来就是用于接收几个产品进程的连接,因此轻量化是其最重要的要求,在这个基础上要能兼顾跨平台就可以了. 其实主要就是 windows,再兼顾一点儿 linux. 考察了几个现有的

一:背景 1. 讲故事 这篇文章起源于 搬砖队大佬 的精彩文章 WinDBg定位asp.net mvc项目异常崩溃源码位置 ,写的非常好,不过美中不足的是通览全文之后,总觉得有那么一点不过瘾,就是没有把当时抛异常前的参数给找出来...这一篇我就试着弥补这个遗憾. 为了能够让文章行云流水,我就按照自己的侦察思路吧,首先看一下现状:iis上的应用程序崩溃, catch 不到错误,windows日志中只记录了一个 AccessViolationException 异常,如何分析? 说实话我也是第一次在

0x01 前言 CVE-2010-3333 漏洞是一个栈溢出漏洞,该漏洞是由于 Microsoft文档在处理 RTF 数据的对数据解析处理错误,在进行内存操作时没有对操作的数据进行长度限制,导致存在内存漏洞,根据漏洞可以很容易构造出恶意的 RTF 文档,危害较大 环境 windows XP sp3(未启用 ASLR 和 DEP) 漏洞软件 Microsoft Office 2003(提取码:woi9) 分析工具 Windbg(Windbg32,Windbg64) metasploit 构造的样本

前言 作为公司的公共产品,经常有这样的需求:就是新建一个本地服务,产品线作为客户端通过 tcp 接入本地服务,来获取想要的业务能力.与印象中动辄处理成千上万连接的 tcp 网络服务不同,这个本地服务是跑在客户机器上的,Win32 上作为开机自启动的 windows 服务运行:Linux 上作为 daemon 在后台运行.总的说来就是用于接收几个产品进程的连接,因此轻量化是其最重要的要求,在这个基础上要能兼顾跨平台就可以了.其实主要就是 windows,再兼顾一点儿 linux. 考察了几个现有的

本文记录我将应用迁移到 dotnet 6 之后,在 Win7 系统上,因为使用 HttpWebRequest 访问一个本地服务,此本地服务开启 https 且证书链在此 Win7 系统上错误,导致应用内存泄露问题.本文记录此问题的原因以及调查过程 核心原因 核心原因是在 CRYPT32.dll 上的 CertGetCertificateChain 方法存在内存泄露,更底层的原因未知 在 .NET 6 里,更新了 https 访问方法逻辑,详细请看 Announcing .NET 6 - The

在WinDBG中通过搜索内存中保存的CONTEXT结构来定位发生的异常信息,再通过WinDBG命令.cxr显示对应的调用堆栈信息.   .foreach ( place { s-[1]d 0 L?FFFFFFFF 1003f } ) { .echo STACK_TRACE; dd ${place} L1; .cxr ${place}; kc }  

场景描述: Sharepoint代码的某方法LoadLines()中使用了SPSecurity.RunWithElevatedPrivileges(delegate() 此方法两次调用了Common.GetLookupValue,并且问题可能出在这里. 解决方案: 由于开发环境没有VS2008,所以我们使用WinDbg进行调试.针对这种情况有两种方式: 1 Load SOS(参考文章) 2 通过快速捕捉异常的方式来快速定位错误(!u eip) 操作步骤: 1 打开WinDbg,附加对应的w3wp

windbg + .dmp + .pdb + 源代码,可以看到是哪个代码崩溃的 设置符号文件所在路径 File->Symbol File Path... 在输入框中填入.pdb文件所在的文件夹路径 设置源代码路径 File->Source File Path... 在输入框中填入源代码所在的文件夹路径 然后,打开.dmp文件,随后在列出一堆信息的后面,点击!Analysis-V超链接, 分析出具体出bug的代码未知