1

Recently found that windbg preview(1.2205.18001.0) can not debug the .net framework program, all .cordll commands will output "CLR DLL status: No load attempts", and several friends around me have windbg previews like this.

()enter image description here

eg1：


0:126> .cordll -ve -u -l
CLR DLL status: No load attempts

eg2:


0:126> .cordll
CLR DLL status: No load attempts

eg3:


0:126> .cordll -lp D:\dumps
CLR DLL status: No load attempts

eg4: !t


0:126> !t
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of clr.dll is 
                in the version directory or on the symbol path
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on supported cross platform architecture as 
                the dump file. For example, an ARM dump file must be debugged
                on an X86 or an ARM machine; an AMD64 dump file must be
                debugged on an AMD64 machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.

Currently it's okay to debug .netcore programs, but .netframework doesn't work, you can't get dac, I found that when you enter !t, the dac component is automatically downloaded, but it can't be debugged.

how to solve it, thank you

dotnetfly
  • 170
  • 2
  • 8
  • I am debugging .NET Framework programs like I did 10 years ago. Just load the [SOS extension](https://stackoverflow.com/a/52264581/480982). I almost never used the `.cordll` command – Thomas Weller Jun 05 '22 at 18:55
  • The message you got asks you to prepare supporting files, https://halfblood.pro/how-to-prepare-your-windbg-magic-box-43b5e9ad8a03 – Lex Li Jun 05 '22 at 23:29
  • @ThomasWeller Windbg preview will automatically load sos.dll by default. Of course, I manually load sos.dll and it will not work. The problem that the .net framework cannot be debugged appeared about 10 days ago. If you can, you can use windbg preview to debug. netframework to verify, thank you. – dotnetfly Jun 06 '22 at 00:16
  • @LexLi Thanks for the reply, everything is normal in windbg 10, but it seems that windbg preview does not support it. If you can, you can use windbg preview to verify it, thank you. – dotnetfly Jun 06 '22 at 00:20
  • More like a bug to me. You can report to Microsoft and see what they say about it, https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-using-windbg-preview#providing-feedback – Lex Li Jun 06 '22 at 04:49

1 Answers1

3

We have been working to improve integrated support for debugging .NET applications/components within WinDbg for recent enough versions of .NET and, unfortunately, the issue around not being able to load the DAC for SoS commands is an inadvertent bug caused by some of those changes (e.g.: in the latest WinDbg Preview versioned 2205.18001). The next push to the Windows Store should come shortly and, hopefully, will resolve that particular problem.

JFYI: Below is an example of what I mean by "better integrated support":

0:000> k6
 # Child-SP          RetAddr               Call Site
00 000000b0`f71fe808 00007ffd`1a697391     KERNELBASE!wil::details::DebugBreak+0x2
01 000000b0`f71fe810 00007ffd`1985f5ee     clr!DebugDebugger::Break+0x151
02 000000b0`f71fe9b0 00007ffc`bab80aa4     mscorlib_ni!System.Diagnostics.Debugger.Break+0x5e
03 000000b0`f71fea00 00007ffc`bab8095e     TestCSharp2!TestCSharp2.Test.DoPrint+0xb4 [C:\Users\wmessmer\source\repos\TestCSharp2\TestCSharp2\Program.cs @ 23] 
04 000000b0`f71fea60 00007ffd`1a0769a3     TestCSharp2!TestCSharp2.Program.Main+0xce [C:\Users\wmessmer\source\repos\TestCSharp2\TestCSharp2\Program.cs @ 38] 
05 000000b0`f71feac0 00007ffd`1a0768c0     clr!CallDescrWorkerInternal+0x83
0:000> .frame 3
03 000000b0`f71fea00 00007ffc`bab8095e     TestCSharp2!TestCSharp2.Test.DoPrint+0xb4 [C:\Users\wmessmer\source\repos\TestCSharp2\TestCSharp2\Program.cs @ 23] 
0:000> dx this
this                 [Type: TestCSharp2.Test]
    [+0x008] m_a              : 100 [Type: int]
    [+0x00c] m_b              : 200 [Type: int]
0:000> dx ar
ar                 [Type: int[]]
    [0]              : 0 [Type: int]
    [1]              : 1 [Type: int]
    [2]              : 2 [Type: int]
    [3]              : 0 [Type: int]
    [4]              : 0 [Type: int]
William Messmer
  • 261
  • 1
  • 3
  • This feature is amazing, unmanaged commands can explicitly manage data, it seems that sos.dll & dac.dll can be retired. – dotnetfly Jun 09 '22 at 00:59