我有一个32位应用程序，我在Windows 7 x64上遇到问题。我正在加载DLL。 LoadLibraryW成功，随后对GetProcAddress的调用失败，错误代码为127（“找不到程序”或类似内容）。
有趣的是，我知道函数是由DLL导出的。我在GetProcAddress电话中没有输错。我可以看到Depends.exe和DllExp.exe的功能。完全相同的应用程序二进制文件从Windows 10 x64上的完全相同的DLL成功加载该函数，但在Windows 7 x64上没有。
更多详情：图书馆为dbghelp.dll，“遗失”功能为MiniDumpWriteDump。
有趣的是：dbghelp.dll提供了API，用于检查加载到流程中的模块以及枚举这些模块导出的函数。所以，首先我为这个有问题的HMODULE取了dbghelp.dll并运行了
auto ptrSymInitialize = (decltype(&SymInitialize))GetProcAddress(hDbgHelpDll, "SymInitialize");
有效，这个功能确实加载了！然后我加载了SymEnumSymbols，编写了枚举器回调，最后运行了以下命令来枚举这个`dbghelp.dll“中的所有函数：
ptrSymEnum(GetCurrentProcess(), 0, "dbghelp*!*", &Enumerator, nullptr);
你知道什么，MiniDumpWriteDump实际上是在那里列出的。去图。
思想？
答案 0 :(得分：2)
我可以看到你的意图是使用MiniDumpWriteDump。我们还在我们的产品中制作小型泵，我是支持此产品的小型泵。
我建议不要使用OS提供的dbghelp.dll。首先，它们往往过时并且不支持您希望拥有的最新minidump功能。其次，它们被证明是相当不可靠的。我相信他们只是缺少太多错误修正。
我发现工作得很好的是从Debugging Tools for Windows包（目前是Windows SDK的一部分）中获取dbghelp.dll并将其与我们的产品一起发送。这样，我可以确定minidumps将具有所有最新功能，并且它可以在所有操作系统上可靠地运行。现在已经有8年了，操作系统从WinXP到Win10，我没有任何问题。
我不确定我用哪个版本的SDK提取当前使用的dbghelp.dll，可能是Win7 SDK。从那时起，我根本就没有理由进行更新。但是，我们在Win7上使用Win1 SDK中的Debugging Tools for Windows包没有任何问题，所以我猜你也可以使用Win10版本。
答案 1 :(得分：1)
这正是我一直在做的事情，而且我没有带来dbgcore.dll
这只是个坏主意。 Microsoft不会努力使操作系统附带的DLL向后兼容。他们没有必要。在它们的实现中，只有接口需要兼容。他们做利用新功能或设计变更来改进实施。
就像你在这里看到的那样MinWin project的副作用。没有合理的猜测结束，如果它现在在Win7机器上运行，那么你很幸运。也许你在没有SP1的Win7机器上没那么幸运，也许在干净的安装中缺少一些minwin胶水DLL，也许minidump本身在某种程度上会受到负面影响。无法预测。
所以永远不要这样做。 Afaik你根本不应该这样做，Win7机器已经有dbghelp.dll可用了。不是100％肯定，它已经太长了，Win7正在迅速变成新的XP。如果您发现有必要，请始终使用可再发行版本。包含在SDK的Windows调试工具中。将其复制到与需要它的EXE相同的文件夹中，这样就不会弄乱机器。