继续跟踪了一下，发现EXE/DLL的差别出在这里： 0:000> kb ChildEBP RetAddr Args to Child 0012f984 7c916071 00153598 0012fa10 0012ff38 ntdll!LdrpMapDll+0x551 0012fc44 7c9162da 00000000 00153598 0012ff38 ntdll!LdrpLoadDll+0x1e9 0012feec 7c801bb9 00153598 0012ff38 0012ff18 ntdll!LdrLoadDll+0x230 0012ff54 7c80ae5c 004020f4 00000000 00000000 ...

上次开了个贴“请教一个.Net程序中PInvoke的问题”问了一个我遇到的奇怪现象。问题描述有点乱，所以重开一贴讲一下我的跟踪结果。 把问题简化一下：我发现LoadLibrary()对待DLL和EXE有不同的行为：加载EXE时不处理Base relocation。如果EXE输出的函数再调用其他函数，一定会出问题。因为CALL指令里的地址没有被重定位。 VC默认是不为EXE产生重定位表的，因为一般EXE都能加载到默认基址。强制产生重定位表的方法是在连接选项里添加“/FIXED:NO”。但即使建立了重定位表，LoadLibrary()仍然不为EXE处理重定位。所有CALL/JMP指令里的地址还是保持原状。 跟踪了一下LoadLibraryW()。环境：XP SP2, ...

依稀记得VC编译的EXE默认是不带重定位表的 这个应该就是原因吧 刚才做了个实验，跟.Net无关。 两个exe都是native的也一样。 等我想明白了再更新

嗯，我有空就去跟一下，今天活有点忙。 刚才刚收到代码 他是这么调的 这种调用走LoadLibrary()吗？ 我如果在托管进程里下LoadLibrary()的断点能拦下来吗？ [DllImport(''A.exe'', CharSet = CharSet.Unicode, CallingConvention = CallingConvention.Cdecl, SetLastError=true)] private static extern UInt16 B(string msgText); public static UInt16 ShowHelp(string msgText) { ...

我不太了解.Net的程序 那个写.Net的同事跟我说，他也是用LoadLibrary的方式把A.exe load到进程空间的。

老雷 终于等到回复了^_^ 只有一个进程，就是那个.Net程序 它把native exe （A.exe）当作dll load起来 然后调用了A.exe的输出函数B()。 我不理解的是，为什么A.exe被load到进程空间之后，没有进行重定位。 A的IAT表里全是初始值，并没有被重定位到进程中相应模块的输出函数去。 按理说，exe或者dll应该没什么区别。 当然普通exe应该不输出函数，B()是程序员特意输出的。

今天帮同事调试一个.Net程序，结果发现一个很奇怪的问题： 同事的.Net程序通过PInvoke调用一个native exe模块（A.exe）中的函数B()。（类似于调用Dll中的函数，我不懂.Net，不知道这么描述对吗） 运行的时候发生AV。 跟踪发现B()又调用了另一个native ...

哦，原来如此 是我搞错了，谢谢老雷指点 希望快点得到删减的内容 ^_^

学习了

使用的是同一个CRT堆。 CRT堆是在EXE启动的时候（main之前）被初始化的。