As nothing exciting has happed in my yard since the last release of Hawkeye I’ve decided to spice up my life and write a new .Net tool: The .Net Deadlock Detector.

The punch line: The .Net Deadlock Detector is the only* tool that is able to detect and report a deadlock inside a running .Net process in a production environment or out of a memory dump.

(* Disclaimer: I couldn’t find any other tool to do this. If you know of one please let me know)

Production environment is an environment in which you don’t (want to) have installed a debugging tool like Visual Studio.

The .Net Deadlock Detector

1. The tool does not require to have the code re-compiled in any way or form, with any external dependencies, nor reference any external library or have you modify your code to use any special type of locks inside your code
2. It works on release builds with no PDB files
3. It works on running processes or previously captured memory dumps
4. It detects deadlocks across multiple threads and returns detailed call-stack and lock usage information
5. It only detect deadlocks in which threads are actively waiting for locks acquired by other threads
6. It does not detect the dining philosophers problem or deadlocks created in combination of time waits + wake/check + lock
7. It has an external dependency on the cdb.exe (part of the the free Debugging Tools for Windows package from Microsoft)
8. It requires absolutely no installation. It an xcopy deployment
9. And best of all it’s free (source code to be published soon)

What’s a deadlock

A deadlock is a situation wherein two or more competing actions are waiting for the other to finish, and thus neither ever does. It is often seen in a paradox like ‘the chicken or the egg‘. (wikipedia)

For example Thread 1 locks resource A, Thread 2 locks resource B, Thread 1 wants resource B and starts a wait on resource B, Thread 2 wants resource A and starts a wait on resource A.

In this moment the two threads are considered deadlocked as each of them owns a resource while trying to acquire another resource owned by a different thread.

1. Two threads, two resources
   
2. Thread 1 acquires resource A
   
3. Thread 2 acquires resource B
   
4. Thread 1 wants resource B and starts waiting for it
   
5. Thread 1 wants resource A and starts waiting for it
   

Now both threads wait for the other one to release their resource.

How does the .Net Deadlock Detector work

The .Net Deadlock detector works by loading the cdb.exe (one of the native Windows Debuggers) on the target process and hooking the input and output streams of it to allow it to send commands and receive output from the debugger.

Then the tool is loading the sos (Son-on-Strike) debugging extensions into the cdb and starts sending commands to the cdb and sos and parse the output.

Then the tool follows a standard procedure in trying to find a managed deadlock by analysing the locks, the threads and the callbacks for each of the threads. As always one of the best examples to understand deadlocks is is Tess’s Deadlock case study.

So more or less the tool is a glorified macro system and command automation that is using standard cdb and sos commands to understand what is happening with the process and does some intensive analysis (including circular references search) to detect the deadlock.

How to “install” the .Net Deadlock Detector

1. First of all before you can use the .Net Deadlock Detector you need to install (on your development machine not on the production machine) the Debugging Tools for Windows from Microsoft
2. Then Download ACorns.Debugging.FindDeadlock.1.0.1.zip and unzip
3. Now you need to copy the cdb.exe from the installation folder (defaults in C:\Program Files\Debugging Tools for Windows\cdb.exe) into the folder where the ACorns.Debugging.FindDeadlock.exe was unzipped
4. You are now ready to use the tool
5. You can now copy this new folder containing (ACorns.Debugging.Cdb.dll, ACorns.Debugging.FindDeadlock.exe and cdb.exe) to your production machine or target machine and start finding your deadlock

(Note: I’d love to deliver the a complete tool but the cdb.exe is not redistributable.)

How to use the .Net Deadlock Detector

If you finally got the right files prepared you are ready to try to find your deadlock.

The tool can be used with a set of command line parameters (exclusive):

ACorns.Debugging.FindDeadlock.exe [/pn=<processname>|/pid=<processid>|/DumpFile=<path to memory dump file>]

• /pn=name of a process
• /pid=id of a proces
• /DumpFile=path to the file

For example to try the tool on the provided demo application start the application then start the deadlock detector with:

ACorns.Debugging.FindDeadlock.exe /pn=ACorns.Debugging.DeadlockTests.exe

Interpreting the results

The tool will output a bunch of less relevant details as it tries to understand the deadlock and at the end it presents a “graphical” representation of the deadlock with some general details about the threads and the locks:

Thread 4 owns a lock named B and waits for lock A. Thread 3 owns the lock A and waits for B.

Then the most relevant part of the analysis comes: the callstack involved in the deadlock. (the callstacks should be read bottom to top with the Using of locks referring to the next (up) method)

Thread 4 has the following callstack:

We can see that method StartThraed2 is using lock B and the Thread2Worker is trying to use lock A.

Thread 3 has the following callstack:

Method StartThread1 is using lock A and Thread1Worker is trying to use lock B.

With all this information at hand you should be able to find and fix your deadlock. Good luck!

If you have a memory dump of a process that has a deadlock that the tool can’t detect please let me know as I’d like to debug it and improve the tool.

Now, start the download of the ACorns.Debugging.FindDeadlock.1.0.1.zip tool and then head to Microsoft to download the Debugging Tools for Windows.

The tool is based on an idea by Tatham Oddie and Paul Stovell. Thanks guys!

During my recent talk on CLR Production Debugging I’ve talked about several interesting attributes that you introduce in your code to make debugging easier. Here is a review of these attributes:

Debugging support attributes

DebuggerStepThroughAttribute & DebuggerNonUserCodeAttrbute

Both attributes do about the same thing: they informs the debugger to not step into that class during normal “Step-Into” debugging. They are generally used on generated code or framework code to avoid the pain on getting into a method that you don’t care about while you debug.

There are very subtle differences between the two attributes:

• DebuggerStepThroughAttribute
  • Can be applied to Classes, Structs, Constructors and Methods
  • Will not step into the method on “Step Into” through the debugger, but allows you to set a breakpoint in the method and the debugger will stop at that breakpoint.
• DebuggerNonUserCodeAttrbute
  • Can be applied to Classes, Structs, Constructors, Methods and Properties
  • Will not step into the method at all even if you have a breakpoint setup or an exception is raised

Sample:

The debugger will not enter in any method declared in this class:

[DebuggerStepThrough()]
public static class ConfigUtils
{
    […]
}

Debugging enhancement attributes

Enhancements attributes are attributes that have no meaning for the CLR but are used by the debugger to improve the way the type/variable is displayed when you look at it in the debugger.

DebuggerDisplayAttribute

Changes the way the class is rendered in the debugger. In the declaration of the attribute you can include multiple properties or fields of you class to be displayed and even call methods on your class and render the result.

You can also include properties or fields of your member properties/fields and your class.

This attribute can be applied to basically almost every construct (classes, structs, enums, fields, properties, delegates and assemblies).

The attribute also supports display based on conditions and basic formatting like “nq” used to strip away quotes from strings.

Samples:

[DebuggerDisplay(“Id={id} Name={firstName} {lastName}”)]
public class Customer
{
    private int id;
    private string firstName;
    private string lastName;

No attributes applied:

Applying the attribute will display:

The following attribute:

[DebuggerDisplay(“Id={id} Name={firstName, nq} {lastName, nq} Orders={Orders.Count}”)]

Renders this:

More details can be found on the MSDN page Using DebuggerDisplay Attribute.

DebuggerBrowsableAttribute

The attribute can be used to let the debugger know how to display (or not to display) specified fields or properties of your class.

For example setting [DebuggerBrowsable(DebuggerBrowsableState.Never)] will make the field invisible in the watch of data tips of the debugger. This is especially useful when you have fields that are exposed as properties and you don’t want to see them twice in the debugger:

Sample:

public class Customer
{
    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    private int id;
    public int Id
    { get { return id; } set { id = value; } }
    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    private string firstName;
    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    private string lastName;

No attributes applied will render this:

(you can see both the fields and the properties)

Applying the attributes will render this:

(only the public properties are visible)

Several other attributes worth having a look at are:

• DebuggerTypeProxyAttribute - allows to specify a proxy class that will be used to display your type. The debugger will instantiate the proxy and ask it to render your class. Can be very valuable when you want to look at complex classes.
• DebuggerVisualizerAttribute - allows you to specify a class to be used to visualize your type.

Happy debugging.

Update: 25/07/2008 20:50: You can see a quick screen-cast of using these attributes here: http://www.acorns.com.au/files/VS_Debugging_Tips_Attributes.wmv (10.6Mb)

If you are based in Sydney or Melbourne come and see my next talk brought to you by Readify RDN.

Debugging the World, starting with the CLR: A session about real-life production debugging from the trenches and how to write better code to help you with debugging.

Leave F5 to the beginners and debug anywhere, anytime: Learn how to debug systems where you can’t install a debugger, release code or third-party code and production machines running live data.  Learn how to debug offline with memory dumps, how to detect deadlocks, debug Windows Services start-up crashes, ASP .NET websites or Smart Client applications.

Sydney

• Wednesday 23 July, 6:00pm – 8:00pm
  Cliftons, Level 6 / 190 George Street,  Sydney
• Thursday 24 July, 10:30am – 12:00pm
  Microsoft, Theatre 1 / 1 Epping Road,  North Ryde

Melbourne

• Thursday 24 July, 6:00pm – 8:00pm
  Cliftons, 440 Collins Street, Melbourne
• Friday 25 July, 7:30am – 9:30pm
  Microsoft, Level 5 / 4 Freshwater Place, Southbank

Don’t know what RDN is?

The Readify Developer Network is the easiest way for you to get a head start in new and upcoming Microsoft technologies, including BizTalk R2, Visual Studio 2008 and Powershell.

Head now to the Readify website and register.

Intro

If you care only a little bit for the security of your ASP.Net application, I am sure that you’ve heard about of Cross-site scripting attacks and of the Microsoft Anti-Cross Site Scripting Library. Html Encoding using AntiXSS is a must for any serious website and it should be mandatory for any web framework (DNN, CS …).

If you didn’t hear about it, then head to it right now: Start here, then go to here and here.

If you don’t want to read about it then head here and here or even better here to read about what it can do it your site, then go back, read about it and implement it.

And if you are still not sure how popular this type of attack can be and how important is to protect then read Samy’s story about how he took down MySpace.com in 24 hours and added more than 1 million friends to himself using a tiny little Xss.

ASP.Net vs AntiXSS

Now that you have a good understanding of what XSS is, you noticed that one of the mitigations that has to be applied is to use HtmlEncode (or other variants) on all rendered data that could have originated from the user.

The main difference between ASP.Net’s HttpUtility.HtmlEncode and AntiXss.HtmlEncode is the fact that the ASP.Net version is using black-listing (encode several known characters) while the AntiXss.HtmlEncode (and the other variants) are using white-listing (encode everything except few not-dangerous characters). You can read more about the differences here.

Big Note: Please don’t even consider to use the ASP.Net HttpUtility.HtmlEncode as there is a reported, Won’t Fix bug reported about it that could become critical one day. Always use the AntiXss for any type of encoding.

What to encode

Everything containing data originating from the user (or data not owned by you and to be known to be secure). Better encode more than less.

Here is non-comprehensive list:

• Names: User Names, First Name, Last Name …
• Personal details (addresses, emails)
• Urls
• Subject lines, content of posts, emails, website or email feedback
• Links to Images and avatars
• User profiles and signatures

How to use Anti Xss:

Basic encoding for Labels, Literals or other controls:

Insecure:

lblEmail.Text = customer.EmailAddress;

Secure:

lblEmail.Text = AntiXss.HtmlEncode(customer.EmailAddress);

This type of code looks ok and it’s not that hard to write and to verify that your application is always using encoding.

However if you use some type of data binding you have to take a much longer route and change your code from something simple like:

Insecure:

<ItemTemplate>
    Description: <%# Eval(“Description”) %>
</ItemTemplate>

To this:

Secure:

<ItemTemplate>
    Description: <%# AntiXss.HtmlAttributeEncode ( DataBinder.Eval( Container.DataItem,“Description” ).ToString() ) %>
</ItemTemplate>  

One more resources worth having at hand for tests is the XSS (Cross Site Scripting) Cheat Sheet. Don’t try to enter this via your UI and say “hey, you can’t enter them” so I’m secure because it’s just a matter of time before someone enters them in your database.

For a real test enter the examples from this page directly in your database (as user names, customer names or user profiles for example) and see how well your website works.

Questions:

• Do you know what is the difference between an asp:Label and an asp:Literal?
• Do you know when to use one and when to use the other?

If you do, don’t read, if you don’t keep on reading:

Differences:

Label:

ASP.Net:

<asp:Label ID=”messageText” runat=”server” meta:resourcekey=”messageTextResource1″ />

Rendered HTML:

<span id=”ctl00_Main_ctl00_messageText”>An email has been sent to ‘gigi@gigi.com’.  </span>

Literal

ASP.Net:

<asp:Literal ID=”messageText” runat=”server” meta:resourcekey=”messageTextResource1″ />

Rendered HTML:

An email has been sent to 'gigi@gigi.com'.

As you can see an asp:Literal does not generate a <span> tag. This is the main difference.

Real life scenario:

When you embed a tag into another tag you should be aware of the validity of the generated code. I know most of us don’t (yet) target to generate any valid XHTML code it would be nice to get this first time around, so writing correct code in the first place should be important for us.

If you have the following pattern:

ASP.Net:

<h2><asp:Label ID=”lblSomeTitle” runat=”server” meta:resourcekey=”lblSomeTitleResource1″></asp:Label></h2>

Rendered HTML:

<H2><span id=” ctl00_Main_ctl00_lblSomeTitle”>Step 2 of 3</span></h2>

This is invalid HTML as per XHTML 1.0 Strict or XHTML 1.1 Strict.

Not only we generate too much code (we have an extra Span with an id for no valid reason) we are also breaking standards. IE6, IE7 accepts it, FF mostly accepts it but it’s wrong.

The fix is simple: Change your code to use a Literal

ASP.Net:

<h2><asp:Literal ID=”lblSomeTitle” runat=”server” meta:resourcekey=”lblSomeTitleResource1″></asp:Literal></h2>

HTML:

<H2>Step 2 of 3</h2>

Almost the same code, much better and smaller HTML.

When to use which:

1. Use Labels when you need to set a CSS class (errors or so)
2. Use Labels when you have references from JavaScript to your label.
3. Use Labels when they represent Field set labels with an AssociatedControlID set
4. Use Literal when you need to display data that the user has originally entered (names, emails…) and set the Mode=”Encode” attribute to automatically Html Encode the rendered data to help avoiding CSS injection attacks
• An even better approach is to use the AntiXSS library and encode your un-trusted strings before setting them into the label/literal.
5. Use Literal in every other scenario

We all know that “magic values” can be bad but we still use them. Sometimes we need them to represent specific states like not initialised, or almost initialised or some other type of placeholder. The simple fact that we still see magic values in code in every project it means developers still use them.

Anyway, one day we had a problem on one of our views and we traced the problem to some wrong checks for the magic value of a specific id. We fixed the problem and also changed the “magic” value from the “magic 0 (zero)” to the less magic and obvious “-1”. We thought we fixed the problem until we discovered that the code had some tests not using the constant but checking directly against zero.

What we learned:

1. If you need to use a magic value to represent a specific “non-existent” information NEVER user 0 (zero) or default(T). Zero is the default for an integer so your might hit your “magic” value even in the scenarios that you don’t expect.
2. Never assume that if you could parse a string into an integer the value you just parsed is a valid value. We parsed a zero and the code simply assumed that if the parse worked the value is good. The parse worked with zero and the code did a (zero – 1) then referenced an array. It failed. Always validate the results of the parse.
3. If you need to check against a magic value ALWAYS check against the constant and NEVER against the magic value itself.
4. Obviously, this code:

   private const int Constants.ValueNotInitialised = 0;
   _someId = Constants.ValueNotInitialised;
   if (_someId == 0) { … }

   will fail when we modified Constants.ValueNotInitialised to be -1 and not zero.

A nice way to make sure none of your (non-string) magic values are safe and never used the wrong way is to declare your (non-string) constants using a non-fixed value:

#if DEBUG
    private readonly int MyMagicConstant = -Environment.TickCount;
#else
    private const int MyMagicConstant = -1;
#endif

On every debug run you’ll get a new MyMagicConstant value.

Update/Delete operations have no reason to return the ID of the item they update/delete.

You already know that ID when you asked for the operation. Returning it makes it redundant.

Wrong:

long UpdateCustomerDetails(CustomerDetails customerDetails);
long DeleteCustomerDetails(CustomerDetails customerDetails);

The delete method is also wrong because it should only require the ID to be able to delete.

Right:

void UpdateCustomerDetails(CustomerDetails customerDetails);
void DeleteCustomerDetails(long customerDetailsId);

There is no reason to return anything out of an Update or Delete methods. If it helps with code you can return the updated object out of the Update method to avoid an extra call:

CustomerDetails UpdateCustomerDetails(CustomerDetails customerDetails);

Returning a bool would be wrong as “false” would have no meaning and would contain no error details about why the Update or Delete failed (plus I’m sure you will forget to verify the result).

A re-post of my previous post which was no only wrong but also misleading.

Always include the schema name inside your queries.

Note: Schema Name is Mandatory in the Stored Procedure name.

CREATE PROCEDURE Customers.usp_CustomerDetails_GetCustomer(…)

Wrong:

SELECT CustomerName FROM CustomerDetails

Right:

SELECT CustomerName FROM Customers.CustomerDetails

As per MSDN (http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx), Query plan reuse, Factors that affect plan-reuse, point 10:

Batches with unqualified object names result in non-reuse of query plans. For example, in “SELECT * FROM MyTable”, MyTable may legitimately resolve to Alice.MyTable if Alice issues this query, and she owns a table with that name. Similarly, MyTable may resolve to Bob.MyTable. In such cases, SQL Server does not reuse query plans. If, however, Alice issues “SELECT * FROM dbo.MyTable”, there is no ambiguity because the object is uniquely identified, and query plan reuse can happen. (See the uid column in sys.syscacheobjects. It indicates the user ID for the connection in which the plan was generated. Only query plans with the same user ID are candidates for reuse. When uid = -2, it means that the query does not depend on implicit name resolution, and can be shared among different user IDs.)

Thanks everyone for the quick replies.

Tags: ImproveYourCode, TSQL

If you use multiple schemas to differentiate between business parts of your application, then never include the schema name inside your queries unless absolutely necessary.

This would assure that if you copy/paste stuff around or move/copy a stored procedure into a different schema, you always use the current schema and not (by mistake) reference the wrong schema. You’d better see it fail because you got the schema wrong than work the with the wrong data.

Note: Schema Name is Mandatory in the Stored Procedure name.

CREATE PROCEDURE Customers.usp_CustomerDetails_GetCustomer(…)

Wrong:

SELECT Customers.CustomerDetails.CustomerName

      FROM Customers.CustomerDetails

Right:

SELECT CustomerName

      FROM CustomerDetails

When I’ve started in my current project more than eight months ago we’ve decided we want to do it right! We wanted to do the best we can to get not only a quality product but to have also high quality code.

I think a quality product is not one that is only well tested but also well coded, maintainable, easy to change when need arises (Agile?), testable, consistent, have as little plumbing code as possible and following proper design patterns in every step.

I’ve seen way to many times projects where code quality degrades with time and most of the times it’s for one of the following reasons:

1. project evolves, people develop new patters and don’t retrofit them to existing code so old code is different than new code
• The risk here is even greater if developers introducing new patters don’t let the other developers know about them or standardise the new patterns and you get mixed code with mixed coding patterns or styles.
2. as developers are added to the team that are not correctly integrated and start to develop their own patters (and practices)
3. pressure to finish requirements in time makes people take shortcuts with “I’ll fix it later” type of approach

So one of the things we started to have in this project is an “Improve Your Code” email that is used to tell all developers about new patterns that we start to apply, simple ways to write better code or simply enforcement(s) we want to put in place to ensure consistency and simply better code.

One other type of email we had was “Tip of the day” offering some cool stuff that can make your life as a developer simpler, better or quicker.

Now, the project is winding up so I thought I’d share some of our Improve Your Code and Tip Of The Day emails we had. Some might be obvious, some might be odd or debatable but even so they might be worth sharing.