一：背景 1.讲故事 最近遇到了好几起和 COM 相关的Dump,由于对 COM 整体运作不是很了解，所以分析此类dump还是比较头疼的，比如下面这个经典的 COM 调用栈。 0:044> ~~[138c]s win32u!NtUserMessageCall+0x14: 00007ffc`5c891
一：背景 1.讲故事 前段时间有位朋友加微信，说他的程序直接 CPU=100%，每次只能手工介入重启，让我帮忙看下到底怎么回事，哈哈，这种CPU打满的事故，程序员压力会非常大, 我让朋友在 CPU 高的时候抓 2 个 dump 下来，然后发给我分析。 二：WinDbg 分析 1. CPU 真的被打满
一：背景 1.讲故事 前段时间有位朋友在微信上找到我，说他对一个商业的 C# 程序用 WinDbg 附加不上去，每次附加之后那个 C# 程序就自动退出了，问一下到底是怎么回事？是不是哪里搞错了，有经验的朋友应该知道，其实这是 商业程序 的反调试机制捣鬼的，为了保护程序隐私，一般都不希望他人对自己做逆
一：背景 1.讲故事 这篇文章起源于昨天的一位朋友发给我的dump文件，说它的程序出现了卡死，看了下程序的主线程栈，居然又碰到了 OnUserPreferenceChanged 导致的挂死问题，真的是经典中的经典，线程栈如下： 0:000:x86> !clrstack OS Thread Id: 0
一：背景 1.讲故事 有朋友咨询个问题，他每次在调试 WinDbg 的时候，进程初始化断点之前都会有一些 dll 加载到进程中，比如下面这样： Microsoft (R) Windows Debugger Version 10.0.25200.1003 X86 Copyright (c) Micro
一：背景 1.讲故事 今天给大家带来一个入门级的 CPU 爆高案例，前段时间有位朋友找到我，说他的程序间歇性的 CPU 爆高，不知道是啥情况，让我帮忙看下，既然找到我，那就用 WinDbg 看一下。 二：WinDbg 分析 1. CPU 真的爆高吗 其实我一直都在强调，要相信数据，口说无凭，一定要亲
一：背景 1.讲故事 前段时间有位朋友找到我，说他的程序在客户的机器上跑着跑着会出现偶发卡死，然后就崩掉了，但在本地怎么也没复现，dump也抓到了，让我帮忙看下到底怎么回事，其实崩溃类的dump也有简单的，也有非常复杂的，因为大多情况下都是非托管层面出现的各种故障，非常考验对 C, C++, Win
一：背景 1.讲故事 前段时间分析了一个dump，一顿操作之后，我希望用外力来阻止程序内部对某一个com组件的调用，对，就是想借助外力实现，如果用 windbg 的话，可以说非常轻松，但现实情况比较复杂，客户机没有windbg，也不想加入任何的手工配置，希望全自动化来处理。 真的很无理哈。。。不过这
一：背景 1.讲故事 这周有个朋友找到我，说他的程序出现了内存缓慢增长，没有回头的趋势，让我帮忙看下到底怎么回事，据朋友说这个问题已经困扰他快一周了，还是没能找到最终的问题，看样子这个问题比较刁钻，不管怎么说，先祭出 WinDbg。 二：WinDbg 分析 1. 托管还是非托管泄露 一直关注这个系列
一：背景 1.讲故事 上个月 .NET调试训练营 里的一位老朋友给我发了一个 8G 的dump文件，说他的程序内存泄露了，一时也没找出来是哪里的问题，让我帮忙看下到底是怎么回事，毕竟有了一些调试功底也没分析出来，说明还是有一点复杂的，现实世界中的dump远比课上说的复杂的多。 还是那句话，找我分析是
一：背景 1. 简介 .NET 高级调试要想玩的好，看懂汇编是基本功，但看懂汇编和能写点汇编又完全是两回事，所以有时候看的多，总手痒痒想写一点，在 Windows 平台上搭建汇编环境不是那么容易，大多还是用微软的 MASM + DosBox 搭一个 8086 的环境，这玩意距今快 50 年了。 在以
一：背景 1.讲故事 前几天有位朋友找到我，说他的程序出现了偶发性崩溃，已经抓到了dump文件，Windows事件日志显示的崩溃点在 clr.dll 中，让我帮忙看下是怎么回事，那到底怎么回事呢? 上 WinDbg 说话。 二：WinDbg 分析 1. 崩溃点在哪里 如果是托管代码引发的崩溃，在线程
一：背景 1.讲故事 今天是🐏的第四天，头终于不巨疼了，写文章已经没什么问题，赶紧爬起来写。 这个月初有位朋友找到我，说他的程序出现了CPU爆高，让我帮忙看下怎么回事，简单分析了下有两点比较有意思。 这是一个安全生产的信息管理平台，第一次听说，我的格局小了。 这是一个经典的 CPU 爆高问题，过往
一：背景 1.讲故事 最近给一位朋友做 SQL 慢语句 优化，花了些时间调优，遗憾的是 SQLSERVER 非源码公开，玩起来不是那么顺利，不过从这次经历中我觉得明年的一个重大任务就是好好研究一下它，争取在 SQLSERVER 性能优化上做一些成绩，哈哈！ 个人觉得要想深入研究 SQLSERVER，
一：背景 1. 讲故事 相信有很多朋友在学习 SQLSERVER 的时候都听说过这句话，但大多都是记忆为主，最近在研究 SQLSERVER，所以我们从 底层存储 的角度来深入理解下。 二：理解数据页 1. 数据页的组织 在前面的文章中我也说过，一个 数据页 是 8k 大小，那这 8k 是如何组织的呢
一：背景 1. 讲故事 前些天看到一个奇怪的 Function 函数，调用的是 C# 链接库中的一个 UserLogin 方法，参考代码如下： CREATE FUNCTION dbo.clr_UserLogin ( @name AS NVARCHAR(100), @password AS NVARC
一：背景 1. 讲故事 最近在看 SQL SERVER 2008 查询性能优化，书中说当一个表创建了聚集索引，那么表中的行会按照主键索引的顺序物理排列，这里有一个关键词叫：物理排列，如果不了解底层原理，真的会被忽悠过去，其实仔细想一想不可能实现严格的 物理排列 ，那对性能是非常大的损害，本篇我们就从
一：背景 1. 讲故事 在 SQLSERVER 中有非常多的索引，比如：聚集索引，非聚集索引，唯一索引，复合索引，Include索引，交叉索引，连接索引，奇葩索引等等，当索引多了之后很容易傻傻的分不清，比如：复合索引 和 Include索引，但又在真实场景中用的特别多，本篇我们就从底层数据页层面厘清
一：背景 1. 讲故事 大家都知道数据库应用程序 它天生需要围绕着数据文件打转，诸如包含数据的 .mdf，事务日志的 .ldf，很多时候深入了解这两类文件的合成原理，差不多对数据库就能理解一半了，关于 .mdf 的合成前面的文章已经有所介绍，这篇我们来聊一下 .ldf 的一些内部知识，比如 LSN。
一：背景 1. 讲故事 年前遇到了好几例托管堆被损坏的案例，有些运气好一些，从被破坏的托管堆内存现场能观测出大概是什么问题，但更多的情况下是无法做出准确判断的,原因就在于生成的dump是第二现场，借用之前文章的一张图，大家可以理解一下。 为了帮助更多受此问题困扰的朋友，这篇来整理一下如何 快狠准 的
