近日公司产品要开始版本重构（做为一个程序员老鸟来说最怕重构，不要问为什么），涉及到一个DLL注入的问题。因是安全类产品，DLL会注入到每一个进程，重构时又希望产品内所有程序都使用一个基础库DLL，因原来用来注入的DLL比较独立，自己内部有一套工具类函数，这次要求直接引用新的基础库DLL，如果可以，就意味着注入到每个进程的不是一个DLL，是两个DLL了。据说之前曾经试验过说有问题，但因时间久远或斯人已弃坑，大家都忘了什么问题了，就要重新再试一下，懂行的朋友可以留言讲讲会有什么问题。

讲下我试验的过程和结果：

在原用来注入的DLL中引入新的基础库。这个简单，工程中加入新的基础库DLL，代码中引用新的DLL函数即可，编译完后，可用工具查看一下是否引用到了新的基础库DLL在安装目录中替换用来注入的DLL，观察运行情况。实际运行中发现因程序流程中会拉起svchost.exe 运行一些服务，但svchost.exe一运行就退出了。windbg调试svchost.exe。windbg附加到svhost.exe的父进程中，命令栏输入.childdbg 1监控子进程运行。svchost.exe加载时会产生断点。这时sxeld dll2inject.dll断到被注入dll加载处。windbg中打开反汇编窗，一直Shift F11直到LdrpLoadDllInternal结束。这时查看返回值rax=C0000135

返回C0000135

查询C0000135的意义是：STATUS_DLL_NOT_FOUND。这时很容易想到是找不到新引入的DLL。为什么呢，这个涉及到windows加载DLL的顺序，优先从应用程序目录下查找DLL，再从Windows系统目录下查找DLL。而新引入的DLL和被注入的DLL在产品的安装目录下，其它应用程序自然是找不到的。实验中把新引入的DLL放到系统目录下就可以了。

如果是一个经验丰富或经常做DLL注入的同学应该一下子就知道被注入DLL中引入另一个非系统DLL会有什么问题，也就不用费劲做一些试验了。所以过往经验还是能节省成本和时间的。