Sos.dll on cloud

1-click AWS Deployment    1-click Azure Deployment


 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.

Win 7 SDK Installation

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. 

Enabled Debuggers

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 

Load SOS

Let’s say we want to view all the managed threads in the process. Type the following command 

Sos Threads

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. 

Microsoft Symbol Servers

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
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:

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)

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.



  • 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 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 is a Windows Debugger extension used to debug .NET Framework 4 applications.


Why user required to load SOS dll to windbg for .NET debugging

Sos.dll on cloud

Related Posts