无论是分析程序崩溃原因,还是解决程序hang问题,我们最常查看的就是程序调用堆栈.学会windbg调用堆栈命令,以及理解堆栈中的各个参数的意义就显得至关重要. 上图就是一个典型的Windbg堆栈,如果不理解ChildEBP.RetAddr.Args to Child等参数意义,以及它们之间的来龙去脉,调试工作将很难进行下去. 1. 函数参数         函数的参数传递有二种方式:堆栈方式.寄存器方式.如果是堆栈方式传递的,就需要定义参数在堆栈中的传递顺序,并约定函数被调用之后

这里以WPF作为探测用的例子,简单一些,看看Title的值是什么样子.(之所以写这个,因为不是简单的一个!do就能看到东西的,中间要绕两下,这也涉及到了DependencyObject的实现机制及数据的存储机制) 首先用VS新建一个WPF工程,在XAML中我们修改一下Title属性和Background属性,运行,得到界面如下(我故意缩小了窗口宽度以及高度) 那么,Title的完整字符串是什么呢?窗体的背景色是什么呢? 与常规的managed debugging一样,首先attach到该进程上,

一.获取ShadowSSDT 好吧,我们已经在R3获取SSDT的原始地址及SDT.SST.KiServiceTbale的关系里面提到:所有的SST都保存在系统服务描述表(SDT)中.系统中一共有两个SDT,一个是ServiceDescriptorTable,另一个是ServiceDescriptorTableShadow.ServiceDescriptor中只有指向KiServiceTable的SST,而ServiceDescriptorTableShadow则包含了所有的两个SST.SSDT是

有如下Class.若想查看静态变量内容.因为静态变量和类绑定,仅需要查看类即可. namespace ConsoleApplication13 { class Program { public static string public_string = "pubstr_static"; public static string private_string = "pristr_static"; ... } } 1.查找类. !Name2EE ConsoleAppli

SSDT HOOK 的原理其实非常简单,我们先实际看看KeServiceDescriptorTable是什么样的.         lkd> dd KeServiceDescriptorTable     8055ab80  804e3d20 00000000 0000011c 804d9f48     8055ab90  00000000 00000000 00000000 00000000     8055aba0  00000000 00000000 00000000 00000000  

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

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/

打开菜单: File->Symbol File Path... 输入: C:/MyCodesSymbols; SRV*C:/MyLocalSymbols*http://msdl.microsoft.com/download/symbols 随便绑定一个进程,然后输入 dt _eprocess

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

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

一.windbg查看内存命令: 当我们在调试器中分析问题时, 经常需要查看不同内存块的内容以分析产生的原因, 并且在随后验证所做出的假设是否正确. 由于各个对象的状态都是保存在内存中的, 因此内存的内容也就相当于对象的状态. d命令最常见的格式就是根据指定的类型信息来显示存储在某地址中的数据. 调试器并不会去猜测这个地址上存储的是什么数据, 因为在大多数情况下猜测都是错误的. 所以需要用户显式地制定按照何种格式来解析数据. 命令格式如下: 语法:d [type][address range] /

一般在写Windows内核程序的时候,经常会出现蓝屏的问题,这个时候一般是采用记录下dump文件然后用windbg查看得方式,具体的过程就不说了,网上一大堆的内容.现在我主要记录自己当初按照网上的方案出现windbg的open crashdump项呈现灰色的情况.就像下面这样 这个问题曾今百思不得其解,曾今一度以为是自己的win10不能很好的兼容这个,后来发现自己想多了 ( ^_^ ),现在公布这个问题的解决方案.主要是确保下面的工作完成 1)首先需要在虚拟机上确保我们打开了抓取dump文件的功

1.http://www.cnblogs.com/huangyong9527/category/384128.html 2.http://www.cnblogs.com/pugang/category/415395.html Ret 函数返回地址   ChildEBP RetAddr的解释 摘要: 参考文章http://www.sevenforums.com/crash-lockup-debug-how/34871-advanced-principles-debugging.htmlChildE

在ntddk.h中定义了该函数原型: #if (NTDDI_VERSION >= NTDDI_WINXP) NTKERNELAPI NTSTATUS IoAttachDeviceToDeviceStackSafe( __in  PDEVICE_OBJECT SourceDevice, __in  PDEVICE_OBJECT TargetDevice, __deref_out PDEVICE_OBJECT *AttachedToDeviceObject ); #endif 我们加载微软的sfil

一.内存管理概念 1. 物理内存概念(Physical Memory Address)     PC上有三条总线,分别是数据总线.地址总线和控制总线.32位CPU的寻址能力为4GB(2的32次方)个字节.用户最多可以使用4GB的真实物理内存.PC中很多设备都提供了自己的设备内存.这部分内存会映射到PC的物理内存上,也就是读写这段物理地址,其实读写的是设备内存地址,而不是物理内存地址. 2. 虚拟内存概念     虽然可以寻址4GB的内存,但是PC中往往没有如此多的真实物理内存.操作系统和硬件(主

抓取到的数据, 要批量写数据到 ORACLE , 一开始是用的EF, 处理速度很慢. 主要表现在验证数据上(db.GetValidationErrors), 每分钟才能写 1000条不到. 换成 EnterpriceLibrary.Validation (Validation.Validate) 后, 验证速度大增, 1000条只需几秒钟. 但是整体速度还是慢, 是因为每条数据都被EF转换为一个INSERT语句.   我花了一些时间用 OracleBulkCopy (需要引用客户端下面的 Ora

_EPROCESS结构简单了解! lkd> dt _EPROCESSnt!_EPROCESS   +0x000 Pcb              : _KPROCESS   +0x06c ProcessLock      : _EX_PUSH_LOCK   +0x070 CreateTime       : _LARGE_INTEGER   +0x078 ExitTime         : _LARGE_INTEGER   +0x080 RundownProtect   : _EX_RUNDO

CVE-2015-0057 POC构造 & 利用分析 主要内容: 构造POC 利用思路 0x00 初探 从这篇文章可以获知: 1.问题出在 win32k!xxxEnableWndSBArrows 函数,其在触发 user-mode callback 后,执行完相应操作后从用户层返回到内核层,对接下来操作的对象未能验证其是否已经释放(更改),而继续对其进行操作,导致UAF.触发user-mode callback的调用流程为: 2.所涉及的敏感对象为 tagSBINFO,可以通过CreateWin

CVE-2014-1767 漏洞分析 1. 简介 该漏洞是由于Windows的afd.sys驱动在对系统内存的管理操作中,存在着悬垂指针的问题.在特定情况下攻击者可以通过该悬垂指针造成内存的double free漏洞. 实现对漏洞的有效利用,攻击者利用成功可导致权限提升.afd.sys是内核用来管理socket的模块. 影响的系统包括(32bit & 64 bit):  Windows Server 2003 Windows Vista Windows Server 2008 Windows 7

Windows kernel pool 1. 简介 Kernel pool类似于Windows用户层所使用Heap,其为内核组件提供系统资源.在系统初始化的时候,内存管理模块就创建了pool. 严格的来说,pool只分为nonpaged pool和paged pool两类. nonpaged pool: 只能常驻于物理内存地址,不能映射.(reside in physical memory at all times and can be accessed at any time without