One DLL cannot simultaneously load into both kernel mode and user mode. When you run an EXE or DLL, the code must be fixed up to run at its given address. For example, jumps within the code or references to global variables must be modified to refer to the right addresses. Because kernel DLLs load above 0x80000000 and user DLLs load below 0x80000000, it is impossible for a single copy of the DLL to be fixed up to both locations at once.
In Windows Embedded CE 6.0, the operating system bypasses this limitation by having two versions of some DLLs; one version to load in kernel mode, and one version to load in user mode. The kernel has a new standard of naming DLLs that load in both kernel mode and user mode. The kernel-mode version of the DLL has a “k.” at the beginning of the name. For example, the user-mode version of coredll is coredll.dll while the kernel-mode version is k.coredll.dll. The significance of the “k.” is that the kernel automatically translates kernel-mode accesses to user-mode DLLs into the proper kernel-mode version. For example, if a DLL is linked against the user-mode coredll.dll, as almost all DLLs in the build system are, then when that DLL is loaded into the kernel process, the DLL ends up importing from the kernel-mode k.coredll.dll instead. There is no load error in this case because the imports are seamlessly redirected to the kernel DLL. Similarly, if code inside the kernel process calls LoadLibrary on coredll.dll, it will actually load a reference to k.coredll.dll. This way, if it goes on to call GetProcAddress and call a function, it calls the proper kernel-mode function.