logo标签列表

DllMain何时以DLL_PROCESS_VERIFIER标志被调用？

c++windowswinapidlldllmain
3
在Windows系统中，标准的DLL入口点被称为DllMain。第二个参数是DWORD类型，即ul_reason_for_call。
我已经在MSDN上查找了该参数可能的取值。以下是显而易见的取值：
DLL_PROCESS_ATTACH:
DLL_THREAD_ATTACH:
DLL_THREAD_DETACH:
DLL_PROCESS_DETACH:

但是还有一个问题：

DLL_PROCESS_VERIFIER

这个标志什么时候会在入口点被调用？在 DLL 的正常操作期间，我需要担心它吗？

请注意，我只在 Visual Studio 2005 的头文件中看到了 DLL_PROCESS_VERIFIER，而没有在 2008 中看到。

3个回答
5

我猜微软理论上可以随时发明新的用法和标志。因此，简单的规则是确保您的代码容忍意外值：即编写处理您需要处理的情况并忽略其余情况的代码，通过返回零来实现。

同意。目前我的代码是 { case DLL_PROCESS_VERIFIER: default: return 0; } 然而我的问题与何时/为什么会发生这种情况有关。 - Konrad
普遍的共识似乎是它可能是由于在被应用程序验证器测量的进程中调用dlls而发送的。我确定这是Visual Studio的一部分，所以应该“容易”放置某种日志代码，并测试是否存在。在正常操作期间？显然从未。 - Chris Becke
1
我建议不要在你的switch语句中明确提及它，@Whyam。这会给人以错误的印象，认为你已经考虑过程序如何处理该值，但显然你不可能知道它的用途。通过将其包含在代码中，你邀请了未来维护者询问它的用途，这将浪费你和他们的时间。最好假装它根本不存在。 - Rob Kennedy
1
这真的很模糊。它甚至没有在SDK中记录，也没有出现在SDK头文件中。谷歌只有少数几个搜索结果，大多数网站都无法访问或不可信。我唯一得到的好结果是XBox代码，它只声明了它但实际上并没有使用它。
我并不完全相信这是一个常规Windows程序中会遇到的真实代码。
+1 个 MSDN 链接。我之前并没有看到它，因为我只是在谷歌上搜索 'DLL_PROCESS_VERIFIER'。我找到它的唯一原因是我在头文件中瞎探索。 - Konrad
它不会传递给普通的DLL，只会传递给在“VerifierDlls”注册表条目中特别列出的DLL。请参见https://skanthak.homepage.t-online.de/verifier.html。 - Ben Voigt
0
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接