!teb 简介 !teb扩展显示线程环境块(teb)中信息的格式化视图. 使用形式 !teb [TEB-Address] 参数 TEB-Address 要检查其TEB的线程的十六进制地址.(这不是从线程的内核线程块派生的TEB地址.)如果在用户模式中省略了TEB地址,则使用当前线程的TEB.如果在内核模式下省略,则显示与当前寄存器上下文相对应的TEB. 备注 TEB是Microsoft Windows线程控制结构的用户模式部分.如果!teb扩展没有参数时,在内核模式下会给您一个错误,您应该使用!

        无论是分析程序崩溃原因,还是解决程序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

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

转载收藏于:http://www.cnblogs.com/kekec/archive/2012/12/02/2798020.html  #调试命令窗口 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #使用gflags.exe工具(在windbg所在目录下),让某个进程启动时,拉取windbg进行调试 如下截图:当名称为captcomm.exe的进程启动时,拉起windbg调试 也可通过脚本命令来实现: // 运行c

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个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

一般在写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

Win32之隐藏DLL隐藏模块技术 这一讲涉及到windows底层技术.跟汇编内容. 我们才可以实现模块隐藏(也称为DLL隐藏) 一丶API反汇编勾引兴趣 我们都用过Windows的进程跟线程API  也就是 GetCurrentThreadId() 跟 GetCurrentProcessId(): 一个是获取进程ID,一个是线程ID 那么我们利用反汇编技术.看看其实现代码是什么. 可以看到使用了FS寄存器.并且获取18内容. 然后+20内容获取出我们的进程Pid 那么FS寄存器是什么. 二丶F

( windows 提供的异常处理机制实际上只是一个简单的框架,一般情况下开发人员都不会直接用到.我们通常所用的异常处理(比如 C++ 的 throw.try.catch)都是编译器在系统提供的异常处理机制上进行加工了的增强版本.这里先抛开增强版的不提,主要叙述原始版本.) 0x01  系统如何找到异常链表 结构化异常处理是以线程为基础的.线程的内核数据结构体现是 _ETHREAD,从它开始进入,通过windbg,找到所关注的异常链表(win7 x86): 查看 _KTHREAD结构(dt _K

一.模块隐藏的实现原理 普通API查找模块实现思路:其通过查询在R3中的PEB(Process Environment Block 进程环境块)与TEB(Thread Environment Block 进程环境块)来找到一个双向链表,通过遍历双向链表中某一成员(字符串)来查找全部模块. 模块隐藏实现思路:在R3层的模块隐藏,我们需要做的就是将其该链表断链,将某一模块从这个双向链表中摘除,这样再调用传统的API时就会搜索不到. 二.结构体成员详细介绍 <1> TEB结构体 -- 内存地址为 f

0x01 前言 ASLR 是一种针对缓冲区溢出的安全保护技术,通过对堆.栈.共享库映射等线性区布局的随机化,通过增加攻击者预测目的地址的难度,防止攻击者直接定位攻击代码位置,达到阻止溢出攻击的目的的一种技术 目前 ASLR 技术据我所知对3种情况进行了保护,分别是映像基址随机化.堆栈基址随机化和 PEB / TEB 随机化(有论文为参考).下面来亲自测试一下,看看地址到底会不会变 实验环境:Windows 10 ,编译器:C-Free 0x02 映像基址随机化 当可执行文件或动态链接库文件被映射

在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中往往没有如此多的真实物理内存.操作系统和硬件(主