C++内核模式驱动开发错误unresolved external symbol error

重点

开发模式选择错了，就会有很多问题。有时候要选用命令行，有时候可以用VS集成IDE。

翻译

I am working on a project where the code is in .cpp files.. Now I need to call kernel mode APIs like 我正在忙的一个项目的代码在.cpp文件里。现在，我需要调用内核模式API，例如

IOCallDriver,
                IoGetDeviceObjectPointer,
                IoGetNextIrpStackLocation
                KeWaitForSingleObject
                ObReferenceObject                

I have linked to wdm.lib and Ntoskrnl.lib, but still getting following errors 我已经链接到wdm.lib和Ntoskrnl.lib，但是仍然出现以下错误

                unresolved external symbol __imp__KeWaitForSingleObject referenced
                unresolved external symbol __imp__IoBuildDeviceIoControlRequest
                unresolved external symbol __imp__KeInitializeEvent referenced in function _callParport

while no unresolved error is thrown for IOCallDriver or ObReferenceObject. Please let me know why these error and how can I resolve them. 而不会为IOCallDriver或ObReferenceObject引发未解决的错误。请让我知道这些错误的原因以及如何解决。
Observation: Earlier I was getting unresolved external symbol error for all kernel APIs, but inclusion of " extern "c" { #include<wdm.h> }, resolved most of them apart from these 3. Are these symbols not available in wdm.lib or Ntoskrnl.lib 以前也遇到 unresolved external symbol，后来加了extern "c" { #include<wdm.h> }就只有3个错误了。

Posts like this really confuse and concern me. Build your driver just like any other driver using the WDK in C. You don't need to specify any specific or special libraries against which to link. You DO want to include WDM.H or NTDDK.H in an extern C block, as you've done. Likewise, you will want to be sure the name "DriverEntry" is not name-mangled. It should "just work", 这样的帖子确实让我感到困惑和关注。C模式使用WDK开发驱动和别的驱动类似。链接时不需要特别指定库。你只需要包含WDM.H 或 NTDDK.H，以C extern块包含。

You DO want to include WDM.H or NTDDK.H in an extern C block .Actually, not so if you are using the latest RELEASED version of the WDK 您确实希望将WDM.H或NTDDK.H包含在extern C块中。实际上，如果您正在使用最新的WDK RELEASED版本，则不可以。
as wdm.h and ntddk.h already enclose their contents in a conditional extern "C" block. The OP must be using an old version of the WDK. 因为wdm.h和ntddk.h已经将它们的内容包含在一个条件中

Are you sure those libs are on the cmd line? Did you verify it in the log file? 您确定这些库在cmd行上吗？您是否在日志文件中进行了验证？

Yes, those libs are in the command line otherwise I should get unresolved references for all the kernel APIs. I have confirmed this from the logs also. As I have mentioned this file is a part of broader project and we use kbuild command to build win kernel stuff.. 是的，这些库在命令行中，否则我应该获得所有内核API的未解析的引用。我也从日志中确认了这一点。

 As I have mentioned this file is a part of broader project and we use kbuild command to build win kernel stuff.. So file a bug against kbuild. 正如我已经提到的，该文件是更广泛的项目的一部分，我们使用kbuild命令来构建Win内核。

don't know how to use the tools. 不知道如何使用工具。

C:\DDK\7600\lib\wlh\i386>link /dump /linkermember ntoskrnl.lib | grep KeWa
                  5E11A _KeWaitForSingleObject@20
                  5E11A __imp__KeWaitForSingleObject@20
                  5E192 _KeWaitForMutexObject@20
                  5E192 __imp__KeWaitForMutexObject@20
                  5E208 _KeWaitForMultipleObjects@32
                  5E208 __imp__KeWaitForMultipleObjects@32
                  44D _KeWaitForMultipleObjects@32
                  44C _KeWaitForMutexObject@20
                  44B _KeWaitForSingleObject@20
                  44D __imp__KeWaitForMultipleObjects@32
                  44C __imp__KeWaitForMutexObject@20
                  44B __imp__KeWaitForSingleObject@20                  

They are present, but with __stdcall linkage. I perceive that you are "doing your own thing" here, by building in Visual Studio instead of
using the supported process. I suspect you have the default calling convention set to the wrong state. You need /Gz to make __stdcall the default calling convention.它们存在，但是具有__stdcall链接。我认为您是通过在Visual Studio中而不是在支持进程中进行构建来“做自己的事”。我怀疑您让默认调用约定设置为错误状态。您需要/ Gz使__stdcall成为默认调用约定。

Right - so that is a nightmare. What your kbuild project should do is what ddkbuild.bat does, use the toolchain from a supported WDK using the supported tools. If your kbuild project is at all like vbox kbuild project(s), for example, it does nothing of the sort and everything is
broken for everyone except one developer somewhere who has all the right bits with all the right patches. 对-这就是一场噩梦。您的kbuild项目应该做的是ddkbuild.bat的功能，配合使用来自受支持的WDK中的工具toolchain。如果你的kbuild项目只是象vbox kbuid项目，比如这样，它不会有条理 ，有很多雷要爆，除非有开发人员有精力做全部的补丁。