我們在用windbg調試客戶發來的dump文件的時候，如果不是相同的環境的話，很容易出現這個現象，簡單的說就是程序運行機器上的CLR與當前開發調試人員機器上的CLR是不同的版本，從而導致開發人員機器上的SOS.dll與dump file中要求的SOS.dll不一樣（比如應用程序要求是.net framework 4.6,所以客戶機安裝的就是.net 4.6，但是開發人員機器上安裝的是.net 4.7）。
我們在open crash dump之後。輸入命令.loadby sos clr，這時候是成功的，但是在運用擴展命令的時候就顯示失敗，比如!dumpheap，這時候顯示CLR version和SOS version 不匹配，這個時候你就需要將客戶機器(相同環境機器也行)上的sos.dll複製到調試機器上隨便一個文件夾，比如C:\temp\目錄下，然後運行.load c:\temp\sos.dll，這時候也會成功。
在執行上述過程之後，還是不能調試，因爲sos.dll還對應一個mscordacwks.dll, 同時你還需要將這個dll從客戶機器上覆制過來，放到symbol所在的目錄或者source文件所在的目錄下都行， 但是需要改名字，名字的規則如下：
mscordacwks_AAA_AAA_x.x.x.xxxx.dll
其中AAA是dump的bit位對應的(x86 or AMD64)，x.x.x.x實際上就是mscordacwks.dll的版本號（可以從文件的property dialog中查到），比如2.0.50272.8763， 4.7.2114.0等。
然後運行.cordll -ve -u -l 命令，就能查看出該dll被成功加載，並且顯示之前的dll不匹配SOS.dll版本。
經過上面的過程之後就能利用SOS 擴展命令正常調試了。
注：如果你不知道怎麼改mscordacwks.dll名字，可以先運行.cordll -ve -u -l,就會顯示當前的版本不匹配SOS的版本，需要的dll的名字是什麼。
客戶機dll的路徑: c:\windows\microsoft.NET\framework\各個版本目錄下，根據上面命令的提示可以找到對應的文件夾，比如4.0之後的都是在4.0.*目錄下，2.0的都是在2.0.*目錄下。