Note that there are some explanatory texts on larger screens.

plurals
  1. POUsing SOS in a dump with .NET 2 (mscorwks) and .NET 4 (clr)
    text
    copied!<p>I have a dump which has both .NET versions loaded:</p> <pre><code>0:000&gt; lm m clr start end module name 65490000 65aff000 clr (deferred) 0:000&gt; lm m mscorwks start end module name 6a980000 6af2c000 mscorwks (deferred) </code></pre> <p>Now I'm uncertain which version of SOS to use. Both will load without problems.</p> <pre><code>0:000&gt; .loadby sos mscorwks 0:000&gt; .loadby sos clr </code></pre> <p>How would I find out which version to use best for my analysis? Or will I always need both?</p> <p>Is .cordll -ve -u -l reliable in this case?</p> <pre><code>.symfix c:\symbols .cordll -ve -u -l CLRDLL: C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll:4.0.30319.18047 f:8 doesn't match desired version 4.0.30319.296 f:8 CLRDLL: Loaded DLL c:\symbols\mscordacwks_x86_x86_4.0.30319.296.dll\50484AA966f000\mscordacwks_x86_x86_4.0.30319.296.dll CLR DLL status: Loaded DLL c:\symbols\mscordacwks_x86_x86_4.0.30319.296.dll\50484AA966f000\mscordacwks_x86_x86_4.0.30319.296.dll </code></pre> <p>Thread 0 shows mscorwks. Commands used:</p> <pre><code>~0s k </code></pre> <p>=== UPDATE ===</p> <p><code>.cordll</code> in principle is ok. By default it will use .NET 4 framework. This behavior can be changed by <code>.cordll -I</code>.</p> <p>I have obtained both versions of SOS which match that of the target computer and loaded by path</p> <pre><code>.load C:\SOS\4.0.30319.296\SOS.dll </code></pre> <p>I have upgraded from WinDbg 6.2 to latest 6.3. Still not better.</p> <p>I have also asked Steve Johnson, the author of SOSEX who suggested <code>.cordll -I</code>, but this also does not work in my dump, neither with module name nor with base address.</p> <pre><code>.cordll -I clr .cordll -I 65490000 </code></pre> <p>Any attempt to run <code>!threads</code> always results in </p> <blockquote> <p>Failed to request ThreadStore.</p> </blockquote> <p>Any attempt to run <code>!clrstack</code> always results in </p> <blockquote> <p>Unable to walk the managed stack. The current thread is likely not a managed thread. You can run !threads to get a list of managed threads in the process.</p> </blockquote> <p>=== UPDATE ===</p> <p>As suggested by Mario Hewardt, the complex scenario with specifying the full SOS path can be avoided by only loading one SOS extension into the process (or unloading one in case they are already loaded) or we can use <code>.setdll</code> to define the default SOS version we like.</p> <p>However, this does not improve the analysis.</p> <p>=== UPDATE ===</p> <p>I have also tried unloading one of the .NET modules by <code>.reload /u</code> in the hope that WinDbg/SOS would not be in a conflict any more, but still no luck.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload