Debugging Script: Dumping out current and recent ASP.NET Requests

re: Debugging Script: Dumping out current and recent ASP.NET Requests

LosManos — Thu, 13 Sep 2007 10:40:26 GMT

hejdig.

I would bet you 1600 comes from the conversion from julian to gregorian date system. 1600 is not the first gregorian year but something like the first leap year.

See more about the gregorian calendar at:

http://www.answers.com/topic/gregorian-calendar

Search for Sweden for the history about when Sweden changed their calendar. Marvellous lack of thinking. And a headache for historians who get high on exact dates.

Thanks for a really good blog.

/OF

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Thiago — Fri, 14 Sep 2007 00:03:15 GMT

Really helpful script!

Thanks!

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Roberto Farah — Fri, 14 Sep 2007 01:22:12 GMT

Very nice script, Tess! :)

Have you tried to use PowerShell?

I'm using PowerShell to create WinDbg scripts. This approach has several benefits and opens endless possibilities.

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Tess — Fri, 14 Sep 2007 22:52:41 GMT

Thanks for the links on the gregorian calendar... really interesting. It appears that the reason it is 1600 years off probably has to do with exactly this... and that the CLR bases the ticks on 1/1 0001 (SYSTEM TIME) while WinDbg goes by FILETIME which is (ticks since 1/1 1601)

http://blogs.msdn.com/oldnewthing/archive/2003/09/05/54806.aspx

About PowerShell,

I looked at it some time ago and I have written some scripts for it, but for things like this where a regular windbg script works well i feel that it is a bit of overkill using powershell... especially since you have to install powershell and do a bit of prework before you can use it... For larger scripts I find it extremely interesting though...

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Brian — Sun, 16 Sep 2007 17:29:24 GMT

Would it be possible to write a pre-processing script that could figure out the offsets rather than having them hardcoded?

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Tess — Mon, 17 Sep 2007 10:15:26 GMT

Hi Brian,

yes absolutely,

you can run !name2ee System.Web.HttpContext and parse the output.

I didn't do it here because I wanted to do something that was fairly easy to write and read, plus the extra pre-processing would happen on every run of the script... I figured that typically when you debug your own servers you will stay at one version for a while.

If you happen to write a script with pre-processing, please post it though since I and I am sure a lot of people reading this would find it very interesting.

Thanks

Tess

Debugging Script: Dumping out ASP.NET Session Contents

If broken it is, fix it you should — Tue, 18 Sep 2007 13:49:22 GMT

In my last post I wrote a script to dump out all the ASP.NET requests on the heap. Since one of the most

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Brian Hartung — Fri, 21 Sep 2007 05:45:27 GMT

>> If you happen to write a script with pre-processing, please post it though since I and I am sure a lot of people reading this would find it very interesting.

Well, since you asked...and considering all the help you've given us over the years, how could I turn down a request like that! What an exercise in frustration learning the scripting language turned out to be. But at least now I feel reasonably comfortable with it.

It will be interesting to see what this code looks like since I'm posting it here in the Comments box...

Cheers,

-Brian

$$ Title: GetOffsetsForDumpAllRequestsScript.txt

$$ Description: Used to compute CLR version-specific offsets for ASP.NET

$$ objects queried by the "DumpAllRequests" script written

$$ by Tess Ferrandez (http://blogs.msdn.com/tess)

$$ Author: If this script works, it was written by Brian Hartung (brian AT hartungconsulting DOT com)

$$ If not, I don't know who wrote it.

$$ Run As: $><c:\tools\extensions\ComputeOffsetsForDumpAllRequestsScript.txt

$$ License: Public domain. Do with this script what you will (I won't be offended).

$$ Dump a CLR version header

.block

{

.foreach /pS 0 (token {!eeversion})

{

.printf "$$ Auto-generated offsets for DumpAllRequests.txt script\n"

.printf "$$ CLR Version ${token}\n\n";

.break

}

$$ All of the following sections use the same basic pattern. First an EEClass address

$$ is computed for a class and stored in a user-defined property. Next, the EEClass is

$$ dumped and the output is scanned looking for a specific property name. We make use

$$ of the .shell directive and the standard Windows findstr.exe utility (which supports

$$ searching using regular expresssions). Although the use of .shell results in a good

$$ deal of screen flicker, it's quite a bit faster than iterating over the entire output

$$ stream and tokenizing it using .foreach since it limits the results to the single row

$$ we're interested in. This also has the benefit of being more resilient to CLR version

$$ changes. The sos.dll debugger extension could have breaking changes made to it, such as

$$ adding a column to the right of the member name in !dumpclass or changing the column order

$$ such that Offset is not the third column, but this seems less likely than new members being

$$ added to a class (which would break any techniques that search for a known token name

$$ and index from that to obtain the Offset value...this is because the offset column appears

$$ earlier in the stream than the property name, so one (fragile) technique would be to search

$$ for a token that's expected to be at the end of the immediately preceding row and then index

$$ forward from there. The find.exe utility was not used because it will produce partial matches

$$ and the algorithm here depends on an exact match on the property name. As a final note, the

$$ !dumpclass command was used rather than !dumpobject because 1) it doesn't require having a

$$ reference to a live object and 2) its output would also include value type members.

$$ As a final note, the fact that the .shell directive caused all that annoying screen flashing

$$ caused me to have the result of this script be the generation of a block of script that could

$$ be pasted at the top of the DumpAllRequests script rather than having it run each time. That

$$ means each time a new version of the CLR is installed, this stub will have to be regenerated

$$ and re-pasted. If the screen flashing is less of a concern than having up-to-the-minute offset

$$ values, then simply remove the .printf directives that surround the aS commands which would

$$ cause them to be executed and stored in user-defined properties at runtime rather than simply

$$ displayed for copying-and-pasting purposes. Of course, anyone choosing to go that route will

$$ hopefully not have a problem with photosensitive seizures. Don't say I didn't warn you...

$$ Compute required HttpContext member offsets

.block {as gtCommand .shell -ci "!name2ee System.Web.dll System.Web.HttpContext" findstr /r ^EEClass:}

.block

{

.foreach /pS 1 (token {${gtCommand}})

{

.block {aS HttpContextEEClass 0x${token}}

.break

}

.block {as gtCommand .shell -ci "!dumpclass ${HttpContextEEClass}" findstr /r _timeout$}

.block

{

.foreach /pS 2 (token {${gtCommand}})

{

.printf ".block {aS HttpContextTimeoutOffset 0x${token}}\n"

.break

}

$$ Compute required ISAPIWorkerRequest member offsets

.block {as gtCommand .shell -ci "!name2ee System.Web.dll System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6" findstr /r ^EEClass:}

.block

{

.foreach /pS 1 (token {${gtCommand}})

{

.block {aS ISAPIWorkerRequestEEClass 0x${token}}

.break

}

.block {as gtCommand .shell -ci "!dumpclass ${ISAPIWorkerRequestEEClass}" findstr /r _startTime$}

.block

{

.foreach /pS 2 (token {${gtCommand}})

{

.printf ".block {aS ISAPIWorkerRequestStartTimeOffset 0x${token}}\n"

.break

}

$$ Compute required HttpResponse member offsets

.block {as gtCommand .shell -ci "!name2ee System.Web.dll System.Web.HttpResponse" findstr /r ^EEClass:}

.block

{

.foreach /pS 1 (token {${gtCommand}})

{

.block {aS HttpResponseEEClass 0x${token}}

.break

}

.block {as gtCommand .shell -ci "!dumpclass ${HttpResponseEEClass}" findstr /r _completed$}

.block

{

.foreach /pS 2 (token {${gtCommand}})

{

.printf ".block {aS HttpResponseCompletedOffset 0x${token}}\n"

.break

}

.block {as gtCommand .shell -ci "!dumpclass ${HttpResponseEEClass}" findstr /r _statusCode$}

.block

{

.foreach /pS 2 (token {${gtCommand}})

{

.printf ".block {aS HttpResponseStatusCodeOffset 0x${token}}\n"

.break

}

$$ Compute required HttpRequest member offsets

.block {as gtCommand .shell -ci "!name2ee System.Web.dll System.Web.HttpRequest" findstr /r ^EEClass:}

.block

{

.foreach /pS 1 (token {${gtCommand}})

{

.block {aS HttpRequestEEClass 0x${token}}

.break

}

.block {as gtCommand .shell -ci "!dumpclass ${HttpRequestEEClass}" findstr /r _httpVerb$}

.block

{

.foreach /pS 2 (token {${gtCommand}})

{

.printf ".block {aS HttpRequestHttpVerbOffset 0x${token}}\n"

.break

}

.block {as gtCommand .shell -ci "!dumpclass ${HttpRequestEEClass}" findstr /r _path$}

.block

{

.foreach /pS 2 (token {${gtCommand}})

{

.printf ".block {aS HttpRequestPathOffset 0x${token}}\n"

.break

}

.block {as gtCommand .shell -ci "!dumpclass ${HttpRequestEEClass}" findstr /r _queryStringText$}

.block

{

.foreach /pS 2 (token {${gtCommand}})

{

.printf ".block {aS HttpRequestQueryStringTextOffset 0x${token}}\n"

.break

}

$$ Clear out the user-defined aliases so we don't leave garbage lying around

ad /q *

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Tess — Fri, 21 Sep 2007 09:19:53 GMT

Awesome stuff... thank you much for posting it Brian

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Brian Hartung — Sat, 22 Sep 2007 19:56:44 GMT

I created another WinDbg script which hopefully you might find useful. The idea is that when you run a command and parse the output tokens using the .foreach command, it's not always possible to index into the stream using a fixed offset, but rather it might be useful to search for a known value and then index a fixed number of tokens from there. I created a script called GetToken for just such a purpose. Because scripts don't seem to post too well in these Comments (extra line breaks, loss of indentation, etc.), I have also posted a copy on my blog (http://brianhartung.blogspot.com/2007/09/useful-windbg-script-gettoken.html) which should retain all the formatting.

Instructions for usage, parameters and outputs are embedded in the comments.

Hope you find this useful,

-Brian

$$ GetToken: A helper function used to run a specified command, search for a

$$ specified token value in the output stream from the command and

$$ then return the nth token following that specified search value

$$ in a specified alias name.

$$ Returns: 1) The value of the nth token in the specified alias

$$ 2) A status code in $t0 (0 = Token Not Found / 1 = Token Found)

$$ 3) The offset to the specified search token in $t1

$$ Written by: If this code works, it was written by Brian Hartung. If not, I

$$ don't know who wrote it.

$$ Run As: $$>a< c:\tools\extensions\GetToken.txt "CommandToRun" "SearchValue" 0xn ReturnAlias

$$ Example: To return the address of the EEClass for HttpContext, use these parameters:

$$ "!name2ee System.Web.dll System.Web.HttpContext" "EEClass:" 1 HttpContextEEClass

$$ Notes: 1) the value for parameter n must be specified in hex

$$ 2) the last two parameters must not have quotes

$$ 3) the alias name specified for returning the value must not already be defined

$$ License: Public Domain. Do with this script what you will (I won't be offended).

$$ Reset $t0 which will be used to return a success (1) or failure (0) status code

r $t0=0

$$ Reset $t1 which will be used as a token counter

r $t1=0

$$ Loop through the tokens returned by the command supplied in arg1

.foreach (token {$arg1})

{

$$ The string comparison function $scmp returns 0 if the strings match.

$$ In this case, we're looking to see if the current token matches the

$$ search value supplied in arg2

.if($scmp("${token}", "$arg2")==0)

{

$$ Compute the total offset to the desired token, which is the

$$ index of the search token plus the number of tokens to skip

$$ as specified in arg3

.block {r $t1 = @$t1 + ${$arg3}}

$$ Skip directly to the desired token

.foreach /pS $t1 (returnValue {$arg1})

{

$$ Store the current token in the specified return value alias

.block {aS ${$arg4} ${returnValue}}

$$ No need to consider any more tokens

.break

}

$$ Return the success status code

r $t0 = 1

.break

}

.else

{

$$ Haven't found it yet, so keep incrementing the counter until we do

r $t1 = $t1 + 1

}

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Tess — Mon, 24 Sep 2007 09:19:36 GMT

Again, really cool... thank you very much for posting these Brian, this latest one will be really useful...

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Vishwas — Wed, 14 Nov 2007 06:05:32 GMT

awesome post!!

for the boolean values - it looks like only the last bit is counted for whether the value is true or false. So for Completed status,

.foreach /pS 1 (token {dd poi(${hc}+0x14)+61 l1}){

.if (${token} == 0) {

.printf "No\t\t"

}

.else {

.printf "Yes\t\t"

}

};

will say completed even if the vlaue at that address is 00000100, which is false or the request is incomplete.

Instead what worked for me was -

.if ($spat("${token}", "???????1")){

.printf "Yes\n"

}

.else{

.printf "No\n"

}

Do correct me if I am wrong, since I am a newbie to windbg and whatever I have learnt about scripts for windbg is from this post :).

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Tess — Thu, 15 Nov 2007 12:11:36 GMT

great, yeah the scripts are a bit quick and dirty so i'm not surprised if there are issues with them on different versions.

THanks for the correction

Case Study: ASP.NET Deadlock calling WebServices

If broken it is, fix it you should — Tue, 18 Dec 2007 18:31:43 GMT

Lately, no matter where you turn there is LINQ presentations and Silverlight demos. A couple of years

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Tess — Thu, 24 Jan 2008 11:37:10 GMT

I wrote in the blog post "Another curiosity is that providing an initial skip to .foreach that is larger than 9 causes no tokens to be returned" and I just got a note from Dan Wilson explaining this curiosity to me... apparently the value you give for the initial skip is hexadecimal (rather than decimal like i thought), so initial skips over 9 work just fine, its just a matter of giving the value in hex instead of decimal...

Thanks much Dan for that insight, makes it a lot easier to write scripts since you dont have to nest the .foreach loops

September 16th Links: ASP.NET, ASP.NET AJAX, IIS7, Visual Studio, Silverlight

rox19840702 — Wed, 27 Feb 2008 19:39:47 GMT

September 16th Links: ASP.NET, ASP.NET AJAX, IIS7, Visual Studio, Silverlight

Why are some commands missing in sos for 2.0 compared to sos for 1.1?

If broken it is, fix it you should — Wed, 30 Apr 2008 09:27:20 GMT

This question that I got from a reader is something that I get asked pretty frequently... "I met a small

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Kumar — Mon, 16 Jun 2008 19:57:24 GMT

Hi Tess

Just wondering if adding this pre condition to the scripts above would ensure that only "HttpContext" objects are processed as !dumpheap can potentially return all types which have HttpContext in their name like HttpContextWrapper

$$ FIND THE MT Address for HttpContext

r @$t0=0;

.foreach /pS 6 /ps 100 (tokenMT {!name2ee System.Web.dll System.Web.HttpContext})

{

r$t0 = ${tokenMT};

};

$$ LOOP THROUGH ALL HTTP CONTEXTS THAT ARE STILL ON THE HEAP

$$ ----------------------------------------------------------------------------------

.foreach (hc {!dumpheap -mt @$t0 -short})

{

}

Also I'm curious why virtual path extraction is done using nested .foreach as

.foreach /pS 2 (tk {.foreach /pS 9 (token {!do -nofields poi(poi(poi(${hc}+0x10)+14)+8)}){.printf "${token} "}}) {

.printf "${tk}"

};

instead of

.foreach /pS 11 (token {!do -nofields 025c0384}){.printf "${token} \n"}

Am I missing something here?

Many thanks

re: Debugging Script: Dumping out current and recent ASP.NET Requests

PBSurfRider — Tue, 26 Aug 2008 00:58:06 GMT

Can someone please explain how to run this script? I installed WinDbg and saved the script to a txt file. Now what? There's no command line entry anywhere...

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Tess — Tue, 26 Aug 2008 08:59:40 GMT

You would have to attach to an asp.net process (w3wp.exe) or open a dump of a w3wp.exe process and then run the script from the windbg commandline (the command prompt at the bottom of windbg) like this

$><c:\tools\DumpRequests.txt

Replacing the path with your own path

re: Debugging Script: Dumping out current and recent ASP.NET Requests

Kevin Goff — Thu, 03 Dec 2009 16:55:01 GMT

Very helpful. Too bad !aspxpages isnt available for 2.x. Will try and adapt this to the version I'm running.