Fun with WinDbg

I was looking into a Memory Leak  using a win-32 w3wp memory dump. Looking into the FinalizeQueue, I saw System.Data.DataTableCollection object in Gen2. Based on the hunch, I dumped the method table.

01

Dumped a couple of addresses listed above

02

I looked at the dataset and the _list, which brought me to the _items below.

03

The list of items is actually an Array.

04

Dumping the array and reviewing one of the array element(s) as below.

06

Viewing the value for tablename showed the string below. This is one of the objects used to retain Trace data.

07I am not posting the rest of the table structure, but if you are interested, you are welcome to follow the steps. Trace.axd was still active and ended up disabling it. Now back to looking into the actual issue.

Advertisements

Network Error in Chrome while downloading files

The dev team reported an odd behavior that exhibited only in Chrome. Since MS Excel is a preferred tool to view transactional data for analysis/self-service, we have an Export function within web pages.

Using OpenXMLSDK to stream the data failed with a “Network Error” in chrome. Surprisingly the same functionality worked in Chrome when the website was hosted on IIS 8.5 / .NET 4.5.

I then traced the Request and Response in fiddler. Decoding the response threw the “chunked body did not terminate properly with 0-sized chunk” error. So, I suspected that the Response was being truncated.

Reviewing the .NET code, after writing the memory stream to the HTTP Response object,  we had a Response.Close. It looks like Response.Close drops the last chuck (in IIS prior IIS versions) causing Chrome to throw the network error. It doesn’t explain how Firefox and IE were able to keep the pipe open to receive the last chunk (need to dig into this further using wireshark).

Removed the Response.Close and all good now.

Identify Locked objects that are Invalid

Here is a query that is useful to identify locks on objects that are Invalid, preventing the object from being recompiled. These sessions need to be identified and stopped or killed.

with src as
(
    select sid, ao.owner, object, status
                 from v$access v, all_objects ao
                where ao.object_name = v.object
                  and ao.status= 'INVALID'
                )
select v.sid,
       src.owner,
       src.object
       serial#,
       username,
       osuser,
       logon_time,
       program,
       action,
       src.status
  from v$session v, src
where v.sid = src.sid;

Troubleshooting – Erratic Load Balanced Web Application behavior

Have you ever run into situations where the Customer reports an issue, but the Dev Team is not able to reproduce it. Well, I have had several of these and sometimes one of the Web Server is configured differently than the rest in a Load Balanced environment. Sometimes these behavior also exhibit when we actually deploy a new farm or add new servers to an existing farm.

Recently a customer reported that attachments on a particular customer portal were not being viewable. Sure enough, when we tested this issue initially, it worked for us. We were able to quickly able to use this technique to isolate the server and then add the missing mime type.

The actual issue/behavior can be identified using Fiddler or the Developer Tools. Identifying the server that is causing the erratic user behavior is key to either quickly resolving or removing the server from the farm for offline resolution.

When adding each server to the farm, add a HTTP Response Header that uniquely identifies the server as shown in the screenshot below. Don’t include any sensitive details that might compromise your server.

screen_shot_2016-11-11_at_4_19_00_pm

Shown below is a Network Capture using Firefox / Firebug, but the same steps apply to Fiddler and other Developer Tools. After you have captured enough events to reproduce the issue, sift through the requests to find the offending request, identify the HTTP Response Header and you will be able to locate the server.

screen_shot_2016-11-11_at_4_03_53_pm

Keep in mind that the Developer Tools have limitation to the total number of requests / responses that can be captured without degrading performance. fiddler seems to be a better tool of choice for this particular debugging scenario.

It’s possible to programmatically set the HTTP Response Headers, but that’s a different topic.