句柄泄露实例分析

http://www.cnblogs.com/Leo_wl/p/5397274.html

在上篇文章.NET对象与Windows句柄（二）：句柄分类和.NET句柄泄露的例子中，我们有一个句柄泄露的

例子。例子中多次创建和Dispose了DataReceiver和DataAnalyzer对象，但由于忘记调用DataAnalyzer的

Stop方法，导致产生句柄泄露。本文假定我们已经发现了泄露现象但还不知道原因，讨论如何在这种情

况下分析问题。

一、发现问题

在程序运行约一个小时以后，通过任务管理器发现句柄数超过5000，线程数也超过1000。对于一段只需

要并行接收和分析数据的简易代码来说，这显然太不正常了，我们可以判断程序已经产生了泄露。

通过任务管理器可以非常方便的查看程序实时的资源占用情况，但无法了解到历史数据和趋势。程序是

一开始就需要分配和使用这么多资源，还是长时间运行的结果？如果是后者，那么是运行过程中平稳持

续的增长，还是在某个时间节点之后的突然增长？弄清楚这些问题是必要的，我们可以借此初步判断出

内存泄露是与用户的特定操作相关，或者与特定时间点上产生的事件相关；是跟程序的初始化有关，还

是跟某些从始至终运行的后台任务相关。

性能监视器可以很直观的显示这一趋势，其中内置了很多有用的计数器，我们可以从图形化界面中观察

这些计数器值的变化规律，了解系统和进程的运行状况。使用Win + R组合键打开“运行”窗口，输入

perfmon打开性能监视器。点击绿色加号按钮打开“添加计数器”对话框，选择Process中的Handle

Count和Thread Count，然后选择LeakExample进程作为实例，添加这两个计数器。

接下来观察这些数值的变化。在这期间，我们像往常一样的使用程序，可以重复进行一些可能造成内存

泄露的操作。在运行过一段时间后，得到了如下的图表。句柄数和线程数在持续的增长，很容易猜测到

跟Timer有关，因为Timer定期触发，并且每次触发都需要使用线程。即便如此，仍然需要确切的定位究

竟是什么对象产生了泄露，因为实际的项目中可能用到的Timer或者后台线程的代码远远不止一两处。

二、分析运行中的进程

首先应该找出5000多个句柄究竟代表什么对象。利用Process Explorer查看该进程，在下方面板中检查

句柄列表，发现有大量的Event句柄和Thread句柄，更进一步的，我们想知道到底有多少Event和Thread

。

在这个列表中难以看出各种句柄的数量。可以按下Ctrl+A组合键，将Process Explorer中的进程列表和

选中进程的句柄列表保存为文本文件，而后利用你所习惯使用的文本查看工具统计其中特定句柄的数量

，我们这里使用Chrome浏览器的搜索功能看到约有4063个Event句柄和1008个Thread句柄。

到这里，我们有一个大致的印象，即泄露的对象是Event和Thread，其中Event占大多数。下一步需要找

出是谁创建出了这些对象，可以使用Windbg跟踪对象的创建。Windbg是非常方便的Windows调试工具，可

以利用强大的SOS扩展命令诊断.NET程序中的各种问题，最新的Windbg（截止2016年4月）可以从MSDN的

Download the WDK, WinDbg, and associated tools页面下载，点击页面上的Get Debugging Tools for

Windows (WinDbg)链接即可。

将Windbg附加到LeakExample.exe进程，而后使用!handle和!htrace命令对进程句柄进行分析。!handle

命令可以列出进程内所有句柄，也可以查看特定句柄的信息，而!htrace显示句柄的堆栈跟踪。我们先使

用!htrace -enable启用句柄跟踪，然后让进程继续运行几分钟时间，再中断程序的执行，用!htrace -

diff查看自上次快照以来新打开的句柄。由于命令输出过长，一些不重要的信息被隐去用省略号代替。

0:482> !htrace -enable

Handle tracing enabled.

Handle tracing information snapshot successfully taken.

0:482> g

(1988.2f3c): Break instruction exception - code 80000003 (first chance)

eax=7fbc0000 ebx=00000000 ecx=00000000 edx=779fd23d esi=00000000 edi=00000000

eip=77993540 esp=5a75ff28 ebp=5a75ff54 iopl=0 nv up ei pl zr na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

ntdll!DbgBreakPoint:

77993540 cc int 3

0:015> !htrace -diff

Handle tracing information snapshot successfully taken.

0x6 new stack traces since the previous snapshot.

Ignoring handles that were already closed...

Outstanding handles opened since the previous snapshot:

--------------------------------------

Handle = 0x00000b68 - OPEN

Thread ID = 0x00002a68, Process ID = 0x00001988

0x779a4b7c: ntdll!ZwCreateThreadEx+0x0000000c

0x75d3bc5d: KERNELBASE!CreateRemoteThreadEx+0x00000161

0x7643281d: KERNEL32!CreateThreadStub+0x00000020

0x6c54b51f: clr!Thread::CreateNewOSThread+0x0000009b

0x6c54b358: clr!Thread::CreateNewThread+0x000000a8

0x6c54b8ad: clr!ThreadpoolMgr::CreateUnimpersonatedThread+0x00000275

0x6c54b9fc: clr!ThreadpoolMgr::MaybeAddWorkingWorker+0x00000129

0x6c53f298: clr!ManagedPerAppDomainTPCount::SetAppDomainRequestsActive+0x0000002f

--------------------------------------

Handle = 0x00000b64 - OPEN

Thread ID = 0x00002a68, Process ID = 0x00001988

0x779a49fc: ntdll!ZwCreateEvent+0x0000000c

0x75d376a0: KERNELBASE!CreateEventExW+0x0000006e

0x75d376f0: KERNELBASE!CreateEventW+0x00000027

0x6c54a106: clr!CLREventBase::CreateManualEvent+0x00000036

0x6c54a84f: clr!Thread::AllocHandles+0x00000064

0x6c54b4f4: clr!Thread::CreateNewOSThread+0x00000074

0x6c54b358: clr!Thread::CreateNewThread+0x000000a8

0x6c54b8ad: clr!ThreadpoolMgr::CreateUnimpersonatedThread+0x00000275

0x6c54b9fc: clr!ThreadpoolMgr::MaybeAddWorkingWorker+0x00000129

0x6c53f298: clr!ManagedPerAppDomainTPCount::SetAppDomainRequestsActive+0x0000002f

0x6ae49bd3: mscorlib_ni+0x00389bd3

0x6adcd38c: mscorlib_ni+0x0030d38c

--------------------------------------

Handle = 0x00000b60 - OPEN

Thread ID = 0x00002a68, Process ID = 0x00001988

0x779a49fc: ntdll!ZwCreateEvent+0x0000000c

… …

--------------------------------------

Handle = 0x00000b70 - OPEN

Thread ID = 0x00002a68, Process ID = 0x00001988

0x779a49fc: ntdll!ZwCreateEvent+0x0000000c

… …

--------------------------------------

Handle = 0x00000b54 - OPEN

Thread ID = 0x00002a68, Process ID = 0x00001988

0x779a49fc: ntdll!ZwCreateEvent+0x0000000c

… …

--------------------------------------

Handle = 0x00000b50 - OPEN

Thread ID = 0x000011f8, Process ID = 0x00001988

0x779a49fc: ntdll!ZwCreateEvent+0x0000000c

… …

--------------------------------------

Displayed 0x6 stack traces for outstanding handles opened since the previous snapshot.

可以看到，在两次!htrace命令之间有6个handle被打开，由调用堆栈可知其中有1个Thread对象和5个

Event对象，并且在第1个Thread对象之后的4个Event都属于该线程。如果重复!htrace -diff多次，可以

发现一个规律，即每个Thread对象被创建之后，紧接着就会有4个Event对象在同一线程中被打开，说明

在本例中泄露的根源在于Thread对象，这也解释了为什么Event句柄数大致是Thread的4倍。实际上每个

线程在创建的时候的确会创建4个Manual Event，从上面句柄打开时的调用堆栈也能看出，clr!

Thread::CreateNewOSThread方法除了创建Thread对象，也会创建几个Manual Reset Event用于控制线程

的挂起和恢复。

查看Event和Thread句柄的详细信息，下面的输出显示了Thread句柄所指向的线程Id，以及其后的Event

句柄信息。

0:015> !handle 0x00000b68 f

Handle b68

Type Thread

Attributes 0

GrantedAccess 0x1fffff:

Delete,ReadControl,WriteDac,WriteOwner,Synch

Terminate,Suspend,Alert,GetContext,SetContext,SetInfo,QueryInfo,SetToken,Impersonate,Direct

Impersonate

HandleCount 4

PointerCount 6

Name <none>

Object Specific Information

Thread Id 1988.261c

Priority 10

Base Priority 0

Start Address 6c54a086 clr!Thread::intermediateThreadProc

0:015> !handle 0x00000b64 f

Handle b64

Type Event

Attributes 0

GrantedAccess 0x1f0003:

Delete,ReadControl,WriteDac,WriteOwner,Synch

QueryState,ModifyState

HandleCount 2

PointerCount 3

Name <none>

Object Specific Information

Event Type Manual Reset

Event is Set

接下来查看这个新启动的线程在执行什么代码，这个信息将帮助我们找到是哪里的代码创建了该线程。

我们需要加载SOS扩展，并利用上面输出的Thread Id信息。

0:015> .loadby sos clr

0:015> !threads

ThreadCount: 323

UnstartedThread: 0

BackgroundThread: 266

PendingThread: 0

DeadThread: 56

Hosted Runtime: no
Lock

ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt

Exception

0 1 fb8 005015e8 26020 Preemptive 4EEC2A44:00000000 004f9540 0 STA

2 2 a20 0050e080 2b220 Preemptive 00000000:00000000 004f9540 0 MTA

(Finalizer)

8 5 14cc 00553c48 102a220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

284 280 f34 1178fa50 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

286 283 1ff4 117bd278 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

761 764 229c 24cfc070 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

849 865 1bc8 490eb860 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

XXXX 868 0 490e82f0 1039820 Preemptive 00000000:00000000 004f9540 0 Ukn

(Threadpool Worker)

900 900 1054 490edd58 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

898 901 654 490d9370 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

903 903 828 490d9e00 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

XXXX 904 0 490ead30 1039820 Preemptive 00000000:00000000 004f9540 0 Ukn

(Threadpool Worker)

XXXX 1004 0 11758b70 1039820 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

10 1005 2844 117590b8 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

7 1006 314 11759600 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

… …

316 804 2164 0054f960 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

318 803 1758 24a3e810 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

317 802 27bc 116e1540 3029220 Preemptive 00000000:00000000 004f9540 0 MTA

(Threadpool Worker)

5 801 261c 117152d0 3029220 Preemptive 4EEC0C44:00000000 004f9540 0 MTA

(Threadpool Worker)

0:015> ~5s

eax=00000000 ebx=00000258 ecx=00000001 edx=4fa6bc17 esi=0465ee48 edi=00000000

eip=779a64f4 esp=0465ee04 ebp=0465ee6c iopl=0 nv up ei pl nz na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206

ntdll!KiFastSystemCallRet:

779a64f4 c3 ret

0:005> !clrstack

OS Thread Id: 0x261c (5)

Child SP IP Call Site

0465eef4 779a64f4 [HelperMethodFrame: 0465eef4] System.Threading.Thread.SleepInternal

(Int32)

0465ef68 6ad83365 System.Threading.Thread.Sleep(Int32)

0465ef6c 001d04cd LeakExample.DataAnalyzer.DoAnalyze(System.Object) [D: \TimerLeak

\TimerLeak\Form1.cs @ 88]

0465ef7c 6adede48 System.Threading.TimerQueueTimer.CallCallbackInContext(System.Object)

0465ef80 6adc2367 System.Threading.ExecutionContext.RunInternal(… …)

0465efec 6adc22a6 System.Threading.ExecutionContext.Run(… …)

0465f000 6adedd91 System.Threading.TimerQueueTimer.CallCallback()

0465f034 6adedc4c System.Threading.TimerQueueTimer.Fire()

0465f074 6ade11a5 System.Threading.TimerQueue.FireQueuedTimerCompletion(System.Object)

0465f078 6adcdd34

System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWork

Item()

0465f08c 6adcd509 System.Threading.ThreadPoolWorkQueue.Dispatch()

0465f0dc 6adcd3a5 System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

0465f300 6c432652 [DebuggerU2MCatchHandlerFrame: 0465f300]

从调用堆栈可以看出，新线程是由Timer触发的，回调函数是DoAnalyze，参照上篇文章中的代码，得知

它就是DataAnalyzer中的analyzeTimer。这本身没有什么问题，但是检查多个线程的调用堆栈，重复以

上的步骤进行多次分析后，发现所有新增的线程都是由这个timer触发的。Timer本身被设置为每秒触发

一次，而每次触发的执行时间都小于一秒。出现大量的线程，说明timer对象本身产生了泄露，即进程中

有大量的timer实例在运行，而程序设计的本意是进程中只存在一个analyzeTimer。到这里问题已经比较

明显了，往往已经可以从代码审查中找出问题，即analyzeTimer没有被Dispose。

三、小结

针对有句柄泄露的程序，本文描述了一种分析的思路。分析的对象是运行中的进程，因此这是一种动态

分析，即我们可以在它运行的过程中，反复的重现问题，而后观察新的泄露情况。实际的项目中，这个

过程是寻找问题复现关键点的过程，也是反复猜测和证实，以及发现新线索的过程。可以进行动态分析

实际上是比较幸运的，因为另一些情况下，问题发生之后很难再次重现，或者现场环境不允许我们进行

反复的尝试。这时我们需要快速的搜集环境数据，并打好内存转储Dump文件，事后进行静态分析。下一

篇文章，我们仍然用这个例子，探讨如何进行Dump分析，并讨论一点Timer的实现细节。
========

句柄泄露的问题

http://bbs.csdn.net/topics/380196549
写了一个ocx,方在IE上下载远程的图片然后用GDI+显示出来，发现长跑一天后句柄增加了2000多，有的

机器没增加，有的2天增量到了1万，用Process Explorer看了一下，GDI句柄和用户句柄是保持不变的

，没有增加，不知道那些句柄是哪来的？

有工具查看socket句柄吗？使用的方法时开了多个线程，在线程里使用调用download_my进行下载,

CHttpConnection，CHttpFile进行下载的，用完也close()了，如下,会有问题吗？每个线程都是共用

的一个线程函数，这个函数要加锁吗？

UINT download_my(const CString& strFileURLInServer, //待下载文件的URL
char *pBuf)//存放到本地的路径
{
char *pszBuffer = pBuf;
ASSERT(strFileURLInServer != "");
CInternetSession session;
CHttpConnection* pHttpConnection = NULL;
CHttpFile* pHttpFile = NULL;
CString strServer, strObject;
INTERNET_PORT wPort;
DWORD dwType;
UINT nRead;
//int nTimeOut = 10;
//session.SetOption(INTERNET_OPTION_CONNECT_TIMEOUT, nTimeOut); //重试之间的等待延时
session.SetOption(INTERNET_OPTION_CONNECT_RETRIES, 1); //重试次数
try
{
AfxParseURL(strFileURLInServer, dwType, strServer, strObject, wPort);
pHttpConnection = session.GetHttpConnection(strServer, wPort);
pHttpFile = pHttpConnection->OpenRequest(CHttpConnection::HTTP_VERB_GET, strObject);
try{
int res = FALSE;
res = pHttpFile->SendRequest();
if( res == FALSE)
return false;

}catch(CInternetException *p)
{
p->Delete();
if(pHttpFile)
{
pHttpFile->Close();
delete pHttpFile;
pHttpFile = NULL;
}

if(pHttpConnection)
{
pHttpConnection->Close();
delete pHttpConnection;
pHttpConnection = NULL;
}
session.Close();
return false;
}
DWORD dwStateCode;
pHttpFile->QueryInfoStatusCode(dwStateCode);
if(dwStateCode == HTTP_STATUS_OK)
{
char szInfoBuffer[MAXRETURNMESSAGESTRLEN]; //返回消息

DWORD dwInfoBufferSize = sizeof(szInfoBuffer);
BOOL bResult = FALSE;
bResult = pHttpFile->QueryInfo(HTTP_QUERY_CONTENT_LENGTH,
(void*)szInfoBuffer, &dwInfoBufferSize, NULL);
if(bResult == FALSE)
{
return -1;
}
nRead = pHttpFile->Read(pszBuffer, BUFFER_LENGTH); //读取服务器上数据

}
else
{

if(pHttpFile != NULL)
{
pHttpFile->Close();
delete pHttpFile;
pHttpFile = NULL;
}
if(pHttpConnection != NULL)
{
pHttpConnection->Close();
delete pHttpConnection;
pHttpConnection = NULL;
}
session.Close();
return -1;
}
}
catch(CFileException &e )
{
e.Delete(); //add by yuwenying
if(pHttpFile != NULL)
{
pHttpFile->Close();
delete pHttpFile;
pHttpFile = NULL;
}
if(pHttpConnection != NULL)
{
pHttpConnection->Close();
delete pHttpConnection;
pHttpConnection = NULL;
}
session.Close();
return -1;
}
if(pHttpFile)
{
pHttpFile->Close();
delete pHttpFile;
pHttpFile = NULL;
}
if(pHttpConnection)
{
pHttpConnection->Close();
delete pHttpConnection;
pHttpConnection = NULL;
}
session.Close();
return nRead;
}

最后，那些多出来的句柄是怎么来的。。。

process explorer可以查看有名字的对象的句柄，看一下这些句柄的对象名是什么

GDI对象也就是图像绘制里的句柄没有释放
参照MSDN图像绘制函数例子

一直保持在稳定的数目，没有关系的吧？

GDI数目一直是稳定的，没有增加，没关系的吧。主要是句柄是2000多个，GDI句柄600一直不变，用户句

柄200,剩下的那些是什么句柄，一直在增加

现在的代码看不出来,应该还在你读取图像文件显示那一块

把这个 download_my 函数注释掉，看看句柄还有没有增加，问题定位一下。

一部分一部分的注释来找吧，这个是最笨最有效的方法了

单独测试下载图片时句柄的变化，再测试画图

你这段代码里有很多的return -1;的语句,看看当执行到任何一个return -1;时是否所有该释放的都释放

了,有可能是该释放时未释放就退出了.所以当程序里有多个return时,一定要在return 前把所有该释放

的都释放了再退出,不然就会出问题

可以用boundschecker这个工具辅助调试一下，定位问题

try{
int res = FALSE;
res = pHttpFile->SendRequest();
if( res == FALSE)
return false;

这个return false; 前没有释放句柄。其他地方就不知道了。

可以用boundschecker这个工具辅助调试一下，定位问题

最好是用一个出口
如

C/C++ code

BOOL bError = 0;

CHttpFile* pHttpFile = NULL;
//……其它初始化语句

//实体处理段落
if(bError==0)
{
//处理1……………
if(出错1)
{
bError |= 0x0001;
}
}

if(bError==0)
{
//处理2……………
if(出错2)
{
bError |= 0x0002;
}
}

//……其它处理段落

//结尾清理工作
if(pHttpFile != NULL)
{
pHttpFile->Close();
delete pHttpFile;
pHttpFile = NULL;
}
//……其它清理工作

//返回
return XXXXX;

这样结构简单，而且调试也和容易，最后设置个断点就知道出了什么错

最好是用一个出口

C/C++ code
BOOL bError = 0;

CHttpFile* pHttpFile = NULL;
//……其它初始化语句

//实体处理段落
if(bError==0)
{
//处理1……………
if(出错1)
{
bError |= 0x0001;
……

恩，谢谢了，学习，一直是在思考这个问题呢，在多个退出前都要写同样的清理代码，不好看，呵呵

try{
int res = FALSE;
res = pHttpFile->SendRequest();
if( res == FALSE)
return false;

这个return false; 前没有释放句柄。其他地方就不知道了。

多谢了兄弟，我回帖的时候，从来没看的这么仔细过，学习。。
========

句柄泄露

http://blog.csdn.net/maomao171314/article/details/38317159
介绍

欢迎来到这个调试教程系列的第5篇。在这篇文章，我们会介绍Windows中的句柄，什么是句柄以及怎

么调试句柄泄露。在读这篇文章之前，我希望你对前4篇文章掌握的都还不错。这一系列的文章并不是在

重复WinDbg/NTSD的帮助文件，而是介绍实实在在的问题，它们是怎么一回事，以及如何解决它们。

什么是句柄

对于一个程序来说，句柄就是设备，文件，或其它一些系统对象或资源的实例。程序可以通过

CreateFile，RegOpenKey等类似函数来创建一个资源的实例，然后使用这个句柄来进行接下来对这些资

源的操作。

一般来说，你不用关心这个句柄值是多少。那么句柄到底是什么，代表什么？

为了理解的更清晰，我们来看看CreateFile的流程。如果你调试CreateFile，你会注意到它最终会调用

NtCreateFile。

kernel32!CreateFileW+0x34a:

77e7b24c ff150810e677 call dword ptr [kernel32!_imp__NtCreateFile (77e61008)]

0:000> kb

ChildEBP RetAddr Args to Child

0012f728 77e7b4a3 000007c4 80000000 00000000 kernel32!CreateFileW+0x40e

0012f74c 00401ba9 00406760 80000000 00000000 kernel32!CreateFileA+0x2e

NtCreateFile会导致一个内核调用。这个调用是如何实现的要看系统，可能是sysenter或一个软中断int

2eh。不管哪种方法，这个调用都会进入内核，并会被系统分配到对应的驱动。然后，在内核中就会创

建了一个对象来代表这个资源，在这里就是文件。如果你去观察NtCreateFile的参数，你会发现第一个

参数就是将会返回的句柄。我们来看看第一个参数：

eax=0012f730 ebx=00000000 ecx=80100080 edx=00200000 esi=77f58a3e edi=00000000

eip=77e7b24b esp=0012f69c ebp=0012f728 iopl=0 nv up ei ng nz na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000282

kernel32!CreateFileW+0x349:

77e7b24b 50 push eax

0:000>

可以看到，第一个参数是一个地址，就是函数中的一个局部变量。返回后，我们可以检查它的值。

0:000> dd 0012f730

0012f730 000007c4

返回的值是7c4h，并不是程序中指向任何一个地址的指针，更不是内核内存中的指针。为了更深入，有

一个调试器命令可以显示句柄信息，就是!handle。

0:000> !handle 7c4 ff

Handle 7c4

Type File

Attributes 0

GrantedAccess 0x120089:

ReadControl,Synch

Read/List,ReadEA,ReadAttr

HandleCount 2

PointerCount 3

No Object Specific Information available

我们可以看到，这确实是一个文件对象，还显示了它的属性和访问权限。但是我们并不知道这个句柄到

底指向哪个文件，而我们想知道的就是这个信息。我们看不到是有原因的，但在我告诉你原因之前，我

们来看看系统到底干了什么。

句柄值代表什么？

为了给你展示这个东西，我们需要内核调试器。我在另外一台Windows2000的机器上调试过一个进程。

我需要打开记事本，然后需要获得这个进程中的一些句柄。

注意：在Windows XP/2003中，调试器会显示系统的更多信息。比如，对一个线程使用!handle将会显示

线程的入口函数，而Windows2000不会显示。如果你想将一个线程和一个句柄匹配，这将非常有用，特别

是当句柄已经泄露了或线程也不再运行了。教程中我还介绍过dt命令，Windows2000有时候不能正确显示

一些结构(比如系统结构_EPROCESS)。这可能是因为DBGs和PDBs在Windows2000上被处理的方法不同，或

者是信息丢失了。在Windows XP/2003上调试还有更多其他的好处。

因此，我选择了一个文件，并在在CreateFile上下断点。当我选择完这个文件之后，断点触发，然后

我再返回地址上下一个断点。然后，我打印出EAX中的值来看看句柄信息。

0:000> !handle eax ff

Handle 120

Type File

Attributes 0

GrantedAccess 0x120089:

ReadControl,Synch

Read/List,ReadEA,ReadAttr

HandleCount 2

PointerCount 3

这和上面一样，只是显示了它是一个文件。下面我们来看看第一个秘密。这些句柄都是针对特定进程的

。120h这个值只在这个进程空间中有用。如果你在另外一个进程中使用这个句柄值，它可能并不存在，

也可能代表了另外一个不同的对象。这些句柄和窗口句柄不一样，它们的作用范围是进程。

句柄还是内核对象的一个代表，这意味着每个进程在内核中都有一个句柄表，其中每一项都指向内核

的一块内存。这是第二个秘密，也是我为什么要使用内核调试器的原因。现在，我们在内核中中断下来

，并来看看这个句柄值。

在内核调试器中，我们使用!process 0 0，列举所有的进程，然后我们使用!handle命令，语法会有一

些不一样，为了列举正确的句柄，我们需要指定相应的进程。

kd> !process 0 0

**** NT ACTIVE PROCESS DUMP ****

...

PROCESS fcc77200 SessionId: 0 Cid: 0338 Peb: 7ffdf000 ParentCid: 02c8

DirBase: 079de000 ObjectTable: fccc30c8 TableSize: 74.

Image: notepad.exe

kd> !handle 120 ff fcc77200

processor number 0

PROCESS fcc77200 SessionId: 0 Cid: 0338 Peb: 7ffdf000 ParentCid: 02c8

DirBase: 079de000 ObjectTable: fccc30c8 TableSize: 74.

Image: notepad.exe

Handle Table at e1e5f000 with 74 Entries in use

0120: Object: fcd32448 GrantedAccess: 00120089

Object: fcd32448 Type: (fced7c40) File

ObjectHeader: fcd32430

HandleCount: 1 PointerCount: 1

Directory Object: 00000000 Name: \TripItinerary.txt {HarddiskVolume1}

第一个加粗的数字是进程对象，它是内存中的一个结构体，包含了进程中的一些信息。既然句柄是对应

于特定进程的，我们就要告诉!handle它对应于哪个进程。”ff”就是说显示可能的所有信息，帮助文件

中有具体的解释。我总是使用”ff”，因为我需要所有的信息。

第二个加粗的地址是进程中的句柄表，这块内存代表进程中所有的句柄项。可以看到现在有74个句柄

被打开。最后一个加粗的地址是对象的地址，这是所有数据的来源。”Name”属性告诉我们文件名。为

什么我们不能在用户态调试器下得到这些信息呢？

在用户态下显示句柄信息

很明显，这个表是在内核中的，所以你不能直接在用户态下看到。NT系统提供了一些API可以让你得到

这些句柄的信息。如果你看了第3篇文章，我写的那个QuickView:System Explorer就可以完成这样的功

能，并显示其中的一些信息，使用的API是NtQueryObject。

这个API的不足之处就是它可能会使你的进程挂住。这是因为有一些对象是以SYNC的方式打开的。系统

中的管道就是这样的情况，如果你请求它们的信息，你将无限期挂住。为了防止出现这样的情况，调试

器以及我的程序都不会去想请求这样的对象，以防死锁。在我的程序中，我会检查SYNC标志，我还发现

其他一些不会挂起的访问权限。

SysInternals中的HANDLE.EXE工具可以显示所有的信息，那么，它是怎么做到的呢？因为它会使用内

核驱动，并且驱动可以访问所有的内核空间，因此可以直接读内核对象的内存，从而不会使

NtQueryObject死锁。我也在想，在将来的QuickView版本中增加一个驱动，从而不会死锁，并显示更加

具体的信息。

多个句柄

在上面的例子中，我打开了\TripItinerary.txt文件。那么我在另外一个记事本中再打开它会怎么样

呢？我们来看看会发生什么。

在用户态调试器中可以看到：

0:000> !handle eax ff

Handle 58

Type File

Attributes 0

GrantedAccess 0x120089:

ReadControl,Synch

Read/List,ReadEA,ReadAttr

HandleCount 2

PointerCount 3

在内核调试器中，列举句柄：

kd> !handle 58 ff fcd8ace0

processor number 0

PROCESS fcd8ace0 SessionId: 0 Cid: 0258 Peb: 7ffdf000 ParentCid: 0198

DirBase: 04b19000 ObjectTable: fccc9648 TableSize: 22.

Image: notepad.exe

Handle Table at e1e89000 with 22 Entries in use

0058: Object: fcce7028 GrantedAccess: 00120089

Object: fcce7028 Type: (fced7c40) File

ObjectHeader: fcce7010

HandleCount: 1 PointerCount: 1

Directory Object: 00000000 Name: \TripItinerary.txt {HarddiskVolume1}

我们还可以在原来那个记事本中列举句柄：

kd> !handle 120 ff fcc77200

processor number 0

PROCESS fcc77200 SessionId: 0 Cid: 0338 Peb: 7ffdf000 ParentCid: 02c8

DirBase: 079de000 ObjectTable: fccc30c8 TableSize: 74.

Image: notepad.exe

Handle Table at e1e5f000 with 74 Entries in use

0120: Object: fcd32448 GrantedAccess: 00120089

Object: fcd32448 Type: (fced7c40) File

ObjectHeader: fcd32430

HandleCount: 1 PointerCount: 1

Directory Object: 00000000 Name: \TripItinerary.txt {HarddiskVolume1}

在这个例子中，我们可以看到它们不仅有各自的句柄，还有各自的内核对象。但并不总是这样的。有时

候内核对象能在不同进程之间共享。如果同一个进程打开了文件，一般来说它们会得到两个句柄，但是

指向同一个内核对象。你可以使用我的工具或HANDLE.EXE来显示句柄信息，并将他们分类排列，这会让

你学习到更多关于句柄的知识。

为什么用户态调试器显示的HandleCount是2，而PointerCount是3？

你会看到，在用户态调试器下显示句柄信息，”HandleCount”是2，而”PointerCount”是3。这是因

为当显示信息的时候，我们需要作一些变动。调试器为了得到信息，会使用DuplicateHandle复制一个句

柄。这个复制会将HandleCount加1，PointerCount加2。

我们来看看上面那个ObjectHeader:”fcd32430”。

kd> !handle 120 ff fcc77200

processor number 0

PROCESS fcc77200 SessionId: 0 Cid: 0338 Peb: 7ffdf000 ParentCid: 02c8

DirBase: 079de000 ObjectTable: fccc30c8 TableSize: 74.

Image: notepad.exe

Handle Table at e1e5f000 with 74 Entries in use

0120: Object: fcd32448 GrantedAccess: 00120089

Object: fcd32448 Type: (fced7c40) File

ObjectHeader: fcd32430

HandleCount: 1 PointerCount: 1

Directory Object: 00000000 Name: \TripItinerary.txt {HarddiskVolume1}

kd> dd fcd32430

fcd32430 00000001 00000001 fced7c40 00000800

fcd32440 fcce5fc8 00000000 00700005 fceccbd0

fcd32450 fcecc248 e1e730d8 e1e73250 fcc790b4

fcd32460 00000000 00000000 00000000 00010000

fcd32470 00010100 00040042 00380024 e1bf2568

fcd32480 00000000 00000000 00000000 00000000

fcd32490 00000000 00040001 00000000 fcd3249c

fcd324a0 fcd3249c 00040000 00000001 fcd324ac

kd> ba r1 fcd32430

kd> ba r1 fcd32434

kd> g

我们可以看到，handle count是1，pointer count是1。然后我使用”ba r1”在handle count和pointer

count的地址上下断点。BA的意思就是当地址被访问是就断下。R表示它是读还是写。R1中的1表示1字节

。

然后我们使用g命令让其运行。而后我会在用户态调试器下使用”!handle 120 ff”，这将会使用户态

调试器访问这个对象。我们来看看这个指针是在什么时候增长的。

kd> kb

ChildEBP RetAddr Args to Child

fb66ebf0 8049ff0d 00000120 00000000 00000000 nt!ObReferenceObjectByHandle+0x1af

fb66ed40 80461691 00000074 00000120 ffffffff nt!NtDuplicateObject+0x12d

fb66ed40 77f83f85 00000074 00000120 ffffffff nt!KiSystemService+0xc4

0006ef28 00000000 00000000 00000000 00000000 ntdll!NtDuplicateObject+0xb

我们可以看到，第一个函数是ObReferenceObjectByHandle。这会增加指针的引用计数。我们来看看。

kd> !handle 120 ff fcc77200

processor number 0

PROCESS fcc77200 SessionId: 0 Cid: 0338 Peb: 7ffdf000 ParentCid: 02c8

DirBase: 079de000 ObjectTable: fccc30c8 TableSize: 74.

Image: notepad.exe

Handle Table at e1e5f000 with 74 Entries in use

0120: Object: fcd32448 GrantedAccess: 00120089

Object: fcd32448 Type: (fced7c40) File

ObjectHeader: fcd32430

HandleCount: 1 PointerCount: 2

Directory Object: 00000000 Name: \TripItinerary.txt {HarddiskVolume1}

我们看到pointer count已经增加到2了，我们看看下面会发生什么。

kd> kb

ChildEBP RetAddr Args to Child

fb66ebec 8049fffb 00000002 fcc77800 fcd32448 nt!ObpIncrementHandleCount+0x236

fb66ed40 80461691 00000074 00000120 ffffffff nt!NtDuplicateObject+0x3c3

fb66ed40 77f83f85 00000074 00000120 ffffffff nt!KiSystemService+0xc4

0006eed0 77e846ed 00000074 00000120 ffffffff ntdll!NtDuplicateObject+0xb

0006ef28 69b22188 00000074 00000120 ffffffff KERNEL32!DuplicateHandle+0xd4

0006f454 69b2252e 00000074 00000120 000000ff ntsdexts!GetHandleInfo+0x29

0006f4d0 0100d562 00000074 00000050 01001dec ntsdexts!handle+0x10f

0006f52c 0100e497 00233848 0006f54c 0006f553 ntsd!CallExtension+0x77

0006f65c 0100c2bb 01089c81 010241d8 01089138 ntsd!fnBangCmd+0x377

0006f868 0100be0f 80000003 00000001 0006fc2c ntsd!ProcessCommands+0x2ac

0006fab4 01008406 00000000 00000000 ffffffff ntsd!ProcessStateChange+0x687

0006fc2c 01008a14 0006fc4c 00000000 00000000 ntsd!DebugEventHandler+0x6a5

0006fca8 010076dc 00000000 00000000 7ffdf000 ntsd!NtsdExecution+0x13b

0006ff70 010226bf 00000002 002337b0 00232978 ntsd!main+0x3d7

0006ffc0 77e87903 00000000 00000000 7ffdf000 ntsd!mainCRTStartup+0xff

0006fff0 00000000 010225c0 00000000 000000c8 KERNEL32!BaseProcessStart+0x3d

kd> !handle 120 ff fcc77200

processor number 0

PROCESS fcc77200 SessionId: 0 Cid: 0338 Peb: 7ffdf000 ParentCid: 02c8

DirBase: 079de000 ObjectTable: fccc30c8 TableSize: 74.

Image: notepad.exe

Handle Table at e1e5f000 with 74 Entries in use

0120: Object: fcd32448 GrantedAccess: 00120089

Object: fcd32448 Type: (fced7c40) File

ObjectHeader: fcd32430

HandleCount: 2 PointerCount: 2

Directory Object: 00000000 Name: \TripItinerary.txt {HarddiskVolume1}

我们可以看到会调用ObpIncrementHandleCount，并且handle count现在也是2了。注意到，这两个调用

都来自于NtDuplicateObject，也就是用户态下的DuplicateHandle。因此，复制对象会增加这块内核内

存的引用计数，并增加句柄数量，这就是两个进程使用同一个内核对象的一个例子。那么第3个指针引用

是从哪来的？

kd> kb

ChildEBP RetAddr Args to Child

fb66ec68 804baed8 00000100 00000000 00000000 nt!ObReferenceObjectByHandle+0x1af

fb66ed48 80461691 00000100 00000002 0006ef4c nt!NtQueryObject+0xc1

fb66ed48 77f8c4e1 00000100 00000002 0006ef4c nt!KiSystemService+0xc4

0006ef24 69b22203 00000100 00000002 0006ef4c ntdll!NtQueryObject+0xb

0006f454 69b2252e 00000000 00000120 000000ff ntsdexts!GetHandleInfo+0xa4