Chat Question: What extension to use in what situation


So we have a bunch of debugger extensions that we need to use depending on the situation.  So here are the extensions that can depend on various situations and when to use which.  The first thing to decide is to load the right DLL for the Framework version and Process version:

Extension Process Version Framework Version
clr10\sos.dll any 32-bit process .NET 1.0/.NET 1.1
Framework\v2.0.50727\sos.dll any 32-bit process .NET 2.0/.NET 3.0/.NET 3.5
Framework64\v2.0.50727\sos.dll any 64-bit process .NET 2.0/.NET 3.0/.NET 3.5
IISInfo.dll any 32-bit process N/A – IIS extension

Keep in mind that you can run a 32-bit process on a 64-bit operating system.  You would still use the 32-bit files to debug it.

If you are dealing with a crash, a good starting point is always to run !analyze -v.  This will check for known issues and help to narrow down where the problem is for a crash.  It isn’t perfect for .NET, but will do a great job getting you something to go on.

Once you have the right extension loaded, then you can start troubleshooting things.

Note: In the future, I hope to have a new extension that will run on top of SOS.dll and allow you to do some more advanced functions.  This will give similar results to the clr10\sos.dll extension.  But it will be able to run against all versions of the framework.  I am still flushing things out on that, feel free to give me your comments here.

Keep checking the RECAP- ASP.NET Blog Chat to see other topics that Tess or I write about.

kick it on DotNetKicks.com

Comments (5)

  1. You’ve been kicked (a good thing) – Trackback from DotNetKicks.com

  2. So we have a bunch of debugger extensions that we need to use depending on the situation.  So here

  3. So we have a bunch of debugger extensions that we need to use depending on the situation. So here are

  4. daveblack says:

    Additional info on IIS & 32-bit vs. 64-bit…

    quoting from an article on Tess’s blog:

    <quote>

    By default when you run IIS on a 64-bit machine you will still be running a 32-bit w3wp.exe, so apart from a few differences, like being able to use 4 GB virtual bytes instead of 2 GB virtual bytes the difference in debugging an issue on 32-bit vs. 64-bit is not that big.  You will still be debugging with a 32-bit debugger and the memory will be aligned the same as in any 32-bit process on a 32-bit system.

    As a matter of fact, something that is very important to point out, is that if you happen to use the 64-bit version of windbg.exe and the debugging tools for windows you will create dumps that are virtually unusable for debugging managed issues.

    However if you have installed 64-bit IIS it’s a bit different.  If that is the case you need to take special care to use the 64-bit debuggers and the 64-bit version of sos.dll etc. or else you will not see anything at all.

    </quote>

    from http://blogs.msdn.com/tess/archive/2007/08/09/asp-net-memory-issue-high-memory-usage-in-a-64bit-w3wp-exe-process.aspx

  5. That is very true, that is why in the table I talk about the process version, not really the OS version.  Be sure to know which one you are running.