windbg指定SOS版本，执行扩展命令报错

调试dump文件，加载相匹配版本的sos/clr时，绝大多数都是可以正常使用的。

然而凡事都有例外，今天在做类似工作时，遇到了错误：

CLRDLL: Consider using ".cordll -lp <path>" command to specify .NET runtime directory.
Failed to load data access DLL, 0x80004005

再次指定mscordacwks.dll所在路径，问题解决。

To debug a managed application, the debugger must load a data access component (DAC) that corresponds to the CLR that the application has loaded. However, in some cases, the application loads more than one CLR. In that case, you can use the I parameter to specify which DAC the debugger should load. Version 2 of the CLR is named Mscorwks.dll, and version 4 of the CLR is named Clr.dll. The following example shows how to specify that the debugger should load the DAC for version 2 (mscorwks).

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-cordll--control-clr-debugging-

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*C:Symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Fri Dec 29 11:43:54.000 2017 (UTC + 8:00)
System Uptime: 7 days 17:13:43.569
Process Uptime: 0 days 0:32:30.000
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
...............
ntdll!ZwWaitForSingleObject+0xa:
00000000`779abd7a c3              ret
0:000> lmvm clr

Browse full module list
start             end                 module name
000007fe`fa120000 000007fe`faa85000   clr        (deferred)
    Image path: C:WindowsMicrosoft.NETFramework64v4.0.30319clr.dll
    Image name: clr.dll
    Browse all global symbols  functions  data
    Timestamp:        Wed Mar 30 16:43:27 2011 (4D92ED2F)
    CheckSum:         00966902
    ImageSize:        00965000
    File version: 4.0.30319.233

    Product version:  4.0.30319.233
    File flags:       8 (Mask 3F) Private
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® .NET Framework
    InternalName:     clr.dll
    OriginalFilename: clr.dll
    ProductVersion:   4.0.30319.233
    FileVersion:      4.0.30319.233 (RTMGDR.030319-2300)
    PrivateBuild:     DDBLD457
    FileDescription:  Microsoft .NET Runtime Common Language Runtime - WorkStation
    LegalCopyright:   © Microsoft Corporation.  All rights reserved.
    Comments:         Flavor=Retail
0:000> .load D:dumpsdotNet_dlls00__233x64sos.dll

0:000> !tp
CLRDLL: Consider using ".cordll -lp <path>" command to specify .NET runtime directory.
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
            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 the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                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.
0:000> .cordll -ve -u -l
CLRDLL: C:WindowsMicrosoft.NETFramework64v4.0.30319mscordacwks.dll:4.7.2115.00 f:8
doesn't match desired version 4.0.30319.233 f:8
CLRDLL: Unable to find mscordacwks_AMD64_AMD64_4.0.30319.233.dll by mscorwks search
CLRDLL: Unable to find 'mscordacwks_AMD64_AMD64_4.0.30319.233.dll' on the path
CLRDLL: Unable to find clr.dll by search
Cannot Automatically load SOS
CLRDLL: ERROR: Unable to load DLL mscordacwks_AMD64_AMD64_4.0.30319.233.dll, Win32 error 0n2
CLRDLL: Consider using ".cordll -lp <path>" command to specify .NET runtime directory.
CLR DLL status: ERROR: Unable to load DLL mscordacwks_AMD64_AMD64_4.0.30319.233.dll, Win32 error 0n2
0:000> .cordll -lp D:dumpsdotNet_dlls0__233x64

CLRDLL: Loaded DLL D:dumpsdotNet_dlls0__233x64mscordacwks.dll
Automatically loaded SOS Extension
CLR DLL status: Loaded DLL D:dumpsdotNet_dlls0__233x64mscordacwks.dll
0:000> !tp
CPU utilization: 83%
Worker Thread: Total: 16 Running: 13 Idle: 0 MaxLimit: 800 MinLimit: 8
Work Request in Queue: 8
    Unknown Function: 000007fefad52da0  Context: 000000000c2544b0
    Unknown Function: 000007fefad52da0  Context: 000000000c2690e0
    AsyncTimerCallbackCompletion TimerInfo@0000000007f14740
    Unknown Function: 000007fefad52da0  Context: 000000000c257ea0
    Unknown Function: 000007fefad52da0  Context: 000000000c257f00
    Unknown Function: 000007fefad52da0  Context: 000000000c257e40
    Unknown Function: 000007fefad52da0  Context: 000000000c268ea0
    Unknown Function: 000007fefad52da0  Context: 000000000c257fc0
--------------------------------------
Number of Timers: 56
--------------------------------------
Completion Port Thread:Total: 3 Free: 3 MaxFree: 16 CurrentLimit: 3 MaxLimit: 800 MinLimit: 8