因热爱而执着，因执着而成功。

若要打开或切换到“局部变量”窗口，请在“WinDbg”窗口中的“ 视图 ”菜单上，选择“ 局部变量”。在windbg中，dx（display expression）是一个非常强大和灵活的命令，用于显示和解析复杂的数据结构和表达式。使用dx命令，可以直接在命令行中执行表达式，并以易于阅读的方式显示结果。需要注意的是，在使用dx命令之前，需要先加载符号信息，以便能够正确解析表达式和数据类型。现在我们拿到了girl变量的地址 0xe32d6ffad8,注意往下看，同时显示了girl中两个成员变量的地址偏移。

莫慌,这篇博客就来讲讲怎么分析这份崩溃日志。

可以看到，还原的信息中出现了 native-lib.cpp:8:10，这样就可以知道是哪一行出错了。如果你是在 Android Stduio 的 Terminal 窗口中执行的命令，还能直接点击跳转到出现问题的那一行，很方便。这个崩溃信息只能看到 Java_com_teletian_sample_myndk_MainActivity_testCrash+27 这个方法出现崩溃了，具体那一行也不知道。链接：https://www.jianshu.com/p/58760868b468。作者：teletian。

下图展示的了堆是如何破坏的，假设有两处应用程序申请的内存，分别为Entry1和Entry2管理,并且是连续的内存。我们每次使用malloc/new申请的内存就占用一个Entry，一个Entry中只有UserData部分是malloc/new返回给应用程序的使用的地址，其他的部分为当前Entry的元数据，用于堆管理，在调试模式下还有一些用于调试的信息。其实程序崩溃有时候反而是好事，如果在堆被破坏发生时，其他对象的数据被修改，并且不立即导致程序崩溃，而继续运行进入了错误逻辑，可能会导致严重的后果。......

场景介绍有时候当你收到一个dump后，大多数情况可以通过k命令查找到导致栈溢出的函数。但是本文要讲的是，曾经碰到过的栈溢出(stackoverflow), 却无法直接通过k命令查看到当前的函数调用栈。下面将介绍一个简单的方法，找到导致栈溢出的函数。样例代码先声明下，因为产品的实际分析不能够通过网络分享。下面的样例代码，实际上不会导致在上一章场景介绍中提到的问题，可以直接通过crash的栈查找到代码，本文只是通过这个例子来讲解如下场景的分析思路: 如果栈溢出了，通过k命令却无法查找到函数调用栈。.

很多时候会遇到调试crash时只有一条栈调用信息。这种情况下是有机会修复完整的调用栈信息的。1. 查看当前的寄存器的ebp如果这个EBP 没有被破坏的话，就可以尝试修复。(因为EBP 保存的是当前函数的栈底，当前函数的栈底会保存上一层函数的ebp,和指令地址)2. 查看EBP 对应的内存数据3.现在转到0xe4f9fd现在已经能看到上一层栈的调用函数了，如果还想往上层遍历，可以继续读取ebp的值遍历。...

转载：https://blog.youkuaiyun.com/bajianxiaofendui/article/details/100801537崩溃捕捉的dump没有提供堆栈的问题前两天客户现场出现了崩溃，但是程序捕捉生成的dump文件大小为0kb，没有办法只能通过任务管理器创建转储文件进行分析。输入 !analyze -v命令输出如下：通过此堆栈信息看不出任何崩溃的具体原因。再输入~*kv命令查看所有线程的堆栈：可以看到崩溃的线程，输入~56s切换到该线程，再输入kv查看该线程的堆栈如下：注意U

本文来介绍一种，使用Windbg分析内存泄露的方法。样例代码这个样例代码中循环调用一个Memory Leak的函数:#include <iostream>#include <chrono>#include <thread>class TestClass{public: char m_str[100];};void MemoryLeakObj(){ TestClass * pObj = new TestClass; strcpy_s(

如下图所示在_malloc_dbg中在实际要用的内存UserPtr前面还加了一段_CrtMemBlockHeader用于记录内存申请的相关信息，而NoMain'sLand部分为一个4个字节填充了0xFDFDFDFD，主要用来校验内存是否溢出或者破坏，这个不是本文的重点。以malloc为例，我们是不是可以通过宏定义，将malloc更改为my_malloc，然后在my_malloc中记录这次内存申请的信息。不过本文讲解的微软DBUG的CRT库采用的是另外的方式，记录内存申请时候文件名和行号等信息。......

小木在对代码进行测试的时候，发现进程占用了100%的单核CPU资源。并且发现在另一个环境，这个进程占用了12%的CPU资源，因为在这个环境中是8核的CPU。而此时这个进程还并没有处理任何的数据，也就是说会有一个线程就占用一个CPU核的资源。对于这个问题研究的方法可以使用两个工具去进行查看：Process Explorer和Windbg。使用Process Exporer查找占用CPU资源的线程小木采用了一个8核的CPU作为测试环境，这样可以有额外的CPU资源来运行我们的工具。第一步在Proc.

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

最近自己写程序遇到了死锁的问题，看了网上网友的文章写的很好，转载过来，作为一个学习的方向原文链接https://blog.youkuaiyun.com/hgy413/article/details/7572097#comments，这位大神对windbg和汇编都有很多优秀的原创文章先上个代码，自己随手写的： #include <windows.h > CRITICAL_SECTION cs1; CRITICAL_SECTION cs2; D...

场景描述在Windows平台上使用C++开发了一个服务，其中组合了各种各样的第三方组件，一般以lib/dll和头文件的形式使用。有这样一种场景，如下图所示，应用程序申请了一段内存ptr, 但在调用lib.dll的函数接口中其调用了free(ptr)。一般来说我们也尽量避免在一个组件中申请内存，而在另一个组件中释放，这里恰巧是一个bug导致了跨组件的内存申请和释放。那么请各位读者思考一下，这样会有问题吗？如果你是一个老司机，也许已经发现，在某些情况下会在调用free(ptr)的时候导致程序crash。

esp是栈指针，是cpu机制决定的，push、pop指令会自动调整esp的值；ebp只是存取某时刻的esp，这个时刻就是进入一个函数内后，cpu会将esp的值赋给ebp，此时就可以通过ebp对栈进行操作，比如获取函数参数，局部变量等，实际上使用esp也可以；既然使用esp也可以，那么为什么要设定ebp呢？答案是为了方便程序员。因为esp在函数运行时会不断的变化，所以保存一个一进入某个函数的esp到...

WinDBG提供了多种设断点的命令： bp 命令是在某个地址下断点， 可以 bp 0x7783FEB 也可以 bp MyApp!SomeFunction 。 对于后者，WinDBG 会自动找到MyApp!SomeFunction 对应的地址并设置断点。 但是使用bp的问题在于：1）当代码修改之后...

这里使用一个debug程序:.frame.frame命令指定使用哪个局部上下文(作用域)来解析局部变量，或者显示当前的局部上下文帧序号(frame number)是堆栈帧在堆栈回溯中的位置。可以使用k (Display Stack Backtrace)命令或者Calls 窗口查看堆栈回溯。第一行 (当前帧) 的帧序号是0。后面的行分别是1、2、3等等。[

双机调试的时候，不管是Windbg+vmware,还是Windbg+1394,其调试速率都是相对比较低的，有时候执行一条p命令，Windbg的状态都会BUSY..好久...VirtualKD可以完美的解决这一问题。VirtualKD主要是用来提高当使用vmware或virtualBox进行windows内核调试时的速率。以前的双机标准调试方法是利用虚拟COM串口，其速率很低。通常，通过

WinDBG的远程调试由服务端和客户端组成，和visualstudio类似。 被调试的机器是服务端（server）， 我们做调试的机器是客户端(client)。 两台机器都需要安装WinDBG。第一步， 建立WinDBG server 端。使用 -server参数可以使WinDBG以服务器方式启动。 WinDBG可以用多种连接协议让客户端连接，比如命名管道（named pipe

二、手动制造蓝屏    上面简单的提了一下蓝屏后生成的内存转储文件，也就是说蓝屏对于分析软件错误是有帮助的，它是Windows系统提交给我们的一个内核异常报告，加以分析就能便于我们改进自己的程序。    但有时候程序异常不会造成蓝屏，而是死机……死机可是不会提供给我们什么有价值的信息的，我们也无法再死机的时候调试异常（WinDBG双机互调那个另说……）。那怎么办呢？我们就必

简介在过去几年里，崩溃转储(crash dump)成为了调试工作的一个重要部分。如果软件在客户现场或者测试实验室发生故障，最有价值的解决方式是能够创建一个故障瞬间的应用程序状态镜像，然后可以在开发者的机器上通过调试器进行分析。第一代的crash dump通常被称为“全用户转储(full user dump)”，它包含了进程的虚拟内存的全部内容。毫无疑问，这样的dump对于事后调试非常有价值。但