2016-12-09 近期想查看下系统分配了的页的页表项的标志位,但是发现资料较少,所以还是记录下,希望可以对某些朋友有所帮助! 系统:win7 32位虚拟机 平台:KVM虚拟化平台 win7 32位默认是开启了PAE分页模式的,PAE分页模式本质上和普通的32位分页并无区别,只是页表结构和虚拟地址的划分有所不同,这点就不单独讲述,感兴趣可参考另一篇博文:PAE 分页模式详解 首先写了一件简单的内核NT驱动,分配了一个页的内存,然后写入数据0xa1b2c3d4 加载驱动: 看到申请的内存的地址是

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

x86-7-页式管理(Paging) 页式管理是重中之重! 在段式管理下操作系统的运作出现了很多问题,因为段的长度不定,在分配内存时,可能会发生内存中的空闲区域小于要加载的段,或者空闲区域远远大于要加载的段,这样一通分来分去最后会导致剩下一些内存碎片,也就是可以的内存还有但是都很小而且地址空间不连续,导致无法再继续利用了.为了解决这个问题,从80386 处理器开始,引入了分页机制. 概述: 分页功能从总体上说,是用长度固定的页来代替长度不一定的段, 来解决因段长度不同而带来的内存空间管理问题.

当我们试图去了解复杂系统时,去除其抽象层,直接关注最底层,我们会更容易去理解.使用这种方法,我们来看一下内存和 I/O 接口的最简单和基础的层:处理器和总线的接口.这些细节是更上层问题的基础,例如线程同步.Core i7 的需求等.然而,由于我是一个程序员,我将忽略一些 EE 人关注的问题.下面展示的是典型的 Core 2 架构: Core 2 处理器有 775 个引脚,大约一半仅仅提供电力,并不传输数据.当你按功能对这些引脚进行分组时,你会惊奇地发现处理器的物理接口非常简单.图示的是涉及到内存

在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