Because of the difference between the test service environment and the WinDbg operating environment, this can occur when WinDbg is parsing the dump file. Net SOS.dll and Mscordacwks.dll version inconsistencies, resulting in WinDbg debugger extension commands not working properly, the specific solution is as follows:
1. First define the WINDGB symbols path (for example: D:\temp), and then create a folder under the symbols path to hold. NET SOS.dll and Mscordackwks.dll (e.g., d:\temp\clr1026);
2. Then copy the dump runtime environment, the SOS.dll and Mscordacwks.dll two DLLs under the. NET Framework installation path on the test server to the clr1026 folder in the symbols directory;
3. Finally start WinDbg and load the dump file, enter the Invoke command in the command window:. cordll-u-ve-lp + (root directory where SOS.dll and Mscordacwks.dll are located), i.e. Cordll-u-ve-lp d:\temp\ clr1026;
4. Verify that all extended commands under the debugger are working correctly, but still prompt for SOS and CLR version mismatch information during use:
650) this.width=650; "class=" Confluence-embedded-image "src=" http://conf.ctripcorp.com/download/attachments/ 83146612/image2016-3-10%2017%3a59%3a14.png?version=1&modificationdate=1457604257000&api=v2 "alt=" Image2016-3-10%2017%3a59%3a14.png?versio "/>
5. Run the. Chain command to find the additional DLL path, and then run the. Unload does not load the system default SOS.dll, last run. Setdll use a custom SOS.dll path, as follows 1, 2, and 3:
650) this.width=650; "class=" Confluence-embedded-image "src=" http://conf.ctripcorp.com/download/attachments/ 83146612/image2016-3-10%2018%3a3%3a46.png?version=1&modificationdate=1457604257000&api=v2 "alt=" Image2016-3-10%2018%3a3%3a46.png?version "/>
Windbg SOS and CLR versions inconsistent solution