1-click AWS Deployment 1-click Azure Deployment
Overview
The SOS (Son of Strike) Debugging Extension (SOS. dll) assists in debugging managed programs in Visual Studio and WinDbg by providing information about the internal common language runtime (CLR) environment. This tool requires a project to have unmanaged debugging enabled.
The SOS (Son of Strike) Debugging Extension (SOS.dll) assists in debugging managed programs in Visual Studio and WinDbg by providing information about the internal common language runtime (CLR) environment. This tool requires a project to have unmanaged debugging enabled. SOS.dll is automatically installed with the .NET Framework. To use SOS.dll in Visual Studio, install the Windows Driver Kit (WDK). To debug a process or memory dump, the sos.dll version must match the .NET Framework version. Psscor2 and Psscor4 are a superset of SOS.
-
Installing Debugging Tools for Windows :
Before we use the SOS extension, make sure you have downloaded the latest version of Debugging Tools for Windows which is a free download package (available in 32-bit and 62-bit) and consist of a set of powerful debuggers and tools to troubleshoot your application. I have chosen the link which says Debugging Tools for Windows 32-bit Version. After downloading winsdk_web.exe, run it and choose ‘Debugging Tools for Windows’ under ‘Common Utilities’ in the wizard, as shown below.
After a couple of minutes, the Debugging Tools for Windows will get installed in the following location: C:\Program Files\Debugging Tools for Windows (x86)
Using SOS Debugger Extension in Visual Studio 2010
Before using SOS, you have to load it into the debugger by using the load command in the Immediate window in VS 2010. Let us see how to use the SOS debugger extension in Visual Studio 2010 (works only in Pro, Premium, and Ultimate edition. Express Edition not supported)
Open a project in Visual Studio 2010 and create a breakpoint. In the Solution Explorer, right click the project > properties and in the Debug tab, make sure the ‘Enable unmanaged code debugging’ is checked.
Run the application. When the breakpoint is hit, use the Immediate Window (Ctrl+Alt+I) to type the following:
.load sos
If the sos.dll gets loaded successfully, you will see the following message
Let’s say we want to view all the managed threads in the process. Type the following command
There you go. It’s as simple as that to view managed threads. There are many more things you can do with this extension and we will explore them in forthcoming articles.
Note: You must be seeing a ‘PDB symbol for clr.dll not loaded’ message in the screenshot shown above. To resolve this error, go to Tools > Option > Debugging > Symbols and check the ‘Microsoft Symbol Servers’ checkbox in the Symbol file(.pdb) locations area. The error will not appear again.
Using SoS to debug 32-bit code in a 64-bit dump with WinDbg:
First open the dump in a windbg instance, shift it to the 32-bit view with !wow64ext.sw, load sos and then attempt to run some sos command. You will get the error message above.
Then start another windbg and attach that to the first instance. First we need to make SoS use the effective architecture instead of the executing architecture. The address we need to patch has changed a bit between versions of sos.dll (probably due to compiler optimizations), so do an assembly listing of sos!ArchQuery with the uf command:
0:005> uf sos!ArchQuery sos!ArchQuery: 0473c5b0 55 push ebp 0473c5b1 8bec mov ebp,esp 0473c5b3 51 push ecx 0473c5b4 a1907f7a04 mov eax,dword ptr [sos!g_ExtControl (047a7f90)] 0473c5b9 56 push esi 0473c5ba 8b08 mov ecx,dword ptr [eax] 0473c5bc 8d55fc lea edx,[ebp-4] 0473c5bf 52 push edx 0473c5c0 50 push eax 0473c5c1 33f6 xor esi,esi ; IDebugControl5[36] 90 -> BC: IDebugControl::GetEffectiveProcessorType ; 0x0473c5c3+2 - 0x0473c5b0 = 0x15. sos!ArchQuery+0x15 0473c5c3 ff9190000000 call dword ptr [ecx+90h] ; IDebugControl::GetExecutingProcessorType dbgeng!DebugCreate+0x3c5f 0473c5c9 8b45fc mov eax,dword ptr [ebp-4] 0473c5cc 3d4c010000 cmp eax,14Ch 0473c5d1 750a jne sos!ArchQuery+0x2d (0473c5dd) Branch
Look for the bolded line. Then calculate the address of that plus 2 and subtract the first address listed, like I have done in the blue comment. Now you have the relative address from the start of sos!ArchQuery to patch (e.g. 0x15 in my case). Now you can in the future refere to that location in your sos.dll version as sos!ArchQuery + <addr>. We have to patch that from 0x90 (IDebugControl::GetExecutingProcessorType) to 0xBC (IDebugControl::GetEffectiveProcessorType):
eb sos!ArchQuery+0x15 0xBC
(replace 0x15 with the relative address you just calculated).
Now this makes some of the sos commands works, e.g. !threads and !dumpstack works now, but others such as !CLRStack does not. This can be fixed by patching the function dbgeng!X86MachineInfo::ConvertCanonContextToTarget. Make a listing of this:
dbgeng!X86MachineInfo::ConvertCanonContextToTarget: 693ceef8 8bff mov edi,edi 693ceefa 55 push ebp 693ceefb 8bec mov ebp,esp 693ceefd 53 push ebx 693ceefe 56 push esi 693ceeff 57 push edi 693cef00 8b7d0c mov edi,dword ptr [ebp+0Ch] 693cef03 33db xor ebx,ebx 693cef05 57 push edi 693cef06 53 push ebx 693cef07 ff7510 push dword ptr [ebp+10h] 693cef0a 8bf1 mov esi,ecx 693cef0c e8c5690d00 call dbgeng!memset (694a58d6) 693cef11 8b4608 mov eax,dword ptr [esi+8] 693cef14 83c40c add esp,0Ch 693cef17 81b8a800000001100000 cmp dword ptr [eax+0A8h],1001h 693cef21 7715 ja dbgeng!X86MachineInfo::ConvertCanonContextToTarget+0x40 (693cef38) dbgeng!X86MachineInfo::ConvertCanonContextToTarget+0x2b: 693cef23 81ffcc000000 cmp edi,0CCh 693cef29 7264 jb dbgeng!X86MachineInfo::ConvertCanonContextToTarget+0x97 (693cef8f)
We need to patch this check out (note that your windbg instance might have problems with non-x86 dumps after this). So just replace the conditional jump with two nops:
ew dbgeng!X86MachineInfo::ConvertCanonContextToTarget+0x29 0x9090
Again the 0x29 may be different in your version, it is the bolded address minus the start address. Also the value compared to is 0x1004 instead of 0x1001 in debugging tools for windows 10 (probably because it’s an enum where members has been added).
Then just detach your second windbg instance from the first one and close it. After this every sos command I have tried seems to be working fine.
Pros :
- You can build DLLs separately.
- It could be faster to re-build one DLL
Cons :
- Calling code from DLL is slower
- It would be slower to re-build hole project with all DLLs
- Function names are visible. It is easier to reverse code that uses dynamic DLLs
The SOS.dll is a Microsoft NTSD extension for .NET Runtime.
This file is part of Debugging Tools for Windows(R). SOS.dll is developed by Microsoft Corporation. It’s a system and hidden file. SOS.dll is usually located in the %SYSTEM% sub-folder and its usual size is 319,488 bytes.
The SOS.dll process is safe and disabling it can be dangerous, because programs on your computer need it to work correctly.
Features
Features:
- detect object corruption
- detect memory leaks
- detect cross-generation references
- find apartment model for each thread
- find out which generation your object currently belongs to
- breakdown of each generation with a view of managed heap size and free space
- set managed code breakpoints
- find the application domain of your object
Major Features of Sos.dll
Psscor2.dll
Psscor2 is the Windows Debugger Extension used to debug .NET Framework applications that use the .NET CLR version 2.0 (.NET Framework versions 2 through 3.5). Psscor2 was developed for internal use at Microsoft as part of their Product Support Services tools. While Microsoft only released Psscor2 in 2010 Microsoft had been publishing commands from the extension several years before, causing difficulty for those who were trying to follow their processes.
Psscor4.dll
Psscor4 is a Windows Debugger extension used to debug .NET Framework 4 applications.
Videos
Why user required to load SOS dll to windbg for .NET debugging
