Third party .NET module not listed in the output of the "lm" command

Question

I created a sample .net app which uses log4net to write logs. It's just used to test the log4net lib.

But when I create a crash dump file by Windows Task Manager, and then open it using WinDbg, I can not find the module "log4net" after entering the command "lm".

Why does the command "lm" not list the dll "log4net.dll"?

Here's the output of WinDbg:

0:009> lmf
start             end                 module name
00000000`003e0000 00000000`003e8000   test_log4net C:\wangzhengzhang\Demo\demo\test_csharp\test_log4net\bin\Debug\test_log4net.exe
00007fff`1a260000 00007fff`1b748000   mscorlib_ni C:\WINDOWS\assembly\NativeImages_v4.0.30319_64\mscorlib\e96b4590c579d08edc2e60cc3e5ae997\mscorlib.ni.dll
00007fff`1b750000 00007fff`1c136000   clr      C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
00007fff`1c380000 00007fff`1c48e000   clrjit   C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clrjit.dll
00007fff`1c490000 00007fff`1c587000   MSVCR120_CLR0400 C:\WINDOWS\SYSTEM32\MSVCR120_CLR0400.dll
00007fff`1c590000 00007fff`1c62d000   mscoreei C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscoreei.dll
00007fff`1c630000 00007fff`1c696000   MSCOREE  C:\WINDOWS\SYSTEM32\MSCOREE.DLL
00007fff`2e590000 00007fff`2e59a000   VERSION  C:\WINDOWS\SYSTEM32\VERSION.dll
00007fff`30cc0000 00007fff`30cf3000   rsaenh   C:\WINDOWS\system32\rsaenh.dll
00007fff`30db0000 00007fff`30dc7000   CRYPTSP  C:\WINDOWS\SYSTEM32\CRYPTSP.dll
00007fff`30dd0000 00007fff`30ddb000   CRYPTBASE C:\WINDOWS\SYSTEM32\CRYPTBASE.dll
00007fff`31280000 00007fff`312ab000   bcrypt   C:\WINDOWS\SYSTEM32\bcrypt.dll
00007fff`31340000 00007fff`3134f000   kernel_appcore C:\WINDOWS\System32\kernel.appcore.dll
00007fff`313d0000 00007fff`3146c000   msvcp_win C:\WINDOWS\System32\msvcp_win.dll
00007fff`31470000 00007fff`31565000   ucrtbase C:\WINDOWS\System32\ucrtbase.dll
00007fff`317f0000 00007fff`3180e000   win32u   C:\WINDOWS\System32\win32u.dll
00007fff`318c0000 00007fff`31a42000   gdi32full C:\WINDOWS\System32\gdi32full.dll
00007fff`32190000 00007fff`323ad000   KERNELBASE C:\WINDOWS\System32\KERNELBASE.dll
00007fff`323b0000 00007fff`3241a000   bcryptPrimitives C:\WINDOWS\System32\bcryptPrimitives.dll
00007fff`32490000 00007fff`324e9000   sechost  C:\WINDOWS\System32\sechost.dll
00007fff`324f0000 00007fff`3251e000   IMM32    C:\WINDOWS\System32\IMM32.DLL
00007fff`32730000 00007fff`32764000   GDI32    C:\WINDOWS\System32\GDI32.dll
00007fff`32770000 00007fff`3282f000   OLEAUT32 C:\WINDOWS\System32\OLEAUT32.dll
00007fff`32830000 00007fff`32af7000   combase  C:\WINDOWS\System32\combase.dll
00007fff`34500000 00007fff`34665000   USER32   C:\WINDOWS\System32\USER32.dll
00007fff`34670000 00007fff`34791000   RPCRT4   C:\WINDOWS\System32\RPCRT4.dll
00007fff`347b0000 00007fff`3485b000   KERNEL32 C:\WINDOWS\System32\KERNEL32.dll
00007fff`34860000 00007fff`348fe000   msvcrt   C:\WINDOWS\System32\msvcrt.dll
00007fff`34910000 00007fff`349b2000   ADVAPI32 C:\WINDOWS\System32\ADVAPI32.dll
00007fff`34b60000 00007fff`34bb2000   SHLWAPI  C:\WINDOWS\System32\SHLWAPI.dll
00007fff`34d30000 00007fff`34e67000   ole32    C:\WINDOWS\System32\ole32.dll
00007fff`34ee0000 00007fff`350b1000   ntdll    C:\WINDOWS\SYSTEM32\ntdll.dll

Answer 1

This is because managed modules are no longer loaded by the OS loader. The CLR now maps these in a custom manner without OS help. Use !sos.dumpdomain to see managed modules.