核心结论 #

直接将用/kernel编译的内核模式静态库链接到用户模式程序完全不可行，必须针对用户模式重新编译核心代码（或拆分代码后编译公共逻辑）。

具体原因 #

• 编译宏与头文件差异：/kernel参数会强制定义_KERNEL_MODE宏，Windows的内核头文件（如ntddk.h、wdm.h）会根据这个宏屏蔽用户模式API，只暴露内核专属的函数、类型和常量。同时，内核代码依赖的是ntoskrnl.exe等内核组件导出的函数，用户模式程序的导入表只能识别kernel32.dll、ntdll.dll等用户态模块，链接阶段就会出现未定义符号的错误。
• 运行时环境不兼容：内核模式和用户模式拥有完全隔离的内存空间，内核代码使用的内存分配（如ExAllocatePool）、同步原语（如KeWaitForSingleObject）、硬件访问接口等，在用户模式下没有对应的实现。就算强行链接成功，运行时调用这些函数会直接触发崩溃或非法访问。
• ABI与调用约定差异：/kernel编译时MSVC会采用内核模式专属的调用约定和结构对齐规则，和用户模式的默认设置（如__cdecl/__stdcall的常规用法）不匹配，直接链接会导致函数调用时栈损坏、参数传递错误，出现不可预测的行为。

优化重编译的方案 #

为了减少重复工作量，可以拆分驱动代码：

• 把不依赖内核API的业务逻辑抽离成独立的公共模块，编译时不使用/kernel参数，生成通用静态库；
• 内核驱动中保留和硬件交互、内核API调用的适配层，链接公共库；
• 用户模式测试程序直接链接公共库，针对测试场景编写用户态的模拟适配层（比如模拟硬件输入、替换内核API为用户态实现）。

这样后续只需要维护公共逻辑，内核和用户态的适配层各自独立，大幅降低重复编译的成本。

内容的提问来源于stack exchange，提问作者Derek C.