会不会是这个原因,就是HeapCreate的时候，第三个dwMaximumSize为0，所以heap能自动扩展，然后真正扩展的时候，按msdn的说法需求比0x7FFF8大，则系统实际会调用VirtualAlloc来分配，这个就能一部分解释了7e031000为reserved了

我用userdump抓了一个进程的内存，然后用windbg打开看heap的问题，发现一个比较奇怪的地方，如下 !heap 002a0000 -hf Heap entries for Segment19 in Heap 002a0000        7e030000: 00000 . 00040 [01] - busy (40)        7e030040: 00040 . 00fc0 [10]        ...

先谢谢。 现在是我自己实验室模拟不出来,但现场却不能上参数,也不能重启，即无法使用UMDH工具来分析，我只好在现场用vmmap和userdump抓了进程内存回来分析。 我现在已经基本不用担心它是内存泄露，但我非常希望的是大致能看到或者能推测出是哪些线程在这个Heap 上操作，即c++概念上在这这个Heap里new/delete，或者说哪些''引用''了这个heap，这样我就基本有概念。 所以，我现在的困惑在于如何搜索或者发现这个heap segment的相关引用，我不知道该用哪个地址或者哪个数据进行search，如002a0000，还是6B040000，或者其他地址？

来由是这样的，我怀疑目标进程有可能有内存泄露，但不允许调试，我就用vmmap来看进程地址空间，每隔2小时看一次，隔一阵，发现多了一些private空间，如下 6B040000   Private    21,600   44        28         28     22      ...

哦,谢谢,我再弄弄

如下面，其实只有一个IMHelper.exe,但却显示很多 PROCESS f89d3020  SessionId: 0  Cid: e164    Peb: 7ffff000  ParentCid: 076c    DirBase: 557d2000  ObjectTable: 00000000  HandleCount:   0.    Image: IMHelper.exe PROCESS f7b632a0  SessionId: 0  Cid: 01b0    Peb: ...

汗,我错了! 多好的机会啊,只有看明天了! 谢谢二位啊

谢谢! 我当时用了这个工具的以前一个版本打印了的,但没有 我根据代码怀疑是标准输出,是不是这个工具不会有0/1/2那三个文件句柄的输出哦 现在没有环境,明天我再用你给的这个版本尝试下,也许这个版本修复了

我在调试一个进程阻塞的时候，发现它阻塞在WriteFile那里，我用userdump把进程给dump出来，用windbg分析，只能得到handle和buffer等信息，但无法确认是哪个文件。 1、打印堆栈 0:019> kvChildEBP RetAddr  Args to Child              583cb07c 7c827d3b 77e65598 00000120 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])583cb080 77e65598 00000120 ...

谢谢MJ。我还是不明白，子进程并没有显示打开这些handle啊。 我没有说太清楚，我的场景是这样，父进程A创建了子进程B带继承属性，因为希望B能够继承很多东东； 子进程B同时也继承了父进程的socket，也包含了port； 本来如果一切平安也就无事，但不巧父进程A由于某种原因需要重启，而B却不能重启，必须时刻运行；  A重启的时候由于要显示bind端口,而端口已经在B那里，导致端口冲突问题重启不成功； 所以我希望B被创建的时候不要继承那个socket/port，但可以继承其他的handle。