国产欧美精品在线,国产亚洲精品久久久久动,国产农村妇女精品一区二区

让xp加蝲指定的内核版�?-别以为xp加蝲的内核��L��来自于ntoskrnl.exe!!!

__ay — Sat, 06 Apr 2013 05:16:00 GMT

之前ida+windbg调内核发现内核的地址和ida中不匚w��....搞了半天,�l�于发现是这个原�?
我ida是ntoskrnl.exe .... 而windows中加载的版本�?span style="font-size: 14px;">ntkrpamp.exe

忘了操作�pȝ��会根据处理器型号加蝲不同版本内核�?...
正好看到高端调试上有关于�q�个的讨�? http://advdbg.org/forums/2142/ShowPost.aspx

但是我的分析是基于ntoskrnl的，没办法，只好强制指定�pȝ��加蝲ntosknrl�?得做以下几个工作

1 把vm的processor调成单核单处理器
2 开windows虚拟�? ��Z��告诉�pȝ��现在是单核单处理器模�?得跑一下这个命�?nbsp;rundll32.exe setupapi,InstallHinfSection ACPIAPIC_UP_HAL 131 %windir%\inf\hal.inf
参�? 如何修改Windows XP�pȝ��的内核类�?nbsp; http://blog.sina.com.cn/s/blog_5918846401000bik.html
3 当然,�q�里�q�没�l�束,如果处理器支持PAE 那么�pȝ��会加载ntoskrnla 所以还得禁用PAE. �?span style="font-family: arial, 宋体, sans-serif; font-size: 14px; line-height: 24px; text-indent: 30px; background-color: #ffffff;">BOOT.INI里面, 启动讄��中如果有/noexecute=optin��替换改�?execute,没有的话��加�?/span>/execute

完了后就会加载ntoskrnl�?效果�?

指定其它�pȝ��Ҏ��c�M��,在此仅抛砖引�?nbsp;

__ay 2013-04-06 13:16 发表评论

__ay — Thu, 12 Jan 2012 05:52:00 GMT

解答出处

http://stackoverflow.com/questions/5014061/whats-the-use-of-atl-packing-constant-when-computing-distance-from-the-start-o

C++标准规定:

�~�译器的�cȝ��c�d��转换对空指针(NULL)�Ҏ��处理,即你NULL�q�行强制�c�d��转化的结果还是NULL,所以�?

				static_cast�c�d��转化的时�?_ATL_PACKING的值得是非零就�?/code>


						
				 
		
				C++ Standard 4.10/3 Pointer conversions [conv.ptr]:
		
		An rvalue of type “pointer to cv D,�?where D is a class type, can be converted to an rvalue of type “pointer to cv B,�?where B is a base class (clause 10) of D. If B is an inaccessible (clause 11) or ambiguous (10.2) base class of D, a program that necessitates this conversion is ill-formed. The result of the conversion is a pointer to the base class sub-object of the derived class object. The null pointer value is converted to the null pointer value of the destination type.


__ay 2012-01-12 13:52 发表评论



__ay — Thu, 05 Jan 2012 01:17:00 GMT
@作�? ay @文章出处: cnss-ay的博�?/a>@Notice: 转蝲��h��明出处！若文章显�C�Z��完整�Q�可以到文章出处阅读�?/font>
  
 此文会涉及到一些普通堆的知识，�q�些内容可以参见我之前的文章 WINDBG的堆调试--了解HEAP�l�织
 堆破�?/h1> 所谓的堆破坏，是说没控制好自己的指针，把不属于你分配的那块内存�l�写覆盖了。这块内存可能是你程序的数据�Q�也可能是堆的管理结构。那么这个会��D��怎样的后果呢�Q�可能的情况我们来yy�?/font>
  把程序里的计���结果覆盖了�Q�这也许会让你重复看了N�ơ代码，校验了N�ơ计���逻辑也搞不明白�ؓ何计���结果还是有问题  
堆管理结构被破坏了，new/delete�Q�或者malloc/free操作��p�|  
�{�等�{�等~
 堆破坏较为理想的情况是被修改的数据会马上��D���E�序crash�Q�最差的情况是你的堆数据莫名其妙在今天被改了�Q�但明天才crash。这个时候在��d��析crash�Q�就如我们的警察叔叔现在接手一�?0�q�前的案子一�?---无从下手。老外�U�C��为heap corruption是很贴切的，有时候咱堆数据被意外���改是无声无息的�Q�你也许没法从界面甚��x��志文件中看到它被���改的一点迹象，当到某一个时刻，�q�种错误会暴露出来，然而这个时候查看堆信息也许会是毫无头��A。所以对于堆破坏�Q�咱的策略是���早发现我们的堆被篡改了�Q�最好能够在堆数据被意外���改的那一时刻诱发一个异常来提醒我们----兄弟�Q�你的堆被腐蚀了�?/font>
 微��Y提供了一些方案，来帮助我们诊断堆破坏。一般来��_��堆破坏往往都是写数据越界造成的（yy的第二种情况�Q�如果是�W�一�U�情况其实还���单，下个内存断点���好�Q�，所以微软在堆分配上�Q�给�E�序员门额外提供�?�U�堆分配模式--完全��堆�Q�full page heap�Q�，准页�?normal page heap)�Q�用来检���堆被写���界的情��c�?/font>
 
 完全��堆�Q�full page heap�Q?/h1> 
������原�?/h2> 完全��堆的检���基本思�\是通过分配盔R��的一个页�Q��ƈ���其设�ؓ不可讉K��属性，然后用户数据块会被分配到内存��늚�最末端�Q�从而实现越界访问的������。当我们对堆中分配的内存��d�����界后便会访问到那个不可�ȝ����，�pȝ��捕获到改�ơ异常后会试图中断执行�ƈ���该异常上报�l�debugger�Q�或者崩溃。具体的内存�l�织�l�构如下�?/font>
 
 摘自《��Y件调试�?/font>
  
 与普通堆不同的是�Q�内存块前面的HEAP_ENTRY�l�构被DPH_BLOCK_INFORMATION�l�构取代�Q�这个结构内部记录了��堆模式下这个内存块的一些基本信息。如果用��h��据区前面的数据，也就是DPH_BLOCK_INFORMATION�l�构被破坏了�Q�那么在释放内存块的时候系�l�会报错�Q�如果编�E�者对�q�块内存块读写越界了�Q�当�Ӟ���q�里���界有几�U�情况：
  读越界，但只是访问了块尾填充部分数据�Q�那么系�l�不会报�? 
写越界，但只���改了图中块���֡�充的部分�Q�那么在堆块释放的时候会报错  
读越界，且超�q�了块尾填充的部分，讉K����C��栅栏��，那么�pȝ��会立��x����Z��个异常�ƈ中断执行  
写越界，且超�q�了块尾填充部分�Q�写��C��栅栏��，那么�pȝ��会立��x����Z��个异常�ƈ中断执行
 �q�里需要注意的�q�是块尾填充不一定存�?/font>�Q�块���֡�充是因�ؓ要满���_��内存的最���分配粒度，如果本��n内存块的分配�_�度���已�l�是最���分配粒度的倍数了，那么块尾填充��׃��存在了，比如堆内存分配粒度是�? bytes�Q�那么如果申请了14 bytes的话会有2 bytes的大徐小的块���֡�充块�Q�如果申请了24bytes�Q�那么就没有块尾填充了，因�ؓ24正好�?的倍数�?/font>
  
 �C�Z��
 开启全��堆�Q�用windbg目录下的gflags或者装一个appverifier都可以开启）�Q�通过自己写的一个heap.exe来看一下如何��用全��堆������堆破坏情况heap.exe代码如下�Q?/font>
 #include "windows.h"

int main()
{
	HANDLE heap_handle = HeapCreate( NULL , 1024 , 0 ) ;
	char *temp = NULL ;

	char *buffer = (char*)HeapAlloc(heap_handle , NULL , 128) ;
	char *buffer1 = (char*)HeapAlloc(heap_handle , NULL , 121) ;
	temp = buffer ;

	for( int i = 0 ; i < 138 ; ++i )
	{
			*(temp++) = 'a' ;
	}

	HeapFree(heap_handle, 0 , buffer ) ;
	HeapFree(heap_handle, 0 , buffer1 ) ;
	HeapDestroy( heap_handle) ;
	return 0 ;
}
在第14行向buffer写入138字节�Q�这昄������界了，然后在用windbg启动heap.exe�Q�直接运行，会发现报错如�?/font>

0:000> g
(1f50.1f54): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000080 ebx=00000000 ecx=02596000 edx=02596000 esi=00000001 edi=00193374
eip=00191068 esp=0016fdc8 ebp=0016fddc iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010297
heap!main+0x68:
00191068 c60161          mov     byte ptr [ecx],61h         ds:0023:02596000=??

报了一个内存访问错误，然后看一下调用堆�?/font>

0:000> kb
ChildEBP RetAddr  Args to Child              
0016fddc 0019120f 00000001 023fbfd0 0239df48 heap!main+0x68 [d:\projects\heap\main.cpp @ 14]
0016fe20 765b1114 7ffd3000 0016fe6c 778eb429 heap!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 582]
0016fe2c 778eb429 7ffd3000 757369d8 00000000 kernel32!BaseThreadInitThunk+0xe
0016fe6c 778eb3fc 00191357 7ffd3000 00000000 ntdll!__RtlUserThreadStart+0x70
0016fe84 00000000 00191357 7ffd3000 00000000 ntdll!_RtlUserThreadStart+0x1b
可以看到是第14行报的错�Q�但�?4行的代码�q�行了那么多�ơ，我们再看一下这个时候变量i的值是多少
0:000> dv i
              i = 0n128
昄����Q�在填充�W?28字节的时候，我们的temp指针讉K����C��栅栏��，从而报��Z��一个内存违规的异常�?/font>

�q�里��带看一下如果我们分配的内存不是8 bytes的情况（一般堆内存分配�_�度�? bytes�Q�所以申�?28 bytes的内存时是不会有块尾填充部分的）
那我们接下来看另外一�D�代�?/font>

我们把第10行的temp = buffer�Ҏ��temp = buffer1
因�ؓbuffer1甌����?21 bytes�Q�也���是说它�? bytes的填充字�?/font>

0:000> g
(1ba0.1ba4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000080 ebx=00000000 ecx=024c8000 edx=024c8000 esi=00000001 edi=00033374
eip=00031068 esp=002cfb80 ebp=002cfb94 iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010297
heap!main+0x68:
00031068 c60161          mov     byte ptr [ecx],61h         ds:0023:024c8000=??
0:000> dv i
              i = 0n128
可以看到变量i�q�是128�Q�也���是说我们还是在讉K��到第128字节后才引发讉K��异常�Q�而不是我们期望的121字节后就引发异常�?/font>

�q�里也就是说如果我们的代码中对申��L��堆内存写���界了，写数据覆盖块���֡�充部分的时候�ƈ不会引发异常�Q?/font>

但是�Q�这�q�不代表我们的写���界问题不会被发现。块���֡�充部分是会被填充上固定数据的�Q�系�l�在适合的时机（比如销毁堆的时候）会校验块���֡�充块�Q�如果发现块���֡�充块数据有变�Q�那么便会报一个verifier异常�Q�比如我们把代码中的for循环�ơ数改�ؓ124
    for( int i = 0 ; i < 124 ; ++i )
那么windbg会中断在�W?9�?/font>

    HeapDestroy( heap_handle) ;
提示内容如下
=======================================
VERIFIER STOP 0000000F: pid 0x1E3C: Corrupted suffix pattern for heap block. 
    025A1000 : Heap handle used in the call.
    025A7F80 : Heap block involved in the operation.
    00000079 : Size of the heap block.
    025A7FF9 : Corruption address.

=======================================
This verifier stop is not continuable. Process will be terminated 
when you use the `go' debugger command.
=======================================
(1e3c.143c): Break instruction exception - code 80000003 (first chance)
eax=6c75e994 ebx=6c75cf58 ecx=00000002 edx=002bf461 esi=00000000 edi=000001ff
eip=6c753c38 esp=002bf6b4 ebp=002bf8b8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
vrfcore!VerifierStopMessageEx+0x543:
6c753c38 cc              int     3
提示说的很清楚了�Q�appverifier指出了堆和具体的内存块，我们�q�个时候查看buffer1的值是0x025a7f80 �Q�正好就是出问题的堆块，出问题的地址�?x025a7ff79�Q�正好就是buffer1内存块的边界�Q�错误原因是Corrupted suffix pattern for heap block�Q�也���是说咱块尾填充部分�Q�suffix pattern for heap block�Q�被破坏�Q�corrupted�Q�了
�l�论�Q�只要写���界�Q�系�l�都能够������出来，只不�q�如果写���界写到了栅栏页会理解触发异�怸�断，而写���界只写了块���֡�充部分，那么�pȝ��在适当时机�Q�比如堆被销毁，或者这块内存被重新分配�{�时机）会对块尾填充部分做完整性检���，如果发现被破坏了�Q�就会报错。当�Ӟ��你可以根据错误号�Q?font color="#0000ff">蓝色字体部分�Q�信息去appverifier的帮助文档中查找更详�l�的错误说明�?/font>
�l�构详解
�q�次咱来倒叙�Q�先从最基本的内存堆块结构DPH_BLOCK_INFORMATION开始介�l�，DPH_BLOCK_INFORMATION�l�构微��Y也有对应文档介绍

�Q�摘自MSDN�Q?/font>

 
其中prefix start magic和prefix end magic是校验块�Q�用来检���DPH_BLOCK_INFORMATION是否被破坏，�q�些������部分属于DPH_BLOCK_INFORMATION�l�构。我们先来用windbg探究下DPH_BLOCK_INFORMATION�q�个最基本的结�?再一��?我们打开windbg调试heap.exe.�q�行到第10�?�q�个时候变量的值是
0:000> dv heap_handle
    heap_handle = 0x024a0000
0:000> dv buffer
         buffer = 0x024a5f80 "???"
0:000> dv buffer1
        buffer1 = 0x024a7f80 "???"
�q�里可以看到一个很有趣的现�?buffer1和buffer的地址正好相差8K,也就是两个页的大��?�q�当然是因�ؓ��堆的原因啦,其实�q�两块内存分配是盔R��着�?虚拟内存�l�构如下图所�C?/font>




buffer内存块（4K�Q?/font>
栅栏��（4K�Q?/font>
buffer1内存�?4K)
栅栏��?4K)
 
�׃��buffer和buffer1分配的大���是一��L���Q�buffer1加上���N��填充块和buffer的大���相同）�Q�所以这两块内存正好相差8K
而DPH_BLOCK_INFORMATION���在我们甌���的内存块指针的前0x20字节处，用dt命��o看的�l�果如下:
0:000> dt _DPH_BLOCK_INFORMATION 0x024a5f80-0x20
verifier!_DPH_BLOCK_INFORMATION
   +0x000 StartStamp       : 0xabcdbbbb
   +0x004 Heap             : 0x024a1000 Void
   +0x008 RequestedSize    : 0x80
   +0x00c ActualSize       : 0x1000
   +0x010 Internal         : _DPH_BLOCK_INTERNAL_INFORMATION
   +0x018 StackTrace       : 0x003d9854 Void
   +0x01c EndStamp         : 0xdcbabbbb
 
0x024a5f80-0x20���是DPH_BLOCK_INFORMATION�l�构的地址。DPH_BLOCK_INFORMATION�l�构在已分配和已释放的状态下�Q�StartStamp和EndStamp�Q�也���是MSDN图中的prefix start magic和prefix end magic�Q�是不同的，昄���dt输出的结果看来，�q�个内存块是已分配状态。StackTrace记录了分配这个内存块时的调用栈，可以用dds来看一下这个内存块被分配时候的调用�?/font>

0:000> dds 0x003d9854 
003d9854  00000000
003d9858  00004001
003d985c  00090000
003d9860  5b3b8e89 verifier!AVrfDebugPageHeapAllocate+0x229
003d9864  776d5c4e ntdll!RtlDebugAllocateHeap+0x30
003d9868  77697e5e ntdll!RtlpAllocateHeap+0xc4
003d986c  776634df ntdll!RtlAllocateHeap+0x23a
003d9870  003b1030 heap!main+0x30 [d:\projects\heap\main.cpp @ 8]
003d9874  003b120c heap!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 582]
003d9878  76451114 kernel32!BaseThreadInitThunk+0xe
003d987c  7766b429 ntdll!__RtlUserThreadStart+0x70
003d9880  7766b3fc ntdll!_RtlUserThreadStart+0x1b
输出�l�果我们可以看到�q�个内存块是在main.cpp,也就是我们的�C�Z��代码的第8行分配的�Q�第8行是char *buffer = (char*)HeapAlloc(heap_handle , NULL , 128) 正好���是分配buffer内存的那条语句。这个结构的其它字段�Q�顾名思义�Q�ActualSize指明了实际分配字节数�Q?x1000 bytes也就�?K大小�Q�Internal�q�个字段保存了个内部�l�构�Q�用windbg也看不出�q�个�l�构信息�?/font>

当然��Z��防止内存块前面的数据被冲��h���Q�除了DPH_BLOCK_INFORMATION外，�pȝ���q�通过DPH_HEAP_BLOCK保存了所分配内存块的信息�Q?/font>

通过!heap –p –h [address] 可以查看到页堆的信息
0:000> !heap -p -h 0x024a0000                            //heap_handle的�?/font>
    _DPH_HEAP_ROOT @ 24a1000
    Freed and decommitted blocks
      DPH_HEAP_BLOCK : VirtAddr VirtSize
    Busy allocations
      DPH_HEAP_BLOCK : UserAddr  UserSize - VirtAddr VirtSize
        024a1f6c : 024a5f80 00000080 - 024a5000 00002000
        024a1f38 : 024a7f80 00000079 - 024a7000 00002000


可以看到�Q�buffer内存块对应的DPH_HEAP_BLOCK�l�构地址�?font color="#0000ff">024a1f6c
0:000> dt _DPH_HEAP_BLOCK 024a1f6c
verifier!_DPH_HEAP_BLOCK
   +0x000 NextFullPageHeapDelayedNode : 0x024a1020 _DPH_HEAP_BLOCK
   +0x004 DelayQueueEntry  : _DPH_DELAY_FREE_QUEUE_ENTRY
   +0x000 LookasideEntry   : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
   +0x000 UnusedListEntry  : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
   +0x000 VirtualListEntry : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
   +0x000 FreeListEntry    : _LIST_ENTRY [ 0x24a1020 - 0x0 ]
   +0x000 TableLinks       : _RTL_BALANCED_LINKS
   +0x010 pUserAllocation  : 0x024a5f80  "???"
   +0x014 pVirtualBlock    : 0x024a5000  "???"
   +0x018 nVirtualBlockSize : 0x2000
   +0x01c Flags            : _DPH_HEAP_BLOCK_FLAGS
   +0x020 nUserRequestedSize : 0x80
   +0x024 AdjacencyEntry   : _LIST_ENTRY [ 0x24a1f5c - 0x24a1fc4 ]
   +0x02c ThreadId         : 0x3f4
   +0x030 StackTrace       : 0x003d9854 Void
从dt的数据看来，�q�个�l�构大小�?x34�Q�buffer和buffer1的DPH_HEAP_BLOCK�l�构首地址正好也是相差0x34�Q�说明这两个�l�构是紧挨着的，下一步在让我们来看看DPH_HEAP_BLOCK�l�构是如何组�l�的�?/font>


摘自《��Y件调试�?/font>

 
�q�个是整个的��堆�l�构图，我们先来说说DPH_HEAP_BLOCK的组�l�吧�Q�在图中0x16d00000是页堆的首地址�Q�也���是��堆的句柄，我们调试器中�Q�页堆首地址则是0x024a0000�Q��ؓ了数据统一�Q�我�q�是�?x024a0000作�ؓ堆句柄来讲解。我们的DPH_HEAP_BLOCK其实���在堆块节点池里边，我们可以�q�似把这个节�Ҏ��看成一个大型的DPH_HEAP_BLOCK数组�Q�但有个地方在��Y件调试中没有提到�Q�就是在win7下，�q�行时这些DPH_HEAP_BLOCK�l�构都是以二叉��^衡数的结构来�l�织的，�q�个树的�l�构的入口正是在TableLinks字段内，�q�么做的原因也大概是因�ؓ能够在分配时更快的烦。我们再看看DPH_HEAP_ROOT�l�构�Q�这个结构储存了整个��堆的必要信息，它就相当于普通堆的_HEAP�l�构�?/font>

0:000> dt _dph_heap_root 24a1000
verifier!_DPH_HEAP_ROOT
   +0x000 Signature        : 0xffeeddcc
   +0x004 HeapFlags        : 0x1002
   +0x008 HeapCritSect     : 0x024a16cc _RTL_CRITICAL_SECTION
   +0x00c NodesCount       : 0x2c
   +0x010 VirtualStorageList : _LIST_ENTRY [ 0x24a1fa0 - 0x24a1fa0 ]
   +0x018 VirtualStorageCount : 1
   +0x01c PoolReservedLimit : 0x024a5000 Void
   +0x020 BusyNodesTable   : _RTL_AVL_TABLE
   +0x058 NodeToAllocate   : (null) 
   +0x05c nBusyAllocations : 2
   +0x060 nBusyAllocationBytesCommitted : 0x4000
   +0x064 pFreeAllocationListHead : (null) 
   +0x068 FullPageHeapDelayedListTail : (null) 
   +0x06c DelayFreeQueueHead : (null) 
   +0x070 DelayFreeQueueTail : (null) 
   +0x074 DelayFreeCount   : 0
   +0x078 LookasideList    : _LIST_ENTRY [ 0x24a1078 - 0x24a1078 ]
   +0x080 LookasideCount   : 0
   +0x084 UnusedNodeList   : _LIST_ENTRY [ 0x24a1ed0 - 0x24a16e4 ]
   +0x08c UnusedNodeCount  : 0x28
   +0x090 nBusyAllocationBytesAccessible : 0x2000
   +0x094 GeneralizedFreeList : _LIST_ENTRY [ 0x24a1f04 - 0x24a1f04 ]
   +0x09c FreeCount        : 1
   +0x0a0 PoolCommitLimit  : 0x024a2000 Void
   +0x0a4 NextHeap         : _LIST_ENTRY [ 0x5b3e9a58 - 0x23a10a4 ]
   +0x0ac ExtraFlags       : 3
   +0x0b0 Seed             : 0xfed6f13a
   +0x0b4 NormalHeap       : 0x027d0000 Void
   +0x0b8 CreateStackTrace : 0x003d9824 _RTL_TRACE_BLOCK
   +0x0bc ThreadInHeap     : (null) 
   +0x0c0 BusyListHead     : _LIST_ENTRY [ 0x24a10c0 - 0x24a10c0 ]
   +0x0c8 SpecializedFreeList : [64] _LIST_ENTRY [ 0x24a10c8 - 0x24a10c8 ]
   +0x2c8 DelayFreeListLookup : [257] (null) 
   +0x6cc HeapCritSectionStorage : _RTL_CRITICAL_SECTION

�q�里边维护了很多�q�行时信息，比如说DPH_BLOCK_INFORMATION中的那个二叉树入口其实就是保存在BusyNodesTable 字段�Q�这里面记录了所有被分配了的内存块所对应的DPH_BLOCK_INFORMATION。当�Ӟ���q�里面一些信息��Y件调试里面都有介�l�，很多看名字也能够猜到大概意思，看名字猜不到啥意思的字段�Q�其实我也猜不到。。�?_-|||在创建页堆后�Q�所有内存分配都分配在页堆中�Q�通过分配的地址也能看得出来�Q�我们分配的内存都是024a打头�Q�，而非普通页堆中�Q�普通页堆也仅仅只是保存一些系�l�内部��用的数据。一般来��_��堆块节点池加上DPH_HEAP_ROOT�l�构大小正好�?个内存页�Q�也���是16K�?/font>

优缺�?/h2>
�~�点�Q�消耗大量虚拟内存，每块内存的分配粒度是2个页�Q?K�Q�，
优点�Q�能够立��x��莯���界读写操作，通过调用栈就可以�q�溯到问题源头。能够快速定位问题代码�?/h3>
使用������Q?2位下不适宜跑配�|�文件结构比较复杂的软�g�Q�让我们来假设一个xml配置文�g下有3000个节点，每个节点�?个字�W�串描述属性，如果把这些配�|�文件信息�{化�ؓstl�l�构来保存，那么每个节点则需要�ؓ此分�?*8K的空��_��3000��w���|�则需�?000*5*8K=117MB虚拟内存�Q�如果每个节点信息再多一些呢�Q�这样会��D��虚拟内存耗尽从而出��C���p�d��内存问题�Q�比如，new��p�|�Q�。当�?4位就不存在这�U�问题了7T的虚拟内存空��_��现在看来应该是够用了�?/h3>
 
对于调试堆破坏来��_��其实我们只要了解DPH_BLOCK_INFORMATION�l�构和DPH_HEAP_BLOCK中的基本字段���差不多了，�q�样更方便我们定位出错源头。比如在appverifier报错后（或者你�E�序自己莫名其妙崩溃或者数据被���改后，要知道appverifier�q�不��L��可信的）�Q�我们可以自己手动调试出错的堆块�l�构�Q�DPH_BLOCK_INFORMATION�Q�DPH_HEAP_BLOCK和DPH_HEAP_ROOT�Q�，������以下这些点�Q?/font>


������堆块管理结构的校验字段是否完整 
是否块尾填充部分有被修改�q?/font> 
������到未释放或者重复释攑֠�资源�Ӟ��查看问题的堆块被分配时的调用�?/font>

其实��堆�q�好�Q�它有较强的实时性，所以�ƈ不需要太多手工调试的操作�Q�越界读写都会立卌���发异常�ƈ且中断，所以从�q�点看来�Q�它是一些��Y件用来检���堆资源是否正确使用的必备良药~ 但是相对于页堆，准页堆的调试则需要更好的��M��解准��堆工作原理了，因�ؓ它提供的堆块������不是实时的�Q�所以发现问题后�Q�需要咱“精湛的调试内功“去扑և�源头�Q�关于准��堆的东西，下回再说吧，敬请期待~


__ay 2012-01-05 09:17 发表评论


__ay — Tue, 03 Jan 2012 08:32:00 GMT
遥想上一�ơ这么清静下来思考还是在��d��7月初了，当时�q�是���迷茫，比较泄气的是没能��d��望的那个���组�Q�但后面看来�q�不���坏事，��L��现在�q�个���组在我看来是很理想的一个状态，凝聚力，上进�Q�分享，有种当初凝聚的感觉，一个房��_��一个团队，天天嬉皮�W�脸�Q�却不忘一赯���寻自��q��梦想。大半年工作下来�Q�也是该回顾下自己半�q�的工作
  
  量化代码的作�?/li>
  和大学时不一��P��我的代码�q�不会马马虎虎赶完去参加比赛后就弃之不理了，�q��ƈ不是一�ơ性代码，它需要维护，更需要体现其价倹{��优化完了一个功能，甚至不能说出它比以前好在哪里�Q�也没有数据可量化，更要命的是我���p��么让�q�项目过��M���Q�花�?个月做出来的东西�Q��ƈ没有��M��人知道，也没��M��人去��x���Q�没有�Q何测试数据来说明我让�q�个功能有了很大�E�度上的�q�展。就像以前对凝聚的娃儿们说的�Q�写出来的��Y件没人用�Q�不���用到的技术再�_�湛�Q�也是堆废代码。切记切讎ͼ�不论如何�Q�要量化自己的工作，有数据的�Ҏ��别�h才知道是�q�步�?/p>
  沟通好重要
  从来到公司到现在�Q�终于知道什么叫���出期望了。as一个合格程序员�Q�你得按时完成老大布置的�Q务。但事情�q�远不止�q�些�Q�老大很多时候只是给你指明方向，�q�不会告诉你每一步怎么赎ͼ��q�样做的好处能够让你自由发挥�Q�坏处是�Ҏ���q����。这也许是好多新�����来时候的通病�Q�被�z�指��d��后无从下手。这个可是个沟通的�z�，首先必须要精���了解老大的预期，��C���Q�我�q�里说的是精���了解，当然老大的预期�ƈ不一定完全正���，但是�Q�在你没法辩驳用数据辩驳他不正确的时候，你要做的���是攉���资料�Q�然后分析可行性，再然后给老大复述你的计划�Q�在我看来，我其实�ƈ不希望我的计划和老大的预惛_��全一��_��更多的讨论才会��生一个完���的�Ҏ���Q�如果你仅仅只是按老大说的��d���Q�那么就是那个qualified programmer�Q�一定一定要��C���Q�你最好得有自��q��观点�Q�观点必���d�����撞�Q�碰撞中才会反思各放观点的优劣�Q�一个权衡的观点才会出来。其实需求确认这一步可能很多�h看来很冗余，但是在我看来很是必需�Q�因为口口相传的需求�ƈ不会�_����到哪里去�Q�所以需要确认确认再���认�Q�省的做完后又得打翻重做�?/p>
  技术的事，不可�p�涂
  技术的事情�Q�千万别�p�涂�Q�你的程序crash了，你得知道为啥�Q�你的new��p�|了，你也得知道�ؓ啥，因�ؓ随着�E�序���来���大�Q�你debug的难度会���来���高�Q�有问题�Q�早解决�Q�而且�Ҏ��有问题，你必��ȝ��其所以然。当�Ӟ��那些恶心的没有文档而且注释只注释了一半的�W�三方库除外�Q�用�q�种库还不如自己重新写一个去�Q�一直认������U�成品的存在���是个鸡肋。编�E�里面有一句话叫donot repeat yourself�Q�你得管理好�q�且�ȝ��你的代码�Q���L��一天，你或者别�����能用得到�?/p>
  动态更��C��先��
  �q�是我最大的一个毛病了吧，其实攑֜�互联�|�公司这�U�催�q�度好比催命般的大环境下�Q�这���是坏习惯，我工作模式一般是串行化且关中断模式，一件事必须得先做完才开始做下一件事情，中间容不得有��M��注意力的转移。但是往往中间会有更加重要的事情插播进来，当然�Q�如果出现这�U�情况那是项目管理上的悲哀�Q�但事实如此�Q�等待现状改变还不如去适应。清楚的知道优先�U�，�q�其实非帔R��要的�Q�因为很有可能插播进来的��d��兌���到其他同事，处理不好�Q�会出现��目发布前N个�h�{�你的这�U�状况，说难听点�Q�这时候你���成了后腿，重点是别人怎么拖也拖不动�?/p>
  �ȝ��啊锻�?/li>
  说好的每周一�ơ运动在工作三个月后���q��消云散了�Q�我是那�U�做事情的时候容易走火入��的�E�序员，事情没解决之前脑子里全部都是相关的事情，但往往�q�样是最没有效率的，反倒去�q�动�q�动�Q�待�W�二天脑袋清��C��反倒就有结果了�Q�老天喃。。。我关中断的思维模式何时能�{�q�来。。。程序员应该���是最最需要锻炼的���体了吧�Q�一天坐10个小时还不带上厕所的，可以遇见好多人在几年后都会脊椎等地方开始出毛病�Q�但�q�是我们可以遇见得到的啊。。。竟焉���知道了，��Z��不去��L��其发生呢�Q�不为别人，单是��Z��现在或者未来的家�h�Q�好好爱护自��q���w�体比�Q何事情都重要�Q�期待有一个�h�Q�，�Q�，能在我走火入��之际把我拉出来��L��一场球�Q�以前有���妖�Q�有番薯�Q�有葡萄哥，而现在呢�Q�没有你们的城市里我也要健康的活着�Q�不为别的，只�ؓ留着口气把赚来的钱好好的花出�?nbsp; -_-#�Q�指不定哪天我暴毙了银行里还有好几百万，�q�丫的不亏大了�?/p>
 暂时���p��么多吧，希望�q�些能在我今后半�q�有所改善�Q�也许在我看来，技术已�l�不再是全部�Q�做事情的方式才是我今后惛_��前辈学习的地斏V�?/p>

__ay 2012-01-03 16:32 发表评论


__ay — Tue, 03 Jan 2012 07:07:00 GMT
 
 写驱动的时候有个地方老是蓝屏,看了dump发现数据被非法篡改了.
 数据初始化如�?/p> 
 
 if(record_set_ptr != NULL )
{
    record_set_ptr->look_aside_pool_ptr = g_user_control_context.look_aside_pools[type] ;
    record_set_ptr->type = type ;
    record_set_ptr->buffer_size = notify_count * unit_size_of ;
    record_set_ptr->units_count = notify_count ;
    record_set_ptr->complete_count = 0 ;
}
 然后在调用ExFreeToNPagedLookasideList传入record_set_ptr->look_aside_pool_ptr 的时候挂�?发现record_set_ptr->look_aside_pool_ptr已经被改�?
  
 ��Z��跟踪数据在哪里被修改�?先在数据初始化的地方下断,然后��C��record_set_ptr->look_aside_pool_ptr 的地址:0x85c16018
 对这个内存下个断�?
 1: kd> ba w4 85c16018
 w表示在写入时断下,4表示监控范围,单位是字�?nbsp; 
 整个命��o的意思就是让调试器在�pȝ��写入内存85c16018-85c1601b�q�个地址范围的时候中�?
 OK,命��o下完,F5一下就立马断下来了
 1: kd> g
Breakpoint 3 hit
nt!memcpy+0x33:
8053b583 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
 
此时edi的�? 0x85c16018
  
 最后看一下函数堆�?发现是字�W�串拯������界覆盖了后面的数据....  
 后面又想�?出错时record_set_ptr->look_aside_pool_ptr 的值是0x005c0065
 �q�么明显的字�W�串特征竟然没意识到....一看出错值就应该知道是字�W�串覆盖造成�?....


__ay 2012-01-03 15:07 发表评论


WINDBG的堆调试--了解HEAP�l�织
__ay — Sun, 30 Oct 2011 11:05:00 GMT

		@作�? ay @文章出处: cnss-ay的博�?/a>@Notice: 转蝲��h��明出处！若文章显�C�Z��完整�Q�可以到文章出处阅读�?/font>

		HEAP的概�?/h1>
		堆栈堆栈�Q�在操作�pȝ��内存中有两种存储�I�间�Q�一个是堆，一个是栈。堆主要用于存储用户动态分配的变量�Q�而栈呢，则是存储我们�E�序�q�程中的临时变量。当然栈的作用远不止用作存储变量�Q�但�q�不是我们这���文章的讨论内容�?/p>
		
 
		堆（HEAP�Q�的分配�Q���用，回收都是通过微��Y的API来管理的�Q�最常见的API是malloc和new。在往底层��C��点呢�Q�这两个函数都会调用HeapAlloc�Q�RtlAllocateHeap�Q�。同��L��相关函数�q�有HeapFree用来释放堆，HeapCreate用来创徏自己的私有堆。下面是�q�些函数的调用链�Q?/p>
		
HeapCreate->RtlCreateHeap->ZwAllocateVirtualMemory  (�q�里会直接申请一大片内存,至于甌���多大内存,��p���E�PEB�l�构中的字段觉得�Q�HeapSegmentReserve字段指出要申请多大的虚拟内存�Q�HeapSegmentCommit指明要提交多大内存，对虚拟内存的甌���和提交概念不清楚的童鞋，请参见windows核心�~�程相关内容~)
		HeapAlloc->RtlAllocateHeap�Q�至于这里申��L��内存�Q�由于HeapCreate已经甌���了一大片内存�Q�堆���理器这片内存中划分一块出来以满��甌���的需要。这一步申��h��作是堆管理器自己�l�护的，仅当甌���内存不够的时候才会再�ơ调用ZwAllocateVirtualMemory �Q?/p>
		
HeapFree->RtlFreeHeap �Q�对于释攄���内存�Q�堆���理器只是简单的把这块内存标志位已释放让后加入到�I�闲列表中，仅当�I�闲的内存达��C��定阀值的时候会调用ZwFreeVirtualMeMory �Q?/p>
		
HeapDestroy->RtlDestroyHeap->ZwFreeVirtualMeMory   �Q�销毁我们申��L��堆）
		
如何扑ֈ�我们的HEAP信息�Q?/h1>
		WINDBG观察�?/p>
		
源码�Q?/p>
		

				#include "windows.h"

int main()
{
	HANDLE heap_handle = HeapCreate( NULL , 0x1000 , 0x2000 ) ;

	char *buffer = (char*)HeapAlloc(heap_handle , NULL , 128) ;

	char *buffer1 = (char*)HeapAlloc(heap_handle , NULL , 121) ;

	HeapFree(heap_handle, 0 , buffer ) ;
	HeapFree(heap_handle, 0 , buffer1 ) ;

	HeapDestroy( heap_handle) ;
	return 0 ;
}
		
		该源码生成编译生成heap.exe�Q�然后用windbg调试�q�个�E�序�Q�在main函数下断�Q�紧接着执行�W�五行语句，执行�l�果如下
		0:000> p
eax=002e1ca0 ebx=00000000 ecx=6d29b6f0 edx=00000000 esi=00000001 edi=01033374
eip=01031012 esp=0022fe8c ebp=0022feac iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
heap!main+0x12:
01031012 ff150c200301    call    dword ptr [heap!_imp__HeapCreate (0103200c)] ds:0023:0103200c={kernel32!HeapCreateStub (769a29d7)}

		0:000> p
eax=002c0000 ebx=00000000 ecx=77429897 edx=77498500 esi=00000001 edi=01033374
eip=01031018 esp=0022fe98 ebp=0022feac iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
heap!main+0x18:
01031018 8945fc          mov     dword ptr [ebp-4],eax ss:0023:0022fea8=6d222201
0:000> !heap 
Index   Address  Name      Debugging options enabled
  1:   00300000                
  2:   00010000                
  3:   00020000                
  4:   002e0000                
  5:   002c0000       
		HeapCreate执行的返回值存攑֜�eax处，�q�个函数�q�回了一个堆句柄�Q?x002c0000。用!heap命��o查看可以看到�W�五个堆���是我们创徏的堆句柄了�?/p>
		
每个�q�程都存在多个堆�Q�我们也可以通过PEB�l�构来得到进�E�中存在的堆�Q�结果和!heap命��o昄���的内�Ҏ��一��L���?/p>
		
heap!_PEB
   +0x018 ProcessHeap      : 0x00300000 Void         ; �q�程的默认堆
   +0x068 NtGlobalFlag     : 0                                       ; �q�个标志位记录了当前堆调试模�?0为普通调试模�?br />   +0x078 HeapSegmentReserve : 0x100000          ; �q�程在新建堆的时候默认申��L��虚拟内存大小
   +0x07c HeapSegmentCommit : 0x2000               ; �q�程在每�ơ申��h��交的虚拟内存大小�Q�在提交的内存用完后�Q�进�E�会又在一�ơ提交HeapSegmentCommit中指定的内存大小
   +0x080 HeapDeCommitTotalFreeThreshold : 0x10000    ; 当释攄���内存大小大于�q�个阀��|�����p��行内存解除提交操�?br />   +0x084 HeapDeCommitFreeBlockThreshold : 0x1000     ;  当一�ơ性释攄���块大���超�q�这个阀��|�����p��行内存解除提交操作，只有当满������两个条�g时才会调用ZwFreeVirtualMeMory 释放物理内存
   +0x088 NumberOfHeaps    : 5                                               ; 当前�q�程的堆数目,�q�个数目对应着!heap命��o的堆昄���个数
   +0x08c MaximumNumberOfHeaps : 0x10                          ; �q�程所能运行的最大堆数目,若堆数目���过�q�个��g��计HeapCreate���失败了�?br />   +0x090 ProcessHeaps     : 0x77498500  -> 0x00300000 Void ;存储堆句柄的数组,�q�里我们可以得到�q�程的所有堆句柄
		我们可以输入如下命��o来查看现有的堆句�?/p>
		
0:000> dd 0x77498500  
77498500  00300000 00010000 00020000 002e0000
77498510  002c0000 00000000 00000000 00000000
77498520  00000000 00000000 00000000 00000000
77498530  00000000 00000000 00000000 00000000
77498540  00000000 77498340 7749bb08 77498220
77498550  00000000 00000000 00000000 00000000
77498560  77498220 00317bd0 00000000 00000000
77498570  00000000 00000000 00000000 00000000

		可以看得到这里面的内容和!heap命��o的输出结果是一��L��
		而堆句柄的存放范�?从MaximumNumberOfHeaps 上来�?���是77498500-77498540�q?x40个字节，因�ؓ每个堆句柄占4个字节，0x10个堆句柄的存攄���间就�?x40�?/p>
		HEAP的组�l�结�?/h1>
		堆的���理�Q�我们可以理解�ؓ一个内存池�Q�它甌���一大块�I�间�Q�然后负责接���应用程序的甌���释放�{�请求。只有在创徏堆，释放堆（注意�Q�是释放堆，不是堆中的空��_���Q�在�q�之前，我们需要对堆有关的数据�l�构做一些解�?/p>
		
我这里观察到的HEAP�l�构�Q�HEAP_SEGMENT�l�构和HEAP_ENTRY�l�构都和软�g调试里面描述的不一��P��当年奎哥写��Y件调试的时候估计还没用上WIN7吧。。。我的演�C�系�l�是WIN7
		HeapCreate函数�q�回的堆句柄其实���是一个指向堆���理�l�构的指针，每个堆都会涉及到�q�样三个�l�构�Q�HEAP,HEAP_SEGMENT,HEAP_ENTRY
		HEAP_ENTRY�l�构�Q?/p>
		
在堆���理中，每一块申请下来的内存都会有下面所�C�的固定模式�Q?/p>
		

				
						
								
										HEAP_ENTRY�Q? bytes�Q?/p>
								
						
						
								
										我们new或malloc分配的空�?/p>
								
						
						
								
										固定填充�I�间
								
						
				
		
		�q�个�l�构用来记录所分配的空间的信息�Q�包括用��L����L���I�间�Q�填充的�I�间�Q�所在的�D�号�{�等信息。所以我们new或者malloc的地址减去8���指向该�l�构。第三部分的固定填充�I�间是�ؓ了内存对齐而生成的�Q�当然这部分�I�间�q�有一部分是用来额外记录这块内存的其它信息�Q�这里就不详�l�做介绍了�?/p>
		
HEAP_SEGMENT�l�构�Q?/p>
		
我们可以�q�么认�ؓ�Q�堆甌���内存的大���是以段为单位的�Q�当新徏一个堆的时候，�pȝ��会默认�ؓ�q�个堆分配一个段�?��h���Q�通过刚开始的new和malloc分配的空间都是在�q�个�D�上分配的，当这个段用完的时候，如果当初创徏堆的时候指明了HEAP_GROWABLE�q�个标志�Q�那么系�l�会�����个堆在再分配一个段�Q�这个时候新分配的段���q���?��h��了，以下以此�c�L��。每个段的开始初便是HEAP_SEGMENT�l�构的首地址�Q�由于这个结构也是申��L��一块内存，所以它前面也会有个HEAP_ENTRY�l�构�Q?/p>
		

				
						
								
										HEAP_ENTRY�Q? bytes�Q?/p>
								
						
						
								
										HEAP_SEGMENT
								
						
						
								
										HEAP_ENTRY�Q? bytes�Q?/p>
								
						
						
								
										我们new或malloc分配的空�?/p>
								
						
						
								
										固定填充�I�间
								
						
				
		
		HEAP_SEGMENT�l�构会记录段的一些基本信息，该段甌���的大���，已经提交内存的大���，�W�一个HEAP_ENTRY�l�构的入口点。（我观察看貌似�D는���L��内存�q�不会一�ơ性全部提交，而是每次提交一个页的大���，比如一个段大小2个页�Q�那么它会先提交一个页内存�Q�若用完了再提交一个页的内存，若内存还用完了那���新��Z��个段�Q�这个新建的�D�也会是先提交一个页内存。）但是0��h��很特别，�q�个�D늚�起始地址���是堆句柄指针指向的��|��也就是说�Q?/font>HeapCreate�q�回的堆句柄��L��指向0��h���Q��ؓ什么呢�Q�因为HEAP�l�构是HEAP_ENTRY,HEAP_SEGMENT的合体加长版~

		HEAP�l�构�Q?/p>
		
HEAP�l�构则是记录了这个堆的信息，�q�个�l�构可以扑ֈ�HEAP_SEGMENT链表入口�Q�空闲内存链表的入口�Q�内存分配粒度等�{�信息。HEAP的首地址便是堆句柄的��|��但是堆句柄的值又�?��h��的首地址也是堆句柄，何解�Q�其实很���单，0��h��的HEAP_SEGMENT���在HEAP�l�构里面�Q�HEAP�l�构�c�d��义如�q�样�Q?/p>
		

				struct _HEAP

{

_HEAP_ENTRY Entry ; //HEAP_ENTRY�l�构�Q�用来描�q�存储HEAP内存块大���等信息�?

_HEAP_SEGMENT Segment ;  //0��h��的首地址

…�? //对于该HEAP的描�q�C���?

} ;

		
		在我们看来，内存�l�织�l�构应该如下所�C�：
		
				
						
								
										HEAP_ENTRY�Q? bytes�Q?/p>
								
						
						
								
										HEAP_SEGMENT
								
						
						
								
										HEAP
								
						
				
		
		更确切的��_��HEAP�l�构中本�w�就包含了HEAP_ENTRY和HEAP_SEGMENT�Q�HEAP_ENTRY�l�构是HEAP的第一个数据成员，HEAP_SEGMENT是它�W�二个数据成员。而对于HEAP_SEGMENT,它的�W�一个数据成员便是HEAP_ENTRY。这里�ؓ了方便理解，才在内存�l�织�l�构中把它们拆开展示。（注：�q�里是win7的情况，和��Y件调试这本书中所描述的有一些差异，也属正常现象�Q�毕竟这部分�l�构微��Y�q�未公开�Q?/p>
		
用WINDBG观察HEAP�l�构
		在之前已�l�演�C�Z��如何从PEB�l�构中找到所有的堆句柄，可以看到002c0000便是我们创徏的句柄。然后我们执�C�Z���E�序的第7行代码。执行完后结果如下：
		0:000> p
eax=002c0000 ebx=00000000 ecx=77429897 edx=77498500 esi=00000001 edi=01033374
eip=01031026 esp=0022fe8c ebp=0022feac iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206
heap!main+0x26:
01031026 ff1500200301    call    dword ptr [heap!_imp__HeapAlloc (01032000)] ds:0023:01032000={ntdll!RtlAllocateHeap (774120b5)}
0:000> p
eax=002c0590 ebx=00000000 ecx=774134b4 edx=002c0180 esi=00000001 edi=01033374
eip=0103102c esp=0022fe98 ebp=0022feac iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
heap!main+0x2c:
0103102c 8945f0          mov     dword ptr [ebp-10h],eax ss:0023:0022fe9c={heap!envp (0103301c)}

		可以看到EAX保存的返回��gؓ002c0590。我们通过两种途径来观察我们申��L��内存�Q�通过!heap命��o观察和通过dt命��o观察
		
		
		通过!heap命��o观察
		
		
		
		
		
		
		输入命��o!heap –a 2c0590得到的结果如下：
		0:000> !heap -a 2c0000
Index   Address  Name      Debugging options enabled
  5:   002c0000 
    Segment at 002c0000 to 002c2000 (00001000 bytes committed)
    Flags:                00001000
    ForceFlags:           00000000
    Granularity:          8 bytes
    Segment Reserve:      00100000
    Segment Commit:       00002000
    DeCommit Block Thres: 00000200
    DeCommit Total Thres: 00002000
    Total Free Size:      0000013a
    Max. Allocation Size: 7ffdefff
    Lock Variable at:     002c0138
    Next TagIndex:        0000
    Maximum TagIndex:     0000
    Tag Entries:          00000000
    PsuedoTag Entries:    00000000
    Virtual Alloc List:   002c00a0
    Uncommitted ranges:   002c0090
            002c1000: 00001000  (4096 bytes)
    FreeList[ 00 ] at 002c00c4: 002c0618 . 002c0618  
        002c0610: 00088 . 009d0 [100] - free
		
				    Segment00 at 002c0000:
        Flags:           00000000
        Base:            002c0000
        First Entry:     002c0588
        Last Entry:      002c2000
        Total Pages:     00000002
        Total UnCommit:  00000001
        Largest UnCommit:00000000
        UnCommitted Ranges: (1)
		
		
				    Heap entries for Segment00 in Heap 002c0000
        002c0000: 00000 . 00588 [101] - busy (587)
        002c0588: 00588 . 00088 [101] - busy (80)
        002c0610: 00088 . 009d0 [100]
        002c0fe0: 009d0 . 00020 [111] - busy (1d)
        002c1000:      00001000      - uncommitted bytes.
		
		�q�个命��o分别提炼��Z��HEAP�Q�绿色区域）,HEAP_SEGMENT�Q�红色区域）和HEAP_ENTRY�Q�灰色区域）�l�构中的信息。虽然在灰色区域中，我们找不�?c0590�Q�但是找��C��一�?c0588�Q�这个正�?c0590-8的结果，也就是说最双���的地址是每个HEAP_ENTRY的首地址�Q�接着00588�q�个字段表示了前面一个HEAP_ENTRY所占用的大���，后面�?088表示�q�个内存块的��d�����，��x��们申��L��内存+HEAP_ENTRY�Q?28+8=0x80+0x8=0x88�Q�，[101]是这块内存的标志位，最双���一位�ؓ1表示该内存块被占用。然后busy�Q?0�Q�就是解释说�q�块内存是被占用的（非空闲的�Q�，它申��L��内存�?x80�Q��{化成十进制正好就是我们申��L��128字节大小�?/p>
		

				但是�q�里用dt _HEAP_ENTRY 2c0588命��o却没办法查看对应的结构信息，真是怪哉�Q�有���博文也提到win2008中HEAP相关�l�构也有变，看来到NT6后，HEAP�l�构变得不小�Q��v码windbg中直接dt HEAP_ENTRY是无法原始数据的了，貌似对HEAP_ENTRY做了�~�码�?/font>
				

		

		通过dt命��o观察
		同样的，已知HEAP的首地址�Q�那么先从HEAP下手好了�Q�dt _HEAP 002c0000可以昄���HEAP的数据结�?/p>
		
ntdll!_HEAP
   +0x000 Entry            : _HEAP_ENTRY
   +0x008 SegmentSignature : 0xffeeffee   
   +0x00c SegmentFlags     : 0
   +0x010 SegmentListEntry : _LIST_ENTRY [ 0x2c00a8 - 0x2c00a8 ]
   +0x018 Heap             : 0x002c0000 _HEAP
   +0x01c BaseAddress      : 0x002c0000 Void
   +0x020 NumberOfPages    : 2
   +0x024 FirstEntry       : 0x002c0588 _HEAP_ENTRY
   +0x028 LastValidEntry   : 0x002c2000 _HEAP_ENTRY
   +0x02c NumberOfUnCommittedPages : 1
   +0x030 NumberOfUnCommittedRanges : 1
   +0x034 SegmentAllocatorBackTraceIndex : 0
   +0x036 Reserved         : 0
   +0x038 UCRSegmentList   : _LIST_ENTRY [ 0x2c0ff0 - 0x2c0ff0 ]
   +0x040 Flags            : 0x1000
   +0x044 ForceFlags       : 0
   +0x048 CompatibilityFlags : 0
   +0x04c EncodeFlagMask   : 0x100000
   +0x050 Encoding         : _HEAP_ENTRY
   +0x058 PointerKey       : 0x17c06e63
   +0x05c Interceptor      : 0
   +0x060 VirtualMemoryThreshold : 0xfe00
   +0x064 Signature        : 0xeeffeeff
   +0x068 SegmentReserve   : 0x100000
   +0x06c SegmentCommit    : 0x2000
   +0x070 DeCommitFreeBlockThreshold : 0x200
   +0x074 DeCommitTotalFreeThreshold : 0x2000
   +0x078 TotalFreeSize    : 0x13a
   +0x07c MaximumAllocationSize : 0x7ffdefff
   +0x080 ProcessHeapsListIndex : 5
   +0x082 HeaderValidateLength : 0x138
   +0x084 HeaderValidateCopy : (null) 
   +0x088 NextAvailableTagIndex : 0
   +0x08a MaximumTagIndex  : 0
   +0x08c TagEntries       : (null) 
   +0x090 UCRList          : _LIST_ENTRY [ 0x2c0fe8 - 0x2c0fe8 ]
   +0x098 AlignRound       : 0xf
   +0x09c AlignMask        : 0xfffffff8
   +0x0a0 VirtualAllocdBlocks : _LIST_ENTRY [ 0x2c00a0 - 0x2c00a0 ]
   +0x0a8 SegmentList      : _LIST_ENTRY [ 0x2c0010 - 0x2c0010 ]
   +0x0b0 AllocatorBackTraceIndex : 0
   +0x0b4 NonDedicatedListLength : 0
   +0x0b8 BlocksIndex      : 0x002c0150 Void
   +0x0bc UCRIndex         : (null) 
   +0x0c0 PseudoTagEntries : (null) 
   +0x0c4 FreeLists        : _LIST_ENTRY [ 0x2c0618 - 0x2c0618 ]
   +0x0cc LockVariable     : 0x002c0138 _HEAP_LOCK
   +0x0d0 CommitRoutine    : 0x17c06e63     long  +17c06e63
   +0x0d4 FrontEndHeap     : (null) 
   +0x0d8 FrontHeapLockCount : 0
   +0x0da FrontEndHeapType : 0 ''
   +0x0dc Counters         : _HEAP_COUNTERS
   +0x130 TuningParameters : _HEAP_TUNING_PARAMETERS
���如本文前面所�q�的�Q�第一个字�D�|��HEAP_ENTRY�l�构�Q�接着应该是HEAP_SEGMENT�Q�这里只不过把HEAP_SEGMENT�l�构的字�D�展开了，可以dt _HEAP_SEGMENT来观察下�q�个�l�构的字�D?/p>
		
0:000> dt _heap_segment
ntdll!_HEAP_SEGMENT
   +0x000 Entry            : _HEAP_ENTRY
   +0x008 SegmentSignature : Uint4B
   +0x00c SegmentFlags     : Uint4B
   +0x010 SegmentListEntry : _LIST_ENTRY
   +0x018 Heap             : Ptr32 _HEAP
   +0x01c BaseAddress      : Ptr32 Void
   +0x020 NumberOfPages    : Uint4B
   +0x024 FirstEntry       : Ptr32 _HEAP_ENTRY
   +0x028 LastValidEntry   : Ptr32 _HEAP_ENTRY
   +0x02c NumberOfUnCommittedPages : Uint4B
   +0x030 NumberOfUnCommittedRanges : Uint4B
   +0x034 SegmentAllocatorBackTraceIndex : Uint2B
   +0x036 Reserved         : Uint2B
   +0x038 UCRSegmentList   : _LIST_ENTRY
		可以看到HEAP�l�构中灰色部分是和HEAP_SEGMENT�l�构中的字段是重复的�Q�也���是说灰色部分字�D�便是HEAP_SEGMENT�l�构。在HEAP_SEGMENT�l�构中，我们可以扑ֈ�FirstEntry字段�Q�这里指的便是我们的分配的内存，不过HEAP_ENTRY�l�构无法观察�Q�这里便没办法枚丑և�所有的HEAP_ENTRY�l�构了，但是说一下思�\�Q?/p>
		
每个HEAP_ENTRY和它对应的内存我们可以称��Z��个内存块�Q�计���下一个内存块需要用到现有内存块中的2个字�D�，Size和UnsedBytes�Q�Size的��g��上粒度（���是0:000> !heap -a 2c0000命��o昄���的信息中的Granularity: 8 bytes字段�Q�这里是8字节�Q�，下一个内存块地址���是 本内存块地址+Size*8+UnsedBytes。当然这里的�_�度可以通过HEAP字段中的AlignMask 字段���出来�?/p>
		

		
		HEAP的分配粒�?/h1>
		在HEAP�l�构中指明了分配�_�度�Q�这个分配粒度是说每�ơ堆分配的时候，都以�q�个�_�度为最���单位，�q�里看到�_�度�?字节。所以这里就有了�W�二�ơ分配内存的实验�Q�我们让�E�序执行�W?行，然后�?heap -a 002c0000观察分配情况
		Heap entries for Segment00 in Heap 002c0000
    002c0000: 00000 . 00588 [101] - busy (587)
    002c0588: 00588 . 00088 [101] - busy (80)
    002c0610: 00088 . 00088 [101] - busy (79)
    002c0698: 00088 . 00948 [100]
    002c0fe0: 00948 . 00020 [111] - busy (1d)
    002c1000:      00001000      - uncommitted bytes.
		
				�q�里可以看出多出了一个占用块�Q�大���是0x79�Q?21�Q?bytes�Q�但是实际分配的大小�q�是0x 88 �Q?28�Q�bytes�Q�这是因为系�l�是�? bytes为粒度分配的�Q�所以�ؓ�q�块121 bytes的内存自动填充了7个字节，可见甌���121 bytes和申�?28 bytes所使用的空间是一��L���?/font>
		

		HEAP的释攑֒�销�?/h1>
		执行�?1行和12行的代码后，堆中的内容分别如下：
		
				执行11行代码的堆情�?/strong>
		

		FreeList[ 00 ] at 002c00c4: 002c06a0 . 002c0590  
    002c0588: 00588 . 00088 [100] �?free   �Q�空闲列表中多出了一块内�?/font>
    002c0698: 00088 . 00948 [100] �?free   �Q�空闲内存，�I�闲�I�间�?48
Heap entries for Segment00 in Heap 002c0000
002c0000: 00000 . 00588 [101] - busy (587)
002c0588: 00588 . 00088 [100]   �Q�原先的�q�块内存释放掉了
002c0610: 00088 . 00088 [101] - busy (79)
002c0698: 00088 . 00948 [100]    ; �I�闲内存
002c0fe0: 00948 . 00020 [111] - busy (1d)
002c1000: 00001000 - uncommitted bytes. 
执行12行代码的堆情�?/strong>
FreeList[ 00 ] at 005c00c4: 005c0590 . 005c0590  
    005c0588: 00588 . 00a58 [100] �?free �Q�回收了buffer1的内存后�Q�由于由于空闲内存是�q�箋的，所以直接合�q�成一块内存。可以看��C��前内存free�I�间�?48�Q�现在合�q�了以后便是948+88+88=a58,也就是当前内存大��?/font>
Heap entries for Segment00 in Heap 005c0000
    005c0000: 00000 . 00588 [101] - busy (587)
    005c0588: 00588 . 00a58 [100]
    005c0fe0: 00a58 . 00020 [111] - busy (1d)
    005c1000:      00001000      - uncommitted bytes.
最后执�?4行代�?对堆�q�行释放,释放后我们通过!heap也可以看到只�?个堆�?我们甌���的堆被释放了.
0:000> !heap 
Index Address Name Debugging options enabled
1: 00300000 
2: 00010000 
3: 00020000 
4: 002e0000 
 
至于HEAP_ENTRY�l�构的问�?有时间在调试看看是怎么回事吧~另外�Q�这里说明下�Q�new和malloc内部都会调用HeapAlloc来申请内存，但是堆句柄从哪来呢？它会������_crtheap变量是否为空�Q�若不�ؓ�I�则拿_crtheap变量来作�������q��堆句柄去调用HeapAlloc
参考：
软�g调试    张奎�?/p>
MSDN    React OS


__ay 2011-10-30 19:05 发表评论


__ay — Sun, 23 Oct 2011 07:23:00 GMT
@作�? ay @文章出处: cnss-ay的博�?/a> @Notice: 转蝲��h��明出处！若文章显�C�Z��完整�Q�可以到文章出处阅读�?/font>
  
 昨天在京东上买的TP-LINK WN821N v3无线�|�卡�Q�今天就到手�?发货真快~~凌晨�l�我发来邮�g说已送货�Q�注意查收。。。。汗~~
 �q�个无线�|�卡是我的开发网卡，�׃��一下午研究才翻到的一个commview for wifi和aircrack都能使用的网卡，用的atheros的芯片，具体型号可以�?a >http://linuxwireless.org/en/users/Drivers/ath9k_htc/devices�q�个�|�址上查到�?/p> 
可惜我的是ubuntu 10.04的版本，������不到这个网卡，只能自己动手装了
 我这里安装的是ath9k_htc
 多亏了下面这两篇文章�Q�网卡成功在ubuntu上面跑�v来了
 ath9k_htc�Q�一些USB无线�|�卡的原生驱�?/a>
 ath9k_htc USB无线�|�卡驱动安装
 不过上面说貌似在UBUNTU 11.04中就可以识别出来�Q�我也不晓得 �q�个待验证�?/p> 
试了下aircrack
 sudo aircmon start wlan%d �Q�貌似网卡名解析有错。。。。竟然给我解析成wlan%d�Q�不�q�也能用�Q�将���吧~�Q?/p> 
打开wireshark监听mon0�q�个虚拟�|�卡�Q�结果如�?/p> 
 嘿嘿  可以使用�Q�那接下来可以���l�wireless fundamental�p�d��文章了，noctilio�q�个开源项目也开始步入开发阶�D�了


__ay 2011-10-23 15:23 发表评论


__ay — Sat, 22 Oct 2011 16:34:00 GMT
@作�? ay @文章出处: cnss-ay.com @Notice: 转蝲��h��明出�?/font>
 之前写了一���文�? VIM–指定自��q��VIM工作目录
 今天准备把windows下的vim配置弄到虚拟��Z��的ubuntu�?于是���有了这���文�?仅记录下期间遇到的问�?/p> 
 
 1. 把windows文�g�Ҏ�����到ubuntu�?/p> 
我这里是用了vmware tools来搞定的,先安装vmware tools,然后在edit virtual mechine setting中的options里面有个shared floders,把它设�ؓalways enable然后在下面添加自��p���׃�n的目录就是了,我在�q�里面把我之前的$MY_VIM_DIR�q�个环境变量的目录添加进��M��,我的floder name为vim.然后在虚拟机的UBUNTU下面,�?mnt/hgfs/vim目录下就可以讉K��我的vim配置文�g�?�W�一步搞�?没什么大问题.
  
 2.然后在环境变量中��d��$MY_VIM_DIR(/mnt/hgfs/vim)�?VIMINIT(source $MY_VIM_DIR/_vimrc)环境变量,我这里查了下资料,在~/.bashrc�q�个文�g中加上这两句话：
 export MY_VIM_DIR=/mnt/hgfs/vim
 export VIMINIT="source $MY_VIM_DIR/_vimrc"
 在每�ơ启动bash的时候会执行~/.bashrc�q�个文�g�Q�我们的环境变量���p��动设�q�去了，但是�q�个讄���只对当前用户有效�Q�换个用��h��们设�|�的环境变量��׃��起作用了. 如果你希望对全局用户都有�?那么可以��M���?etc/profile文�g,在文件末���֊�上这两句�?
  
 3.好了,一切就�l?在控制台启动VIM, ��p�|! 提示说检���到有^M, 无法解析.�?windows格式�~�码问题....
 解决�Ҏ��很简�?先跑去装个tofrodos,命��o: sudo apt-get install tofrodos
 然后执行sudo fromdos -p $MY_VIM_DIR/*/*.vim
 把配�|�文件目录下的所�?vim文�g的换行都转成unix格式�?/p> 
然后在我们的_vimrc中加入一句话: set fileformat=unix
 告诉vim我们换行�W�用unix格式�?/p> 
在windows�? gvim可以识别�q�种带有unix换行�W�的vimrc文�g
 OK,问题解决
  
 4.执行sudo vim, �?... 竟然没有加蝲我的_vimrc文�g,而是转而加载了默认�?vimrc文�g,也就是说2中设�|�的环境变量不�v作用
 然后惛_��能是sudo用的是root,不会�l�承我这个用��L��环境变量,OK  我在/etc/profile中设�|�环境变量��d��以了�?/p> 
��d��后登�?看效�?/p> 
�?.. �q�是不行
 然后癑ֺ�了一�?原来在sudo命��o��Z��安全性考虑,执行期间会把环境变量reset,然后保留可信的环境变�?比如$PATH�q�种变量
 那么问题扑ֈ����好办了,有几�U�方�?/p> 
a. 使用sudo -s命��o�Q�指出sudo�l�承shell环境变量
 b. 执行visudo命��o, 把Defaults env_reset�Ҏ��Defaults !env_reset�?���止sudo对环境变量重�|�，因�ؓ我是在虚拟机上个人用ubuntu做开�?所以用的这�U�方�?若在多�h�׃�n使用的操作系�l�上,�q�是推荐使用a�Ҏ��安全�?/p>

__ay 2011-10-23 00:34 发表评论


用vim�~�辑moin
__ay — Sat, 22 Oct 2011 16:32:00 GMT
@作�? ay @文章出处: cnss-ay.com @Notice: 转蝲��h��明出�?/font>
  
 最�q�在���试用moin wiki来做协同开发，直接用moin自带的编辑器太不爽了�Q�字体难看不��_���q�没法着�Ԍ��看着不舒服�?/p> 
然后��L��索了下vim中相关moin的插�Ӟ��想不到还真有�Q?/p> 
 
 首先是这�?a >editmoin�Q�用python写的�Q�可以通过�q�个插�g来直接操作moin的页面，但是我这里是windows�pȝ���Q�它老读不到我的配置文�g。这个方法linux下的用户可以用，我就不行咯，所以作�|�，重新��L��其它�Ҏ���?/p> 
 
 然后去moin主页上看�Q�上面推荐了一个firefox的插�Ӟ��可以使用指定�~�辑器来�~�辑��面内容�Q�插件地址在这�Q?a s All Text! 
 �q�款插�g中你指定vim为编辑器���可以了�Q�然后在�~�辑的时候激�z�该插�g卛_���Q�它会帮你把内容复制到vim中，�~�辑完关闭后会把修改应用到网��늼�辑器内，很好用的说~~哈哈
  
 此外�Q�在moin官网上提到的vim插�gmoin.vim可以对moin wiki语法�q�行高亮昄����Q�但是用的时候注意，��h��moin.vim中的 hi clear  �q�一句话注释�?否则vim中配�|�的主题会失�?/p>

__ay 2011-10-23 00:32 发表评论


VIM �?指定自己的VIM工作目录
__ay — Fri, 07 Oct 2011 13:03:00 GMT

 
@Author�Q�ay        @Date�Q?011-10-07    @文章出处�Q?a >http://cnss-ay.com
	
@Notice�Q��{载请注明作者信息！
 
 
在��用vim的过�E�中个，我发现我的vim配置要�{�U�d��windows上很�ȝ���Q�因为我的插件和vim插�g攑֜�vim安装目录下，和vim原配的插件�؜一起了。而且vimrc文�g也被我改的很乱，攑ֈ�windows上面未必能够直接使用。所以就有了�q�篇文章�Q�讨论如何指定的一个自��q��文�g夹，vim从这文�g夹中载入我的插�g和蝲入初始化文�gvimrc�?
 
 
用过vim的都晓得�Q�vim在初始化之处会蝲入vimrc文�g�Q�在windows下这个文件是_vimrc�Q�在linux下是.vimrc�Q�我们可以修改这个文件来定制我们的初始化操作。但是我们必���d��把这个vimrc文�g攑֜�指定的位�|�才可以被vim������到�Q�这些个路径分别�?VIM,$VIMRUNTIME,$HOME�q�三个环境变量下所指的路径。这里有两种�Ҏ���Q?
1 修改$HOME的�\径，把这个环境变量指向我们自己定义的路径�Q?VIM�?VIMRUNTIME指向的�\径可能vim�q�有其它用途，最好别攏V��但是修�?HOME也不是很好，特别是linux下，很多�E�序都是依赖�?HOME环境变量的�?
 
 
2指定$VIMINIT�Q�我是定义了一�?MY_VIM_PATH的环境变量，�q�里面存了我VIM配置文�g和插件的目录地址�Q�然�?VIMINIT中的内容是：
source $MY_VIM_PATH/_vimrc
在vim初始化之初会查看$VIMINIT有没有被定义�Q�若被定义了���放弃后面蝲入vimrc的操作，转而执�?VIMINIT变量内的操作。当然也可以讄���$MYVIMRC的环境变量�ؓ$MY_VIM_PATH/_vimrc�Q�vim同样会先载入$MYVIMRC变量中指定的vimrc文�g。只有当�q�两个环境变量都没定义的时候vim才回��d��下的目录中找vimrc文�g�?
注：在windows中没法创�?vimrc的文�Ӟ��所以只能用_vimrc代替之�?
 
 
关于如何讄���插�g�Q�帮助文档的查找路径
在vimrc中加入如下语句即�?
set runtimepath=$MY_VIM_PATH,$VIMRUNTIME
在vim�q�行�Ӟ��会在runtimepath变量中记录的路径中去扑֊�载插�Ӟ��背景色等内容�?
 
 
 
 

 

 

			 


文章来源�Q?a href=http://cnss-ay.com/?p=43>http://cnss-ay.com/?p=43


__ay 2011-10-07 21:03 发表评论

国产欧美精品在线,国产亚洲精品久久久久动,国产农村妇女精品一区二区

让xp加蝲指定的内核版�?-别以为xp加蝲的内核��L��来自于ntoskrnl.exe!!!

完全��堆�Q�full page heap�Q?/h1>

�C�Z��

�l�构详解

�Q�摘自MSDN�Q?/font>

优缺�?/h2>

�~�点�Q�消耗大量虚拟内存，每块内存的分配粒度是2个页�Q?K�Q�，

优点�Q�能够立��x��莯���界读写操作，通过调用栈就可以�q�溯到问题源头。能够快速定位问题代码�?/h3>

WINDBG的堆调试--了解HEAP�l�织

用WINDBG观察HEAP�l�构

通过!heap命��o观察

通过dt命��o观察

用vim�~�辑moin

VIM �?指定自己的VIM工作目录

优点�Q�能够立��x��莯��界读写操作，通过调用栈就可以�q�溯到问题源头。能够快速定位问题代码�?/h3>