Debugging Script: Dumping out ASP.NET Session Contents

Link Listing - September 18, 2007

Christopher Steen — Wed, 19 Sep 2007 13:44:44 GMT

Link Listing - September 18, 2007

re: Debugging Script: Dumping out ASP.NET Session Contents

Jonathan Perret — Wed, 19 Sep 2007 17:18:28 GMT

This is very good info, Tess, thanks !

I don't have any suggestions for useful scripts right now, but I do have two questions that have been nagging me since your blog got me started using SoS :

1) How does !objsize exactly work and how reliable is it ? It seems you could have many sessions that each report being 100 MB in size while in fact they are all pointing to the same 100 MB block of data ?

2) Is there an easy way to filter out unreachable objects from !dumpheap etc. ? I'm asking this because I once had a situation where some code was creating hundreds of thousands of objects very fast, and every dump was full of these - it was very difficult to discern which were temporary and which were actual "leaks". I know of !gcroot but it's slow and not really practical to run it on every object. Ideally there would be a !collect command that would force or simulate a GC on the current heap. But perhaps I am thinking of this in entirely the wrong terms...

Well that's it, if you feel like addressing either or both I'd be grateful. Otherwise it's no matter, your blog has already been of tremendous help.

Cheers,

--Jonathan

re: Debugging Script: Dumping out ASP.NET Session Contents

Tess — Wed, 19 Sep 2007 17:41:15 GMT

Hi Jonathan,

1. You are completely right, you cant add upp the result of !objsize since it could potentially be pointing to the same data. i.e. if two items (a and b) both have a pointer to the same object (c) !objsize for a would include the size of c and !objsize for b would also include the size of c.

However if you have a toplevel object d, pointing to a and b, then the size of c and it's membervariables should only be counted once.

The same thing is true if you have a double-link, i.e a->c and c-> (eg. a control points to the parent page and the page has a list of controls which point to the control)

In this case the size of the control will only be counted once...

So in short, the !objsize of an item is pretty reliable, but the sum of all objsizes will exceed the total amount of memory on the heap.

2. No, there isn't an easy way to do this, and yes, gcroot usually takes a long time because it has to traverse a lot of objects...

The only recommendation I can make there is to run

GC.Collect

GC.WaitForPendingFinalizers

GC.Collect

before taking the dump, if you are in a testing environment. That way you will clean out as much as possible, leaving you with almost only reacheable objects.

Hope this helps,

Tess

September 23rd Links: VS, ASP.NET, ASP.NET AJAX, Silverlight, WPF

ScottGu's Blog — Mon, 24 Sep 2007 08:28:36 GMT

Here is the latest in my link-listing series . Also check out my ASP.NET Tips, Tricks and Tutorials page

September 23rd Links: VS, ASP.NET, ASP.NET AJAX, Silverlight, WPF

ASP.NET — Mon, 24 Sep 2007 08:34:40 GMT

Here is the latest in my link-listing series . Also check out my ASP.NET Tips, Tricks and Tutorials page

re: Debugging Script: Dumping out ASP.NET Session Contents

ASP.NET applications — Tue, 09 Oct 2007 10:46:31 GMT

Great blog.

Somehow in Java it seem to be much easier...

re: Debugging Script: Dumping out ASP.NET Session Contents

Niktu — Wed, 31 Oct 2007 19:17:32 GMT

Awww, my eyes!!!

Never again textual screenshoots in low quality jpeg, please! :D

Png or Gif heve their best use right in such situations :)

... after manadatory amount of complaining ...

Great info, Thanks!!!

re: Debugging Script: Dumping out ASP.NET Session Contents

Tess — Thu, 01 Nov 2007 11:30:08 GMT

:) I completely see what you're saying... I'll update with better pics shortly...

re: Debugging Script: Dumping out ASP.NET Session Contents

Tess — Thu, 01 Nov 2007 11:54:21 GMT

Niktu,

I found the problem with the pics, turns out that the tool i am using for blogging didn't choose to link to the external source but rather stored the pics on the blog but after having turned them into some low res thumbs of the pics. Now it should look a lot better:) I didn't realize this was happening so the pic quality bothered me too, so i'm glad i figured it out...

re: Debugging Script: Dumping out ASP.NET Session Contents

parag medsinge — Wed, 14 Nov 2007 13:13:49 GMT

I was trying to use the script dumpsessions.txt , i have win2000 Advance server on my machine

I m getting following error :

Address expression missing from ':\Aspnetdumps\Scripts\Dumpsessions.txt'

What will be the possible reason... Its urgent

re: Debugging Script: Dumping out ASP.NET Session Contents

Tess — Thu, 15 Nov 2007 12:09:56 GMT

sounds like the path to your script may be incorrect, perhaps you could post the command you use to load the script so that me or someone else reading the blog can take a look to figure out whats wrong

My presentation on Troubleshooting ASP.NET production issues at Developer Summit 2008

If broken it is, fix it you should — Fri, 11 Apr 2008 14:24:40 GMT

The purpose of my presentation was to show some common pitfalls and of course to show off windbg and

re: Debugging Script: Dumping out ASP.NET Session Contents

womp — Fri, 08 Aug 2008 00:27:29 GMT

Tess,

Thanks so much for your awesome labs/tutorials. I went through all of them and have gotten to the point where I'm trying to debug my own asp.net sessions.

Running these scripts seems to corrupt my dump. When I run DumpSessions.txt I get the following:

0:000> $$><DumpSessions.txt

Session Address: 015c8420

Session Size: 208 bytes

_______________________________________________

Session Address: 017e05a8

Session Size: 208 bytes

_______________________________________________

Session Address: 017ed374

Session Size: 208 bytes

_______________________________________________

Session Address: 01823aa4

Session Size: 208 bytes

_______________________________________________

Session Address: 01826570

Session Size: 208 bytes

_______________________________________________

Session Address: 05693848

Session Size: 6466088 bytes

_______________________________________________

Session Address: 05859788

Session Size: 208 bytes

_______________________________________________

Session Address: ------------------------------

Session Size: 1 bytes

_______________________________________________

This last entry will hang until I break in Windbg. If I try to run DumpSessionVar on my large session, I get a few good variable outputs and then it starts dumping

================================================

Session Variable

================================================

Sessionvar Size: not bytes

Session Variable: 0167e128

****

<Note: this object has an invalid CLASS field>

Invalid object

If I try to run either of the scripts, or even a !dumpheap after that, I get the following error message:

0:018> !dumpheap -stat

The garbage collector data structures are not in a valid state for traversal. It is either in the "plan phase," where objects are being moved around, or we are at the initialization or shutdown of the gc heap. Commands related to displaying, finding or traversing objects as well as gc heap segments may not work properly. !dumpheap and !verifyheap may incorrectly complain of heap consistency errors.

Error requesting GC Heap data

Unable to build snapshot of the garbage collector state

Any idea? My dump is from an IIS5 aspnet_wp.exe process with .net 2.0 runtime...

re: Debugging Script: Dumping out ASP.NET Session Contents

Tess — Fri, 08 Aug 2008 01:21:12 GMT

Hi Womp,

based on the output of the 2nd script it looks like your version is not matching the version that the script is written for so the offsets are a little bit off... so you would have to change the offsets in the scripts to match your version...

either way, to get back to a good state you can unload and reload the sos extension, i.e. .unload sos (or path to sos) and then .load sos (or path to sos) again

re: Debugging Script: Dumping out ASP.NET Session Contents

womp — Fri, 08 Aug 2008 01:27:39 GMT

Well I figured out the first part of the problem...

!dumpheap ... -short was printing out a line of "---------" at the end of the output, which was being taken as one of the sessions in the for loop. Here's some fixed up code for the script:

.foreach (CurrentSession {!dumpheap -type System.Web.SessionState.InProcSessionState -short}){

.if ('${CurrentSession}' == '------------------------------')

{

$$.printf /D "Not an Address\n";

}

.else

{

$$ Increment # of sessions

r @$t0 = @$t0+1

.printf /D "Session Address:\t<?dml?><exec cmd=\"$$>a< DumpSessionVar.txt ${CurrentSession}\">${CurrentSession}</exec>\n";

.printf "Session Timeout:\t%d\n", poi(${CurrentSession}+0xc);

.foreach /pS 2 /ps 99 (token {!objsize ${CurrentSession}}){.printf "Session Size:\t${token} bytes\n"}

.printf "_______________________________________________\n";

$$.printf /D "An address\n";

}

Now DumpSessionVar.txt gets quite a bit further before bogging down with the invalid class field errors.... but it still doesn't complete properly and ends up in some kind of corrupted state....

re: Debugging Script: Dumping out ASP.NET Session Contents

slmoloch — Tue, 26 Aug 2008 13:05:00 GMT

Hello,

Could you help me? I have problem similar to the problem above:

0:000> !dumpheap -stat

The garbage collector data structures are not in a valid state for traversal.

It is either in the "plan phase," where objects are being moved around, or

we are at the initialization or shutdown of the gc heap. Commands related to

displaying, finding or traversing objects as well as gc heap segments may not

work properly. !dumpheap and !verifyheap may incorrectly complain of heap

consistency errors.

Error requesting GC Heap data

Unable to build snapshot of the garbage collector state

I am using SOS for .NET 2.0 and dump is got from the same version.

re: Debugging Script: Dumping out ASP.NET Session Contents

Tess — Tue, 26 Aug 2008 13:16:10 GMT

like the message says you are probably in the middle of a GC in the dump so you can't traverse the heap and thus we can't pick up the requests from the heap

Developers are from Mars, Ops people are from Venus… or It looked good on paper

If broken it is, fix it you should — Fri, 03 Apr 2009 16:57:04 GMT

A few weeks back me and Micke (one of our Architect Evangelists) had a session at TechDays where we talked