softlogger Latest Articles ::Design-Architecture

Things in Metadata that are missing in Reflection

Mike Stalls blog — 2008-03-15T00:00:00

System.Reflection is a high-level way of describing Types in .NET targetted at managed code consumers. The API is easy to use, but does not expose all the information that's actually present and affecting decisions.

For example, Reflection does not expose TypeRef, MemberRef, AssemblyRef, or other Ref tokens. These tokens are references to things in other assemblies. Reflection just resolves them for you (potentially invoking an event to get help from your app) and hands back the resolved object.

Similarly, reflection is also missing TypeSpecs. TypeSpecs are just binary signature blobs that describe compound types (arrays, generics, etc). Reflection will parse the blob and resolve it to a real System.Type.

This entry is not a complete list of all things missing in reflection; nor am I going to get into the other problems in reflection here. For now, I'll just look at TypeRefs...

Imagine you have a class that inherits from a type in another assembly. At the metadata level, the base type is described with a TypeRef token.

1. Practically, that means you could use reflection to inspect what a base type actually bound to, but not what it was supposed to bind to (as described in the original assemblyRef).

2. Another issue is that when you have a high-level API (Reflection) that loses information over a low level API (IMetadataImport), you risk that the high-level API won't be able to talk to the low level API because it may not be able to provide it with the information the low level API requests.

3. In related trivia, ILDasm can print TypeRef, TypeSpec tokens:

//000010:         Console.WriteLine("Hi!" + arg);
IL_0001: ldstr      "Hi!" /* 70000001 */
IL_0006: ldarg.0
IL_0007: call       string [mscorlib/*23000001*/]System.String/*01000012*/::Concat(string,
                                                                                      string) /* 0A000010 */
IL_000c: call       void [mscorlib/*23000001*/]System.Console/*01000013*/::WriteLine(string) /* 0A000011 */
IL_0011: nop

So the inability to get the raw unresolved tokens from Reflection would prevent you from writing ILDasm on reflection that could print the above snippet.

High memory usage with usercontrols in IE (using Debug Diag)

If broken it is, fix it you should — 2008-02-19T00:00:00

I was helping a colleague with an interesting case yesterday concerning a memory leak in IE when using winforms usercontrols.

We got a nice little repro with a very basic user control that displayed a picture and each time the page was refreshed it appeared to leak quite a bit of memory,
and inducing a garbage collection had no effect on the memory.

I started off with setting it up on my machine, and then I used Debug Diag 1.1 to track down the leak... Debug diag is not all that great for managed/.net memory leaks since the GC manages the memory for you as I'll show later... but I figured that since I had a repro it was worth a try...

Some notes on how debug diag works:

Debug diag is basically a debugging helper that allows you to take memory dumps of a process or set up different rules like crash rules, memory rules, exception rules and hang rules. It also has a leaktracking feature which I will talk about in more detail in a bit. It also has a number of scripts (and allows you to write your own scripts) for automated analysis. Basically you load up a dump file in debug diag (can even be a dump file gathered with windbg) and choose the script you want (hang, crash or memory) and then Debug Diag will produce a report with stacks and information about what it thinks is the problem.

The downloads page has very nice information concerning how you use Debug Diag to troubleshoot different issues.

Debug diag and memory leaks:

This excerpt is copied straight from the downloads page:

To debug memory and handle usage, use one of the following:
1. Create a leak rule against the process in question. The leak monitoring feature will track memory allocations inside the process. Tracking is implemented by injecting a DLL (leaktrack.dll) into the specified process and monitoring memory allocations over time. When configuring a memory and handle leak rule, you can specify memory dump generation based on time or memory usage.
2. Using the “processes” view, right-click the process in question and select the “monitor for leaks” option. When the process has grown to the suspected problem size, manually dump the process by right-clicking on the same process in the processes view and choosing the “Create Full Userdump” option.

In esscence what this means is that any memory that has been allocated and not been de-allocated will be reported as a possible leak. It is very important that you turn on leaktracking for a sufficient amount of time (or raise in memory usage) that you can weed out the real leaks for the stacks that allocated memory recently and just hasn't had the time to de-allocate it.

Another item worth mentioning is that by default debug diag will not track any stacks for the first 15 minutes (to avoid mixing in all the allocations made on startup which are not really leaks but just getting you up to baseline memory usage).

Debugging the issue:

I started up by browsing to the html page that instantiated the user control so that i had everything loaded and then I started up debug diag and then I followed these steps to get a memory dump.

1. Since my repro was very quick (way less than 15 minutes) I went in to "tools/options and settings" in debug diag and checked the box "Record call stacks immediately when monitoring for leaks..." under the preferences tab.

2. In the process tab I found my iexplore.exe process, right clicked it and choose "Monitor for leaks"

3. I refreshed the page like crazy to get a a leak of around 200 MB in the IE process

4. Then I right clicked the iexplore.exe process under the process tab again and choose "Create Full Userdump"

Since leaktrack.dll stores all the info about the allocated memory in memory there is a slight overhead that leaktrack itself creates. It is usually not all that significant but I wanted to mention it in case you ever look at a memory analysis and wonder what all the memory on the leaktrack heap is doing.

My next step was to go in to debug diag under the advanced analysis tab and choose "Add data files" to get my dump analysed, and then I chose "Memory Preassure Analyzers" from the analysis scripts and hit "Start Analysis". After that it is time for a coffee break:)

Back from coffee, debug diag has finished running the analysis and popped up IE with an mhtml file with the results and on top it showed the following...

And a little bit further down on the page under leaktracking summary it had this:

So from this we can see that we have been tracking for 45 seconds (way shorter than I would normally recommend but this was a quick leak). We have allocated 213 MB and the biggest memory user seems to be GdiPlus.dll (192,56 MB)

Note that mscorwks.dll has used up 20,73 MB. If you have a .net memory leak or high .net memory usage you won't really see the individual allocators here. All .net leaks will show up as a high amount of outstanding allocations from mscorwks.dll which is why I mentioned earlier that tracking .net leaks with debug diag doesn't work all that well.

If I click on GdiPlus.dll I will get to a section in the html file with more details about the GdiPlus allocations, including stacks which is extremely useful since it tells you where/why all this memory is allocated...

Call stack sample 1

Address   0x0bc00000 
Allocation Time   00:00:11 since tracking started 
Allocation Size   5,49 MBytes 




Function   Source   Destination 
GdiPlus!GpMemoryBitmap::AllocBitmapData+71   
GdiPlus!GpMemoryBitmap::AllocBitmapMemory+26   
GdiPlus!GpMemoryBitmap::BeginSink+14b    
GdiPlus!GpJpegDecoder::CallBeginSink+6c       
GdiPlus!get_sos+285       
GdiPlus!GpJpegDecoder::Decode+b7       
ntdll!NtQueryVirtualMemory+12       
kernel32!VirtualQueryEx+1d    
mscorwks!RuntimeMethodHandle::SerializationInvoke+36       
System.RuntimeMethodHandle.SerializationInvoke(System.Object, System.SignatureStruct, System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)       
System.Reflection.RuntimeConstructorInfo.SerializationInvoke(System.Object, System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)       
System.Runtime.Serialization.ObjectManager.CompleteISerializableObject(System.Object, System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)
System.Runtime.Serialization.ObjectManager.FixupSpecialObject(System.Runtime.Serialization.ObjectHolder)
System.Runtime.Serialization.ObjectManager.DoFixups()
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(...)       
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(...)
System.Resources.ResourceReader.DeserializeObject(Int32)
System.Resources.ResourceReader.LoadObjectV2(Int32, System.Resources.ResourceTypeCode ByRef)
System.Resources.ResourceReader.LoadObject(Int32, System.Resources.ResourceTypeCode ByRef)
System.Resources.RuntimeResourceSet.GetObject(System.String, Boolean, Boolean)
System.Resources.RuntimeResourceSet.GetObject(System.String, Boolean)
System.Resources.ResourceManager.GetObject(System.String, System.Globalization.CultureInfo, Boolean)
System.Resources.ResourceManager.GetObject(System.String, System.Globalization.CultureInfo)
LeakControl.Properties.Resources.get_SomePicture()       
LeakControl.LeakControlTest.InitializeComponent()
mscorwks!CallDescrWorker+33 
...

This call stack sample tells us that 11 seconds in to the tracking this stack allocated 5,49 MB in the GdiPlus!GpMemoryBitmap::AllocBitmapData which is extremely interesting in this case since this method was the one that allocated the 192,26 MB according to the summary.

Looking a bit further down the stack we can see that this is done because we load up some picture resource in the InitializeComponent method for the control. Basically this means that this is something that happens every time the control is loaded.

Turns out that the picture it is loading up is pretty large so that is why we see the 5 MB here (my guess though is that this is done on purpose to show the leak faster). Anyways, this begs the question, why is this bitmap not released? If the control goes out of scope GdiPlus should release this memory as part of the destruction of the control.

Debugging with windbg:

The next step for me was to load up the dump in windbg to figure out what was up with these controls.

Running !dumpheap -stat I found that there were 36 controls in memory (same amount as the times I had refreshed)

7912d7c0         66         5,884 System.Int32[]
07b9719c         36         6,768 System.Windows.Forms.PictureBox
7911bbd0        289         8,092 System.Security.SecurityElement
07b54664         36         8,208 LeakControl.LeakControlTest
07b5dc08         82         8,604 System.Windows.Forms.PropertyStore+ObjectEntry[]
79120830        226         9,944 System.Reflection.Emit.OpCode
79104368        491        11,784 System.Collections.ArrayList
79109778        289        16,184 System.Reflection.RuntimeMethodInfo
7912d9bc        101        23,448 System.Collections.Hashtable+bucket[]
7912d8f8        862        79,784 System.Object[]
790fd8c4      6,150       357,664 System.String
7912dae8        100    20,847,312 System.Byte[]
Total 13,093 objects, Total size: 21,516,680

So something is obviously keeping these controls alive...

I dumpped them all out using !dumpheap -mt 07b54664

0:000> !dumpheap -mt 07b54664         
Using our cache to search the heap.
   Address         MT     Size  Gen
...
05300d84 07b54664      228    2 LeakControl.LeakControlTest 
05301910 07b54664      228    2 LeakControl.LeakControlTest 
0530237c 07b54664      228    2 LeakControl.LeakControlTest 
05302de8 07b54664      228    2 LeakControl.LeakControlTest 
05303854 07b54664      228    2 LeakControl.LeakControlTest 
053042c0 07b54664      228    2 LeakControl.LeakControlTest 
...
Statistics:
      MT    Count    TotalSize Class Name
07b54664       36        8,208 LeakControl.LeakControlTest
Total 36 objects, Total size: 8,208

And then I picked one at random and ran !gcroot on it to see where it was rooted (i.e. what was holding it alive), and among other things I saw this...

0:000> !gcroot 05302de8 
...
DOMAIN(04731890):HANDLE(Strong):78416d0:Root:  053031f8(System.Runtime.Remoting.ServerIdentity)->
  053031e8(System.Runtime.Remoting.ObjectHandle)->
  05302de8(LeakControl.LeakControlTest)

Solution

So it is rooted in a System.Runtime.Remoting.ObjectHandle in a ServerIdentity object, whatever that means;)

Then I searched for "System.Runtime.Remoting.ObjectHandle usercontrol" and found this... KB 555916 Memory leak in .NET Managed Usercontrols

I just have to stop here and say WOW!!! I really didn't have a clue that these types of kb article. And when I say this type I mean 1. Community Solutions Content and 2. Really nice debugging summaries... Kudos to Alvin Bruney who wrote the article, love it:)

So anyways, it turns out that the reason these objects (and thus the bitmaps) stick around is because remoting is used to communicate between the IE domain and the domain associated with the security zone of the user control. The remoting lease is set in this case to 5 minutes by default which means that these objects will stick around until the lease is up to avoid having to recreate them for further communication between the domains.

You can lower the lease time but as Alvin mentions in the article that may affect the performance. Typically though it should not be an issue since these types of controls are generally not that memory consuming, but if it is, and needs to be, then lowering the lease time is probably the best option.

Btw, I will try to get the memory lab review done today or tomorrow so we can get on with the next lab which will be a high CPU perf issue.

Laters

Tess

Dealing with Exceptions in a Future

jaredpars WebLog — 2008-02-11T00:00:00

Besides waiting, the another important issue when dealing with Futures is how to deal with exceptions thrown by the user specified code.

Option 1: Ignore the Exception

Don't take any actions in the future code and force users to write exception free code. IMHO this is not the best way to approach the problem. The code will be running in the thread pool and unhandled exceptions in the thread pool result in the taking down of an appdomain/process. In addition Futures are designed to be simple. Adding a try/catch around every lambda is not practical and/or readable.

Option 2: Catch and Swallow

Catch the exception on the background thread and swallow it. Silently failing is in many cases worse than actually crashing. Behavior will become flaky and the user/developer won't have any indication there is an error.

Option 3: Re-throw the Exception when Wait is called

Catch and save the exception when it occurs on the background thread. Then when Wait() is called on a Future re-throw the exception. This makes exception handled deterministic.

It's also very similar to the exception handling semantics of calling a method. The only difference is that users must handle the exception at the point of method completion vs invocation. For synchronous methods this is just the same point.

The big downside to this approach is the stack trace information is lost from the exception. Re-throwing will instead add the stack trace at the point of the re-throw. Not having stack trace information makes it very difficult to actually track down the source of an error.

Option 4: Re-throw a new Exception when Wait is called

This is very similar to Option #3. The only difference is when the user calls Wait, throw a new exception and make the original exception an inner exception of the new one. We'll call this exception FutureException. This has the advantages of option 3 and in addition will preserve the stack trace information from the original exception.

There is a downside to this approach though. Users can no longer have different catch blocks to handle the different types of exceptions that can be thrown.

            try
            {
                Future.Create(() => SomeOperation());
            }
            catch (IOException ex)
            {
                // ...
            }
            catch (InvalidOperationException ex)
            {
                // ...
            }

Instead the user can only catch a Future exception and examine the inner result to take corrective action.

            try
            {
                Future.Create(() => SomeOperation());
            }
            catch (FutureException ex)
            {
                var type = ex.InnerException.GetType();
                if (type == typeof(IOException))
                {
                    // ...
                }
                else if (type == typeof(InvalidOperationException))
                {
                    // ...
                }
            }

This doesn't actually limit any functionality but users may find the syntax uncomfortable. VB users can still do exception filtering but this is not at option for C# users.

        Try
            Future.Create(Function() SomeOperation())
        Catch ex As Exception When ex.InnerException.GetType() Is GetType(IOException)

        End Try

The FutureException class is straight forward. A simple implementation of the exception snippet will do the trick.

    [global::System.Serializable]
    public class FutureException : Exception
    {


        public FutureException() { }
        public FutureException(string message) : base(message) { }
        public FutureException(string message, Exception inner) : base(message, inner) { }
        protected FutureException(
          System.Runtime.Serialization.SerializationInfo info,
          System.Runtime.Serialization.StreamingContext context)
            : base(info, context) { }
    }

ASP.NET Hang and OutOfMemory exceptions caused by STA components

If broken it is, fix it you should — 2008-01-30T00:00:00

I have talked about blocked finalizers before and this issue is a special case of blocked finalizers where we are not really finalizing a .NET object but rather cleaning up all Com Callable Wrappers (CCWs) and getting stuck doing that.

Problem description:

The situation we are facing is that the ASP.NET process starts to go hey wire both in response times and in memory usage. All of a sudden memory just starts growing and growing and we need to figure out why.

Troubleshooting:

We took a memory dump when memory usage was high (~837 MB private bytes which we could see from the dump size) with adplus -hang -pn w3wp.exe, but really the dump could have just been taken anytime after the memory started rapidly increasing.

Around ~469 MB of the memory are pure .net objects (as we can see from GC Heap Size in !eeheap -gc) and the large object segments are minimal so there isn't a whole lot of large objects...

0:015> !eeheap -gc
Number of GC Heaps: 2
------------------------------
Heap 0 (000db128)
generation 0 starts at 0x33bc0c98
generation 1 starts at 0x338bc070
generation 2 starts at 0x02410038
ephemeral segment allocation context: none
 segment    begin allocated     size            reserved
00176d48 7b451688  7b467f9c 0x00016914(92,436) 00003000
000e96e0 7a721784  7a74248c 0x00020d08(134,408) 00003000
000e1ee0 790d6358  790f5800 0x0001f4a8(128,168) 00003000
02410000 02410038  0640f130 0x03fff0f8(67,105,016) 01fdf000
17d80000 17d80038  1bd69da8 0x03fe9d70(67,018,096) 0000e000
2a070000 2a070038  2e063b38 0x03ff3b00(67,058,432) 00009000
321d0000 321d0038  33caad50 0x01adad18(28,159,256) 01cb6000
Large object heap starts at 0x0a410038
 segment    begin allocated     size            reserved
0a410000 0a410038  0a4234f0 0x000134b8(79,032) 01fdf000
Heap Size  0xdb215fc(229,774,844)
------------------------------
Heap 1 (000dc138)
generation 0 starts at 0x38146e28
generation 1 starts at 0x37e5033c
generation 2 starts at 0x06410038
ephemeral segment allocation context: none
 segment    begin allocated     size            reserved
06410000 06410038  0a40ee00 0x03ffedc8(67,104,200) 01fdf000
1bd80000 1bd80038  1fce8e6c 0x03f68e34(66,489,908) 00077000
26070000 26070038  2a05b85c 0x03feb824(67,024,932) 03ff7000
36510000 36510038  38a8cc68 0x0257cc30(39,308,336) 01a7c000
Large object heap starts at 0x0c410038
 segment    begin allocated     size            reserved
0c410000 0c410038  0c410048 0x00000010(16) 01fff000
Heap Size  0xe4d0060(239,927,392)
------------------------------
GC Heap Size  0x1bff165c(469,702,236)

If we dump out the managed heaps with !dumpheap -stat the most memory consuming objects are shown below...

I have grouped them like this:

Red - UI related items
Green - Data related items
Black - Regular items like string, char[] etc. (note, these are very likely linked to the data related or ui related items as well)

...
0ec99d1c     38,575       617,200 Oracle.DataAccess.Client.OracleParameterCollection
68a35670     11,135       623,560 System.Web.UI.WebControls.HiddenField
0ec693f4        848       630,912 ASP.aspx_mypage_aspx
7a742f30     37,751       755,020 System.ComponentModel.EventHandlerList+ListEntry
68a652e8     73,493       881,916 System.Web.UI.WebControls.BorderStyle
7a753288     55,789       892,624 System.Collections.Specialized.NameObjectCollectionBase+NameObjectEntry
653c5b14     15,019       961,216 System.Data.DataRow
0ec96d64     34,834       975,352 Oracle.DataAccess.Client.MetaData
79124670      3,936       985,932 System.Char[]
68a2c690     14,989     1,019,252 System.Web.UI.HtmlControls.HtmlTableRow
653c3e94      7,703     1,140,044 System.Data.DataColumn
653d61c0      1,137     1,177,932 System.Data.RBTree`1+Node[[System.Data.DataRow, System.Data]][]
0ec9bd4c     36,872     1,179,904 Oracle.DataAccess.Client.OracleRowUpdatingEventHandler
10fa17dc     13,293     1,329,300 MyControls.MyCheckBox
791052bc    117,882     1,414,584 System.Int16
68a37884     17,827     1,426,160 System.Web.UI.WebControls.Label
79104f64    151,695     1,820,340 System.Boolean
68a3e7a0    155,042     1,860,504 System.Web.UI.WebControls.FontInfo
0ec634fc     25,512     2,040,960 MyControls.MyTextBox
68a7d910     26,604     2,128,320 System.Web.UI.WebControls.Button
68a2f704    105,846     2,540,304 System.Web.UI.CssStyleCollection
0ec96c84     98,136     2,747,808 Oracle.DataAccess.Client.ColMetaRef
68a2f694    202,158     3,234,528 System.Web.UI.AttributeCollection
79103b6c     75,803     3,335,332 System.Threading.ReaderWriterLock
68a2f7fc     94,486     3,401,496 System.Web.UI.ControlCollection
0ec9ae14     36,872     3,687,200 Oracle.DataAccess.Client.OracleDataAdapter
68a6423c    150,531     4,816,992 System.Web.UI.WebControls.FontUnit
68a2c918     85,276     5,457,664 System.Web.UI.HtmlControls.HtmlTableCell
0ec6322c     69,949     5,595,920 MyControls.MyLabel
0ec9b404     36,872     5,604,544 Oracle.DataAccess.Client.OracleCommandBuilder
68a31bdc    476,216     5,714,592 System.Web.UI.IndexedString
68a884a0     96,876     5,812,560 System.Web.UI.LiteralControl
68a7ca28    365,718     5,851,488 System.Web.UI.Pair
7ae75d7c    252,629     6,063,096 System.Drawing.Color
68a85ea0    392,440     6,279,040 System.Web.UI.StateBag
0ec9975c     40,043     6,406,880 Oracle.DataAccess.Client.OracleCommand
68a7745c    159,338     7,010,872 System.Web.UI.WebControls.Style
790fea70    139,382     7,805,392 System.Collections.Hashtable
68a92e2c    177,707     7,819,108 System.Web.UI.Control+OccasionalFields
68a86004    331,329     7,951,896 System.Web.UI.WebControls.Unit
790fed1c    698,227     8,378,724 System.Int32
791036b0    401,277     9,630,648 System.Collections.ArrayList
000daa58        296    10,030,596      Free
7a747bac    378,430    10,596,040 System.Collections.Specialized.ListDictionary
7a747ad4    608,586    12,171,720 System.Collections.Specialized.HybridDictionary
7a747c78    837,066    16,741,320 System.Collections.Specialized.ListDictionary+DictionaryNode
79124418      4,555    17,726,104 System.Byte[]
0ec9a664    165,910    17,918,280 Oracle.DataAccess.Client.OracleParameter
68a131b4  1,758,380    28,134,080 System.Web.UI.StateItem
79124228    705,459    31,266,188 System.Object[]
791242ec    142,053    43,835,496 System.Collections.Hashtable+bucket[]
790fa3e0  1,032,738   116,787,020 System.String
Total 11,377,657 objects, Total size: 469,685,264

So here, most of the memory is going to either datarelated items, ui related items or generic objects. In short, let's say we got rid of all the ASP.aspx_mypage_aspx objects for example, then it is very likely that we would get rid of most of the UI related items. And if we got rid of all the DataSets in the dump we would probably get rid of all or most of the datarelated items...

If I focus on the aspx pages and dump them out... and then !gcroot a few of those aspx pages to see where they are rooted we get this...

0:000> !dumpheap -mt 0ec693f4        
Using our cache to search the heap.
   Address         MT     Size  Gen
0251f0ec 0ec693f4      744    2 ASP.aspx_mypage_aspx 
02555c90 0ec693f4      744    2 ASP.aspx_mypage_aspx 
0259cfc0 0ec693f4      744    2 ASP.aspx_mypage_aspx 
025d3ca0 0ec693f4      744    2 ASP.aspx_mypage_aspx 
0260a85c 0ec693f4      744    2 ASP.aspx_mypage_aspx 
02641294 0ec693f4      744    2 ASP.aspx_mypage_aspx 
02677f44 0ec693f4      744    2 ASP.aspx_mypage_aspx 
026aeaf4 0ec693f4      744    2 ASP.aspx_mypage_aspx 
0270622c 0ec693f4      744    2 ASP.aspx_mypage_aspx
... 


0:015> !gcroot 0251f0ec 
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 15 OSTHread a28
Scan Thread 19 OSTHread 43c
Scan Thread 20 OSTHread b94
Scan Thread 21 OSTHread 15c
Scan Thread 13 OSTHread ce8
Scan Thread 22 OSTHread 750
Scan Thread 5 OSTHread d3c
Scan Thread 24 OSTHread 234
Scan Thread 7 OSTHread dc0
Scan Thread 25 OSTHread c28
Scan Thread 26 OSTHread 528
Scan Thread 8 OSTHread aec
Scan Thread 6 OSTHread 754
Scan Thread 27 OSTHread bc8
Scan Thread 28 OSTHread fb4
Scan Thread 29 OSTHread 20c
Scan Thread 31 OSTHread 88c
Finalizer queue:Root:  0251f0ec(ASP.aspx_mypage_aspx)
Finalizer queue:Root:  02523b0c(MyControls.MyTextBox)->
  02523aa8(MyControls.MyWebTextBox)->
  0251f0ec(ASP.aspx_mypage_aspx)
Finalizer queue:Root:  025243e0(MyControls.MyClientEvents)->
  02523aa8(MyControls.MyWebTextBox)->
  0251f0ec(ASP.aspx_mypage_aspx)
Finalizer queue:Root:  02524d88(MyControls.MyTextBox)->
  02524d24(MyControls.MyWebTextBox)->
  0251f0ec(ASP.aspx_mypage_aspx)
Finalizer queue:Root:  0252565c(MyControls.MyClientEvents)->
  02524d24(MyControls.MyWebTextBox)->
  0251f0ec(ASP.aspx_mypage_aspx)

The page is rooted in the finalizer queue, both by itself and as a member variable to a MyWebTextBox object (probably the _parent member variable).

This means two things

1. The finalizer is probably blocked, otherwise items usually won't be rooted in the Finalizer queue long enough for us to catch it in a dump
2. The ASP.aspx_mypage_aspx, the MyTextBox and the MyClientEvents classes all have finalizers or derrive from classes that have finalizers which seems very odd and is probably unneccesary. This article is a good resource for understanding how the finalizer/dispose pattern should be implemented, and this article explains why unneccesary finalizers are bad (under the topic "What can make us spend a lot of our time in GC?")

If the finalizer is blocked no objects can be finalized which will lead to rapid memory growth, so a blocked finalizer will most definitely explain our problem. The reason these objects (UI and Data objects) don't go away then is of course because they would have to be finalized to be garbage collected.

So, let's have a look at the finalizer thread

0:015> !threads
ThreadCount: 27
UnstartedThread: 0
BackgroundThread: 17
PendingThread: 0
DeadThread: 10
Hosted Runtime: no
                                      PreEmptive   GC Alloc           Lock
       ID OSID ThreadOBJ    State     GC       Context       Domain   Count APT Exception
  15    1  a28 000d75f0   1808220 Enabled  3823b58c:3823bb08 000d3fe8     0 STA (Threadpool Worker)
  19    2  43c 000dd5f0      b220 Enabled  00000000:00000000 000d3fe8     0 MTA (Finalizer)
  20    3  b94 000f20b0    80a220 Enabled  00000000:00000000 000d3fe8     0 MTA (Threadpool Completion Port)
  21    4  15c 000f5318      1220 Enabled  00000000:00000000 000d3fe8     0 Ukn
  13    5  ce8 0014c3f0   880a220 Enabled  00000000:00000000 000d3fe8     0 MTA (Threadpool Completion Port)
  22    6  750 00122f70   880b220 Enabled  00000000:00000000 000d3fe8     0 MTA (Threadpool Completion Port)
   5    7  d3c 00160890       220 Enabled  00000000:00000000 000d3fe8     0 Ukn
  24    8  234 0f8a90d8   180b220 Enabled  3816cea0:3816ee28 000d3fe8     0 MTA (Threadpool Worker)
   7    a  dc0 0f8ae008       220 Enabled  00000000:00000000 000d3fe8     0 Ukn
XXXX    b    0 0015d0c8   1801820 Enabled  00000000:00000000 000d3fe8     0 Ukn (Threadpool Worker)
XXXX    c    0 115a0f68   1801820 Enabled  00000000:00000000 000d3fe8     0 Ukn (Threadpool Worker)
XXXX    d    0 11dadf88   1801820 Enabled  00000000:00000000 000d3fe8     0 Ukn (Threadpool Worker)
XXXX    e    0 13168018   1801820 Enabled  00000000:00000000 000d3fe8     0 Ukn (Threadpool Worker)
  25    f  c28 1441b018   180b220 Enabled  3823bde4:3823db08 000d3fe8     0 MTA (Threadpool Worker)
XXXX   10    0 1352b3b8   1801820 Enabled  00000000:00000000 000d3fe8     0 Ukn (Threadpool Worker)
  26   11  528 1433d008       220 Enabled  00000000:00000000 000d3fe8     0 Ukn
   8   12  aec 14416bc0       220 Enabled  00000000:00000000 000d3fe8     0 Ukn
   6   13  754 1444b828       220 Enabled  00000000:00000000 000d3fe8     0 Ukn
  27   14  bc8 14526248       220 Enabled  00000000:00000000 000d3fe8     0 Ukn
  28   15  fb4 145cb220       220 Enabled  00000000:00000000 000d3fe8     0 Ukn
XXXX   16    0 1461a008   1801820 Enabled  00000000:00000000 000d3fe8     0 Ukn (Threadpool Worker)
  29   17  20c 147abac8       220 Enabled  00000000:00000000 000d3fe8     0 Ukn
XXXX   18    0 164a02e8   1801820 Enabled  00000000:00000000 000d3fe8     0 Ukn (Threadpool Worker)
XXXX   19    0 230be290   1801820 Enabled  00000000:00000000 000d3fe8     0 Ukn (Threadpool Worker)
XXXX    9    0 0f8a99a8   1801820 Enabled  00000000:00000000 000d3fe8     0 Ukn (Threadpool Worker)
XXXX   1a    0 227c2f18   1801820 Enabled  00000000:00000000 000d3fe8     0 Ukn (Threadpool Worker)
  31   1b  88c 227d1c98       220 Enabled  00000000:00000000 000d3fe8     0 Ukn

0:015> ~19s
eax=01eff518 ebx=00099cd0 ecx=01eff518 edx=7743345e esi=00000740 edi=00000000
eip=7c97ed54 esp=01eff254 ebp=01eff2c4 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!KiFastSystemCallRet:
7c97ed54 c3              ret

0:019> kb 2000
ChildEBP RetAddr  
01eff250 7c972124 ntdll!KiFastSystemCallRet
01eff254 7c82baa8 ntdll!NtWaitForSingleObject+0xc
01eff2c4 7c82ba12 kernel32!WaitForSingleObjectEx+0xac
01eff2d8 774854ef kernel32!WaitForSingleObject+0x12
01eff2f4 77549905 ole32!GetToSTA+0x6f
01eff314 77547ed7 ole32!CRpcChannelBuffer::SwitchAptAndDispatchCall+0xcb
01eff3f4 77455349 ole32!CRpcChannelBuffer::SendReceive2+0xc1
01eff460 77484eee ole32!CAptRpcChnl::SendReceive+0xab
01eff4b4 77c8127e ole32!CCtxComChnl::SendReceive+0x91
01eff4d0 77c813ca rpcrt4!NdrProxySendReceive+0x43
01eff8b8 77c811bd rpcrt4!NdrClientCall2+0x206
01eff8d8 77bf3a12 rpcrt4!ObjectStublessClient+0x8b
01eff8e8 77484c23 rpcrt4!ObjectStubless+0xf
01eff970 774d28f3 ole32!CObjectContext::InternalContextCallback+0x126
01eff9c0 79f2340f ole32!CObjectContext::ContextCallback+0x85
01effa0c 79f23362 mscorwks!CtxEntry::EnterContextOle32BugAware+0x2b
01effb2c 79f231ef mscorwks!CtxEntry::EnterContext+0x2db
01effb60 7a0426dc mscorwks!RCWCleanupList::ReleaseRCWListInCorrectCtx+0xc4
01effbb0 79f23058 mscorwks!RCWCleanupList::CleanupAllWrappers+0x77
01effbf4 79f75f2d mscorwks!SyncBlockCache::CleanupSyncBlocks+0xec
01effdb8 79f34ff2 mscorwks!Thread::DoExtraWorkForFinalizer+0x40
01effdc8 79ecb4a4 mscorwks!SVR::GCHeap::FinalizerThreadWorker+0xc6
01effdd8 79ecb442 mscorwks!ManagedThreadBase_DispatchInner+0x4d
01effe6c 79ecb364 mscorwks!ManagedThreadBase_DispatchMiddle+0xb0
01effea8 79ed5e8b mscorwks!ManagedThreadBase_DispatchOuter+0x6d
01effed0 79ed5e56 mscorwks!ManagedThreadBase_NoADTransition+0x32
01effedc 79f6fd87 mscorwks!ManagedThreadBase::FinalizerBase+0xb
01efff14 79ecb00b mscorwks!SVR::GCHeap::FinalizerThreadStart+0xbb
01efffb8 7c826063 mscorwks!Thread::intermediateThreadProc+0x49
01efffec 00000000 kernel32!BaseThreadStart+0x34

The finalizer thread (which we found from the !threads output) is definitely doing something and based on what we know about objects beeing rooted in the Finalizer queue it has probably been stuck here for a while.

The finalizer is not neccesarily finalizing a managed object, instead it is cleaning up all com wrappers, and to release them it has to get on an STA thread.

If we look at the !threads output again, specifically at the APT (Appartment) column we can see that our only STA thread is thread 15 so that is likely where it is trying to go.

0:019> ~15s
eax=2d220b44 ebx=000d75f0 ecx=2d220ca4 edx=000b4883 esi=0000022c edi=00000000
eip=7c97ed54 esp=01b1fc70 ebp=01b1fce0 iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000297
ntdll!KiFastSystemCallRet:
7c97ed54 c3              ret

0:015> kbL 2000
ChildEBP RetAddr  Args to Child              
01b1fc6c 7c972124 7c82baa8 0000022c 00000000 ntdll!KiFastSystemCallRet
01b1fc70 7c82baa8 0000022c 00000000 01b1fcb4 ntdll!NtWaitForSingleObject+0xc
01b1fce0 79e77fd1 0000022c 00009c40 00000000 kernel32!WaitForSingleObjectEx+0xac
01b1fd24 79e77f9a 0000022c 00009c40 00000000 mscorwks!CLREventWaitHelper+0x2f
01b1fd74 79e77f50 00009c40 00000000 00000000 mscorwks!CLREvent::WaitEx+0x117
01b1fd84 79f5b69c 00009c40 00000000 00000000 mscorwks!CLREvent::Wait+0x17
01b1fe04 7a112052 000bf560 00009c40 00000000 mscorwks!ThreadpoolMgr::SafeWait+0x73
01b1fe2c 7a112206 eeb88f9d 00000000 7a1120b5 mscorwks!ThreadpoolMgr::EnterRetirement+0x8e
01b1fe94 79f71123 00000000 00000000 00000000 mscorwks!ThreadpoolMgr::WorkerThreadStart+0x360
01b1ffb8 7c826063 000bcbf0 00000000 00000000 mscorwks!ThreadpoolMgr::intermediateThreadProc+0x49
01b1ffec 00000000 79f710dd 000bcbf0 00000000 kernel32!BaseThreadStart+0x34

Thread 15 however is just a regular .net worker thread waiting for work, and as such it is not pumping messages so thread 19 (finalizer) will be indefinitely blocked in GetToSTA.

The symptom is very very similar to that explained here http://support.microsoft.com/?id=828988 and in this kb the reason for the issue is that the main thread is configured with the attribute [STAThread] and the suggested solution is to change this to [MTAThread] or to manually pump messages using Thread.CurrentThread.Join(100), neither of which really apply in an ASP.NET application.

The problem in ASP.NET is that the first CLR threadpool worker thread is never initialized for COM+ so if someone instantiates a component there that calls CoInitialize, the thread can become an STA thread and cause this type of blocking...

Solution:

A hotfix was recently released which changes this behavior, so if you run into this issue you can install that. If you also have a lot of unneccesary finalizers like in this particular case, I would recommend that you take care of them since it causes a lot of unneccessary memory usage and higher CPU in GC because of the amount of collections that have to be done to release them and the amount of data the GC has to work through.

Laters all,

Tess

Active Objects and Futures

jaredpars WebLog — 2008-01-29T00:00:00

Herb Sutter gave one of my favorite and inspiring presentations. It is called "The Free Lunch is Over". The original article can be found here. My first encounter though came from his PDC presentation and highly recommend viewing that as well.

The part that interested me the most about the talk was two new threading abstractions I hadn't encountered before. Future's and ActiveObjects. One of the basic premise is that concurrency should be grep`able and somewhat declarative. The act of calling a method on a background thread and later waiting for it to complete should be simple, not complicated.

Asynchronous programming is one of my favorite aspects of computing. What interests me the most is how asynchronous programming can be useful for UI. My biggest pet peeve is when UI hangs because an operation call, or network operation takes too long. Why not make multi-threading easy and give users a way to cancel out of these operations??? Or start loading on the background thread instead of waiting for the user to perform a specific. Hopefully over the next month or so I'll lay out some utilities and classes building on Futures and Active Objects that will do precisely this.

Future's are actions where work can be done now, but the result is not needed until a future time. Work occurs on a separate thread and the results can be easily joined once work is complete.

            var f = Future.Create(() => LongCalculation());
            // ...
            var result = f.Wait();

Future's are now exposed via the Parallel Extension team's work. You can download the CTP off of their web site and get to work.

ActiveObjects are objects which only expose Asynchronous functions where the return value is exposed as a Future. So instead of

        string GetName()

You would have

        Future<string> GetName()

An ActiveObject essentially lives on or owns a thread. All operations are queued up and processed one at a time. Since only one action at a time can be executing the object internals don't have to use locks or consider many types of race conditions. In fact if your return types are immutable a great many threading concerns go out the window. Yet all of the calls are inherently asynchronous so callers can get the result only when they are needed. The best of both worlds.

Both of these provide significant advantages over the "lock before use" patterns. In my experience I find these to be hard to maintain and lead to difficult to track down bugs. I can't tell you how many times I've gone through someone else's code, or even my own, and wondered ...

Did they forget to lock here or is this an optimization?
Is a join needed here or can these terminate at separate times?
OK I need to touch that variable, can it be accessed in multiple threads or is it safe?

Futures/Active Objects on the other hand are a bit more declarative and straight forward to understand than plain old locks. They allow you to do away with many uses of plain old locking. Don't confuse this with me saying they are a cure all for threading. They're not. But in my experiences I've found them to be a significant upgrade.

Over the next month or so I'll be laying out the design for a basic ActiveObject implementation. We will likely have to deviate off of the Parrallel Extension work to get certain behaviors but the concepts map well.

Design and Implementation - Episode 2

CraigBlog — 2008-01-23T00:00:00

Tim and I sat down and recorded our second episode of "Design and Implementation", our occasional podcast. In this episode, we discuss the newly-launched MTPS REST API.

Grab the epsiode here: Design and Implementation Episode 2 (MP3, 33MB).

If you missed our first episode, get it here.

Modularity Guidance Bundle Screencast Video - Build Pluggable ASP.NET Web Applications

David Hayden - Florida .NET Developer - C# and SQL Server — 2008-01-23T00:00:00

Modularity Guidance Bundle Screencast Video - Build Pluggable ASP.NET Web Applications

by David Hayden, Florida ASP.NET Developer, Tag: Web Client Software Factory

The Microsoft Patterns & Practices Team released the Modularity Guidance Bundle and I went ahead and put together a video that discusses the Modularity Bundle Quickstart in detail from the standpoint of creating modular web client applications using the Composite Web Application Block.

Modularity Bundle Screencast in WCSF - Create Modular ASP.NET Web Applications

The screencast highlights:

The Composite Web Application Block ( CWAB ).
Business Modules and Foundation Modules.
WebModuleEnumerator and ModuleLoader Services.
Custom Module Configuration Sections.
ModuleInitializer and Adding Global and Module Services.

So far there are 16 Patterns & Practices Screencasts, and I have a few that I will publish after my talks at the Day of Patterns & Practices and the South Florida Code Camp.

I hope you enjoy it.

The Real Value of Service Oriented Architecture (SOA)

A .NET Architecture, Design & Development Journal — 2008-01-11T00:00:00

Why SOA isn't just another spot on your buzz-word bingo card.

Partial Classes and future-proof vindication

Mike Stalls blog — 2008-01-10T00:00:00

A common question is "How can my tool crack the PDB to automatically determine what source file / line number a .NET class is defined in?"

It's a trick question.

There's a problem with the question. A .NET class may not be defined at a single source file / line number.

How should you specify what source file and line number a .NET class is defined in? Ok, that's easy for C# 1.0 since the entire class is contained in a single source file, and you could even say the line number is where the 'class' keyword appears.

In that case, you could use a C# 1.0 specific technique (such as grepping source files). But managed PDBs are targeted more generally at the IL level, and so the design tried to avoid getting tied to specific C# or other language semantics.

Managed PDBs provide source mappings for executable IL opcodes within a function body. That has well defined semantics. An executable opcode can map to an instruction address, which can map to a source line. But mapping .NET class declarations to line numbers as used generally across different .NET languages is not so clear...

When people asked this back in the C# 1.0 days, we'd emphasize the issue at the IL level. But since it wasn't a problem in C# 1.0, there wasn't a killer counter-example. All of obvious examples made it appear that classes had a well defined file/line number.

Corner cases and Future-proofing

We'd suggest that they could approximate the answer by just using the source mapping for an arbitrary method in the class. Of course, this wasn't 100%.

Maybe the class was empty or didn't have any method bodies. Maybe the class was produced from some less common codegen construct, in which case people didn't want to run the query anyways. Maybe the functions were defined across multiple files. You could even force that with the #line directive. But folks asking usually considered these to be insignificant corner cases. There were certainly a lot of corner cases, but unless you really understood the problem space, it was never really convincing; the corner cases just seemed like excuses. ("oh, we don't need to handle such an obscure case. We just need a solution that works for the mainline cases")

One could also view our obstinance of adhering to the protocol as defending the invariants and future-proofing.

The vindication

C# 2.0 introduced Partial Classes, which provided 1st-class mainline language support for splitting a class across multiple source locations. And then the default designers leveraged this so that you could write your user code in foo.cs and auto-generated code for your class would go in a file like foo.designer.cs. So now there was a mainstream common case that showing that a class may not be defined at a single source file / line number.

Add or remove the www sub domain

.NET slave — 2008-01-09T00:00:00

Most websites needs a policy for handling the www sub domain because of SEO. It doesn’t matter if you redirect all requests coming from http://www.example.com to http://example.com or the other way around. The important thing is that you do one of them. Otherwise search engines will punish you for duplicate content.

This feature is built in to BlogEngine.NET and it allows you to either enforce the use of www or to remove it. It’s an HttpModule that handles these two scenarios and I’ve pulled it out of BlogEngine.NET and polished it so it can be used in any ASP.NET web application.

The code

This is the bit that handles the incoming request and either removes or enforces the www sub domain based on a web.config appSetting.

/// <summary> 

/// Handles the BeginRequest event of the context control. 

/// </summary> 

/// <param name="sender">The source of the event.</param> 

/// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param> 

private void context_BeginRequest(object sender, EventArgs e) 

{ 

  string rule = ConfigurationManager.AppSettings.Get("WwwRule"); 

  HttpContext context = (sender as HttpApplication).Context; 

  if (context.Request.HttpMethod != "GET" || context.Request.IsLocal) 

    return; 

  if (context.Request.PhysicalPath.EndsWith(".aspx", StringComparison.OrdinalIgnoreCase)) 

  { 

    string url = context.Request.Url.ToString(); 

    if (url.Contains("://www.") && rule == "remove") 

      RemoveWww(context); 

    if (!url.Contains("://www.") && rule == "add") 

      AddWww(context); 

  } 

} 

/// <summary> 

/// Adds the www subdomain to the request and redirects. 

/// </summary> 

private static void AddWww(HttpContext context) 

{ 

  string url = context.Request.Url.ToString().Replace("://", "://www."); 

  PermanentRedirect(url, context); 

} 

private static readonly Regex _Regex = new Regex("(http|https)://www\\.", RegexOptions.IgnoreCase | RegexOptions.Compiled); 

/// <summary> 

/// Removes the www subdomain from the request and redirects. 

/// </summary> 

private static void RemoveWww(HttpContext context) 

{ 

  string url = context.Request.Url.ToString(); 

  if (_Regex.IsMatch(url)) 

  { 

    url = _Regex.Replace(url, "$1://"); 

    PermanentRedirect(url, context); 

  } 

}

/// <summary>

/// Sends permanent redirection headers (301)

/// </summary>

private static void PermanentRedirect(string url, HttpContext context)

{

  context.Response.Clear();

  context.Response.StatusCode = 301;

  context.Response.AppendHeader("location", url);

  context.Response.End();

}

Implementation

Download the HttpModule below and drop it in your App_Code folder. Then register the module in the web.config’s system.web section like so:

You also need to add an appSetting like so:

WwwSubDomainModule.zip (1,23 kb)

MVP Bundle Screencast - Learn ASP.NET MVP Design Pattern Using WCSF and Without WCSF

David Hayden - Florida .NET Developer - C# and SQL Server — 2007-12-22T00:00:00

MVP Bundle Screencast - Learn ASP.NET MVP Design Pattern Using WCSF and Without WCSF

by David Hayden ( Florida Web Developer ), Filed: Web Client Software Factory

For those of you interested in learning the Model View Presenter Design Pattern in ASP.NET, the Microsoft Patterns & Practices Team released an MVP Bundle as a part of the Web Client Software Factory v2.0. The MVP Bundle contains two quickstart examples with guidance on implementing the MVP Design Pattern with and without the Composite Web Application Block, which among other things, provides Dependency Injection services using Object Builder.

I created an MVP Bundle Screencast that walks you through the two quickstart samples in the MVP Bundle, pointing out all the cool features in the WCSF to help with Model View Presenter as well as all the 3rd party Dependency Injection and Mock Frameworks that you can use if not using the WCSF and Composite Web Application Block.

If you want to learn more about implementing the Model View Presenter Design Pattern in the Web Client Software Factory after viewing the screencast, I recommend the following screencast which talks more about the View-Presenter Pattern in the WCSF:

View-Presenter Pattern in Web Client Software Factory Screencast

The MVP Bundle Screencast went a little longer than expected at 29 minutes, but if you are new to the WCSF and/or MVP in ASP.NET, I think it will be worth watching:

MVP Bundle Screencast - WCSF v2.0 Model View Presenter Design Pattern

Enjoy and Happy Holidays!

Code Better With Design Patters in .Net Training Thoughts...

Gregs Cool [Insert Clever Name] of the Day — 2007-12-17T00:00:00

This past week I attended the Code Smarter with Design Patterns in .Net course given by Developmentor and I wanted to share some thoughts about it...

Instructor
As I'm sure you heard or seen, sometimes it is a hit or miss game with the level of a trainers experience. Sometimes they are a day ahead of you, learning as they go. Or, as seems to be the rule with Developmentor, they are very experienced, have been coding for years and generally just know their stuff.

Kevin Jones, the instructor for Code Better With Design Patters in .Net, was not only a great presenter but had decades of real world experience (err... sorry Kevin... I meant "a number of years of experience..." yeah... that... ;). And best of all that experience was across many technologies, trends and programming languages. This gave a depth to his lectures that only comes with experience, knowledge and wisdom.

He was able to seemingly easily translate that experience and knowledge and present it to us. This provided a back story and depth to the material. Not just a "here is the pattern," but "here is the pattern and here's why this has become important and the problems that it was evolved to solve..."

Kevin was also very flexible in how he presented the material, modifying it on the fly in order to adapt to the experience levels in the class or to fit it into our schedules (flight, commute, etc)

You've heard, "those who can't do, teach"? That was far from the case with Kevin (and the other Developmentor instructors I've met in the past). He really knew his stuff and it showed.

Class Environment
If you go to a Los Angeles Developmentor course, bring a jacket... I've attended two classes there and both times it was cold in the classroom (so cold the first time the Developmentor guys went out and bought sweatshirts for all attendees with the text, "Developmentor is cool"... LOL. Got to love that kind of humor...)

Besides that, I dig Developmentor courses. The rooms are good, the computers are always setup and working, the staff is professional and friendly and the lobby/gathering area always stocked with drinks, snacks and stuff ;)

Developmentor usually has small class sizes, which means you quickly develop a learning relationship with every one. This course was the most attended of any past course I've gone too, having 12 attendees.

This near one-on-one training situation is just one reason I find myself returning so often to Developmentor...

Course Content

I've been seeing the buzz on patterns for many years. I've done some reading and bought some books, but never got the "fire." Never really saw how they would directly help me solve my development problems. Having someone walk me thought it, provide the depth that I'd not seen before was just the push I needed.

The funny thing about this, is by the end of the class I saw that I've already been using patterns for many years. Reinventing the wheel over and over again. sigh...

A couple times a day I'd find myself thinking, "I done that before... I've built using singleton, factory, proxy, facade, strategy, etc, patterns for years... I just didn't know it. Nor, now that I see it, did I build them quite right..."

One thing I really liked about this course was that it wasn't about technology, but how to use existing technology (C#/.Net 2.0 with patterns) to provide better answers to the problems I have today. How to be a better developer... How to make your coding life easier... How to provide more professional solutions that will be easier to maintain and improve over time.

You can only present and learn so much in 32 hours, but with the interactive nature of the training, having someone who has "been there, done that," the knowledge gained was multiplied and sunk in deeper.

Summary

Okay, okay... I know I'm gushing a little. All was not perfect. I think the parking is a pain (park in this building, then that building and then on the last day park in this building, etc). I HATED the drive to it (driving everyday from Simi Valley to LAX on the freeway from hell, aka the 405, was just pure pain). I wish it was longer, and covered enterprise patterns (like MVC, etc). And I wish there were a VB.Net version (or at least VB.Net labs). But in the end those were little things...

All in all, I felt this course was money very well spent and one that I am going to recommend to my peers (and of course to you as well :).

Related Past Post XRef:
I'll be mostly offline the next few days...

iPhone Tops Time's List Of Top 10 Gadgets Of 2007

iPod Hacks — 2007-12-17T00:00:00

The iPhone has landed at #1 on Time's list of Top 10 Gadgets of 2007.The iPhone changed the way we think about how mobile media devices should look, feel and perform. The design is exceptional inside...

Return vs. Finally (2)

Mike Stalls blog — 2007-12-16T00:00:00

The Return statement and finally have competition. Both can are the "last" thing to execute when a function exits, so which of them is really last? I blogged about this before regarding C#'s semantics setting data. Now I'll compare some interesting differences between C# and Python.

Who wins if you set them up in direct competition like this (non-exceptional path):

void f1()
    {
        try
        {
            return 10;
        }
        finally
        {
            return 5;
        }
    }

or this (the exceptional path):

    void f2()
    {
        try
        {
            throw new Exception();
        }
        finally
        {
            return 5;
        }
    }

There are multiple intelligent ways a language design could answer this.

C#'s answer: Illegal

In C#, this is just illegal. Returns are forbidden in finally clauses. This nicely just avoids the whole problem by refusing to let you write such potentially ambiguous and confusing code. (CS0157: "Control cannot leave the body of a finally clause"). And if a consensus emerges down the road that there really is a clear "right" answer, C# can always make it legal with the "right" semantics.

IL's answer: Illegal

The underlying CLR's IL instruction provides try/catch/finally and branching opcodes. The only branching opcode out of a finally is 'endfinally', which jumps to the end of the finally block. You can't return / branch out of a finally. (See VER_E_RET_FROM_HND=0x80131845 in CorError.h).

Since .NET languages compile to IL, it may be natural for a language to have the same semantics as the IL instructions it compiles to. It's not surprising that C# has the same restrictions as the underlying IL instruction set here. However, a .NET language can have more clever opcode usage to provide their own semantics.

Python's answer: Legal

In Python, return inside of finally is actually allowed.

>>> def f1():
...   try:
...     return 10
...   finally:
...     return 5
...
>>> f1()
5
>>> def f2():
...   try:
...     raise Exception # like 'throw'
...   finally:
...     return 5
...
>>>
>>> f2()
5

In this case, you can see that even on the exceptional path, the return statement will swallow the exception and return a value.

Note that IronPython compiles to IL, and still faithfully maintains the python exception semantics here.

.NET Compact Framework WCF and Store and Forward Messaging Webcast

You Can Take it With You — 2007-12-10T00:00:00

Just a quick note to let everyone know that I'll be giving a Webcast this Wednesday (12-Dec) talking about Windows Communication Foundation as it's implemented on Windows Mobile with a focus on Store-and-Forward messaging. Store-and-Forward messaging is a .NET CF extension to WCF that significantly simplifies communication between mobile devices because it eliminates the need for the source and destination devices to be online at the same time. The sending device can send the message at anytime - if the receiving device is online, the device receives the message immediately; otherwise, the receiving device receives the message the next time the receiving device comes online.

Please join me on Wednesday for a look at the architecture of .NET CF WCF Store-and-Forward messaging and a demonstration of how to build applications that take advantage of it.

The Webcast will be broadcast live on Wednesday, 12-December at 11:00 AM PST, 2:00 PM EST, 1900 UTC. I hope to see you there.