jaredpar's WebLog : CLR

Disabling JIT optimizations while debugging

Jared Parsons — Fri, 29 Aug 2008 15:00:10 GMT

If you've ever been debugging a managed app, only to be unable to evaluate any of the locals or parameters because the code was "optimized", check out the article below. It shows a quick trick to disable optimizations by way of a .ini file. This is great because it doesn't force you to recompile the application and takes only seconds to implement.

The short version is create an .ini file (i.e. myapp.ini) with the following contents.

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

This has really saved me time debugging recently. It's been blogged about by several others but given that I've had to search for this solution 3 times in as many weeks, I figured blogging about it would make it easier to find next time :)

http://msdn.microsoft.com/en-us/library/9dd8z24x.aspx

CLR Changes in 3.5 SP1

Jared Parsons — Fri, 22 Aug 2008 15:00:41 GMT

If you haven't come across this post yet about inlining changes in 3.5 SP1 it's a good read. The short version is, value types will have better performance.

http://blogs.msdn.com/clrcodegeneration/archive/2007/11/02/how-are-value-types-implemented-in-the-32-bit-clr-what-has-been-done-to-improve-their-performance.aspx

CLR Memory Model

Jared Parsons — Thu, 17 Jan 2008 20:16:48 GMT

Internally and externally I see a lot of questions about the .Net Memory Model. I think a lot of the confusion comes from the specs. Mainly that there are really two of them.

The first is the ECMA CLI Memory Model (Partition 1, Section 12). This standard introduces a relaxed memory model which, IMHO, makes multi-threading program a bit difficult. For instance it allows for write reordering which can be quite confusing to programmers (and result in very hard to track bugs).

The CLR 2.0 Memory Model is a stricter version of the EMCA model. There are two excellent sources of information on the more strict version.

http://msdn.microsoft.com/msdnmag/issues/05/10/MemoryModels/ - Vance Morrison's detailed article on multi-threaded apps and locking techniques. He goes into a bit of detail on how the ECMA and CLR 2.0 models differ and the justification for making them do so.
http://www.bluebytesoftware.com/blog/2007/11/10/CLR20MemoryModel.aspx - Joe Duffy sums up Vance's article and defines a set of 6 simple rules to the memory model.

For anyone doing multi-threaded programming in .Net, both of these articles are a must read.

IMetaDataImport::GetParamForMethodIndex

Jared Parsons — Mon, 30 Jul 2007 20:09:46 GMT

While investigating a recent bug I found about an interesting return for GetParamForMethodIndex. On a perfectly verifiable assembly, a call to GetParamForMethodIndex was returning a failure code. After some searching I found the return code was CLDB_E_RECORD_NOTFOUND. I was surprised at first because it's a verifiable assembly so how could the record for a parameter I knew existed not be there?

It turns out this is legal. GetParamForMethodIndex returns a mdParamDef token by which you can query for information about a parameter with GetParamProps. This will return the following information about a parameter.

Name of the parameter
Attributes about the param (ByRef, Marshal, etc ...)
Default value

In this particular case the assembly was generated without a parameter name. As it also had none of the information the parameter row was omitted from the metadata. The reason is adding an empty row takes up space and provides no data.

Note you can't reproduce this behavior with ILASM.exe. If you omit a parameter name, ILASM.exe will add one for you and hence generate a parameter row.