Windows 设备驱动程序可以有依赖关系吗？

Question

I wrote a kernel-mode driver using C. When I examined it using dependency walker I saw that it depends on some NT*.dll and HAL.dll.

I have several questions:

1. When does the OS load these DLLs? I thought kernel is responsible for loading DLLs in that case how can driver load a DLL if it is already in kernel-mode
2. Why don't the standard C dependencies show up like ucrtbase, concrt, vcruntime, msvcp etc? Would it be possible for a driver to have these dependencies and still function?
3. (A continuation of the last question). If Windows will still load DLLs even in kernel mode, I don't see why drivers cannot be written in (MS) C++

Thanks,

Answer 1

1. Most of the API in the driver is exported from ntoskrnl.exe.

   Your driver is actually a "kernel module", which is part of a process, just like the modules in Ring3.

   The driver's "process" is "System", with a Pid of 4, which you can see in the task manager.

   ntoskrnl.exe and HAL.dll are modules in the "System", they will Loaded at system startup, while other modules are loaded at time of use (such as your drivers).

   You can write and load "driver DLLs", but I haven't done so yet, so I can't answer that.

2. Ring3 modules are not loaded into the kernel, so you can't call many common Ring3 APIs, but Microsoft has mostly provided alternative APIs for them.

   You can't load the Ring3 module directly into the kernel and call its export function. There may be some very complicated methods or tricks to do this, but it's really not necessary.

3. You can write drivers in C++, but this is not officially recommended by Microsoft at this time as it will encounter many problems, such as:

   • Constructors and destructors of global variables cannot be called automatically.

   • You can't use C++ standard libraries directly.

   • You can't use new and delete directly, they need to be overridden.

   • C++ exceptions cannot be used directly, and will consume a lot of stack space if you support them manually. Ring0 driver stack space is usually much smaller than Ring3 application stack space, indicating that BSOD may be caused.

   Fortunately:

   • Some great people have solved most of the problems, such as the automatic calling of constructors and destructors and the use of standard libraries. GitHub Project Link (But I still don't recommend using standard libraries in the kernel unless it's necessary, because they are too complex and large and can lead to some unanticipated issues)

   • My friend told me that Microsoft seems to have a small team currently trying to make drivers support C++. But I don't have time to confirm the veracity of this claim.