New MSDN Article – Investigating Memory Issues

We have a new MSDN article out in the November issue that talks about investigating managed memory issues.

Take a look and let me know what you think.

Oh, and it's also in 6 other languages (German, Spanish, French, Russian, Portuguese and Chinese) for readers that prefer one of those languages.

Comments (10)

  1. Miral says:

    Shouldn’t you tell people to use the version of SOS that comes with the Debugging Tools for Windows rather than the one that came with the framework?  The DTW version of SOS has a *lot* more commands, including a handy !analysis command that goes and does the common stuff for you.  (Though it can sometimes take a long time to complete — the last time I used it it took 2.5 solid days of execution, mostly while doing the !objsize.)

  2. Mark says:

    In the article under figure 5, you have a command listed that dumps out information about all the strings:

    !dumpheap -type System.String -min 150 -max 200

    and it shows the first few characters of the string. When I execute that command, I don’t get the first few characters of the string. I am using the release version of .NET 2.0 and loading the sos.dll from the C:WINDOWSMicrosoft.NETFrameworkv2.0.50727 directory. Any ideas why it is behaving differently for me?

  3. nativecpp says:

    Hi Maoni,

    I would like to find out what is the latest and greatest version of sos as well. I was blogging with Tess the other day and she said that "!dc is short for !dumpcollection  (a command in some versions of sos.dll)". When I loaded my sos, it does NOT have the command. I would love to have the latest SOS commands to help me to debug. Are there many different versions of SOS ? Does Microsoft us same version as ‘us/public’ ?

    BTW, my SOS version is

    extension C:WINDOWSMicrosoft.NETFrameworkv2.0.50727sos.dll loaded

  4. Well, unfortunately there isn’t an sos that ships with the debugger package for 2.0 (due to legal issues).

    Mark, if you don’t see the content of the string you can always dump them yourself by either

    db address_of_string_object

    or du on the actual unicode string.

  5. nativecpp says:

    I FINALLY finished reading the article that you co-authored. I thought it has a lot of useful information. But for someone just started thinking about GC & SOS, it might be overwhelming. BTW, about two years ago, my co-worker and I tried to monitor the app (ASP.NET) and used a lot of counters. One of the counters was

    .NET CLR Data->SqlClient: Total # failed command

    under the performance monitor and was able to locate some old sql statements where tables were no longer exist. Not only did we elimante the useless code but also remove the exceptions it caused.

  6. nativecpp, I agree, it could be overwheling for someone who just started. We are always trying to improve our tools to make life easier for people. For now sos is a tremendously useful thing for investigating managed applications. Hopefully my previous blog enties explain a lot of things mentioned in the article.

  7. Howard says:

    Hi Maoni

    That’s an excellant article and has recently helped me understand an OOM exception on a customers site. However there’s one part of it I’m not quite sure about. There’s a sentence in that article that goes like this "The !eeheap -gc command…… You can correlate this with !address to determine if virtual memory is fragmented by the managed heap". Can expand on this? An example correlation of the outputs from these two commands would be great. Many Thanks.

  8. Howard, since I can’t use different fonts/colors I posted a new article to answer your question:

  9. Howard says:

    Blimey that was quick!, thanks for that. Now it’s time to apply that to my current set of dumpfiles. I don’t think that we’re seeing that kind of fragmentation here, I just wanted to know how to look for it, thanks again.

  10. Andy says:

    Jus tso folks know, the link to that article is now:

Skip to main content