Testing Responses to ‘GET’ Requests (The Easy Way)

NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.

Often times, it may become necessary to look at the response received from a ‘GET‘ request to a web server. We can do a little .NET magic to perform this.

Below is an example tested my favorite TV station in Sweden:

[net.Webrequest]::Create(“http://www.svt.se”).GetResponse()

IsMutuallyAuthenticated : False
Cookies                 : {}
Headers                 : {X-UA-Compatible, X-Varnish, Connection, Content-Length…}
SupportsHeaders         : True
ContentLength           : 50827
ContentEncoding         :
ContentType             : text/html;charset=UTF-8
CharacterSet            : UTF-8
Server                  : Apache
LastModified            : 6/22/2014 8:21:33 PM
StatusCode              : OK
StatusDescription       : OK
ProtocolVersion         : 1.1
ResponseUri             : http://www.svt.se/
Method                  : GET
IsFromCache             : False

You can use the command against any URI you wish to test/verify is up and responsive (which is handy for proving/disproving network issues).

Debugging: When Recursive Becomes Recursively Too Much

NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.

Recently, I had a problem with a build environment and, specifically, I was receiving a StackOverflowException.

This is what the exception information looked like from the Application Log perspective:

Faulting application name: <redacted>, version: <redacted>, time stamp: 0x5347902e

Faulting module name: clr.dll, version: 4.0.30319.34014, time stamp: 0x52e0b784

Exception code: 0xc00000fd

Fault offset: 0x00002cf4

Faulting process id: 0x1848

Faulting application start time: 0x01cf815776173165

Faulting application path: <redacted>

Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll

Report Id: b5a7c204-ed4a-11e3-825f-6c3be5144bba

Faulting package full name:

Faulting package-relative application ID:

Not much to go on, right?

I attached adplus (via pmn) and caught the First Chance Exception and process exit dumps. Using the first chance exception dump, I could see (via the stack back-trace) that thread 0 (1eb8) was well over 7,000 frames and that the same objects were repeating on the thread-stack (!dso).

Using this information, I went to the developers of the internal application and they had a compiled fix for me to test and run.

Needless to say, it’s a lot easier to get work done without the StackOverException haunting me

Attached, you’ll find a (heavily-redacted) text file (sort-of) illustrating the recursion in the thread.

Happy debugging! 🙂

stack.txt