... a journey through WPF, MVVM and .NET4 RSS 2.0
# Tuesday, April 17, 2007
For those students who were in the London WPF class last week, I've posted the demos and labs/slides up on the website. You can get them using "dmstudent" as the id and the password mentioned in class from here: Demos and Labs. In the labs zip, open Coursebook and you can then open any of the slide links. If there are any questions, feel free to send them my way!
Tuesday, April 17, 2007 1:00:55 PM (Central Daylight Time, UTC-05:00)  #    Comments [0] -
WPF
# Wednesday, January 17, 2007

About a year ago, I blogged on using the .NET 2.0 facility SynchronizationContext to create thread-aware components which could be hosted and would "do the right thing" for callbacks. Here's the Link to that post.

Recently, I got an email from a reader who wanted to use that paradigm, but wanted to be able to suspend the operation for some period of time and then resume it later on. He asked if there was an easy way to modify the sample I presented, and it turns out that there is.

It essentially involves three steps:

1. In the AsyncStateData structure, add a ManualResetEvent object. This will be used to trigger the pause/resume behavior. It must be initially set as signaled.

2.
In the actual asynchronous operation loop, add the event into the loop condition by calling event.WaitOne(). Make sure you have released any locks and the code can safely be halted at that point in the logic otherwise you may create deadlock scenarios and other difficult debugging issues.

3.
Add a Pause and Continue method into the class which signals and resets the event.

Modifying my previous code example, here's what I come up with:

Step 1: Add the event to AsyncStateDate

   1:  class AsyncStateData
   2:  {
   3:      private ManualResetEvent pauseEvent = new ManualResetEvent(true);
   4:      ...
   5:  }

Step 2: Add event into the loop at a safe point

   1:  public partial class Calculator
   2:  {
   3:      private void InternalCalculatePi(int digits, AsyncStateData
   4:  asyncData)
   5:      {
   6:         int completedDigits = 0;
   7:         for (; !asyncData.canceled && pauseEvent.WaitOne(-1, true) &&
   8:  completedDigits < digits; completedDigits++)
   9:         {   ...  }
  10:      }
  11:   
  12:  ...
  13:  }

Step 3: Add a Pause and Continue API

   1:  public partial class Calculator
   2:  {
   3:      public void PauseAsync(object asyncTask)
   4:      {
   5:          AsyncStateData asyncData = asyncTask as AsyncStateData;
   6:          if (asyncData != null && asyncData.running == true)
   7:              asyncData.pauseEvent.Reset();
   8:      }
   9:   
   10:     public void ContinueAsync(object asyncTask)
   11:     {
  12:          AsyncStateData asyncData = asyncTask as AsyncStateData;
  13:          if (asyncData != null && asyncData.running == true)
  14:              asyncData.pauseEvent.Set();
  15:     }
  16:  ...
  17:  }


There are certainly other ways to do this as well, for example, create a dedicated Thread object instead of using an Async delegate and then call Suspend on the thread (and Resume to continue). That can be dangerous if you take locks while running your async operation so the ManualResetEvent is probably a better solution from that perspective (since you are blocking in a known location vs. just suspending the thread arbitrarily and potentially holding onto shared resources.
Wednesday, January 17, 2007 10:11:04 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -
.NET | Code | Real World
According to the super villain quiz I am

Lex Luthor
A brilliant businessman on a quest for world domination and the self-proclaimed greatest criminal mind of our time!
Click here to take the Super Villain Personality Test
Wednesday, January 17, 2007 8:02:01 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -

One of the nifty new features of the WPF platform is the pluggable data providers.  It ships with two out of the box:

ObjectDataProvider: allows you to execute binding expressions against an object and it's methods
XmlDataProvider: loads an XML data source and makes it available as a binding source

Both of these derive from the abstract class System.Data.DataSourceProvider which implements the binding glue (INotifyPropertyChanged) needed for data binding.  A side note here is that you could write your own custom data provider if you needed to, although if the data is exposed through a .NET object, then the ObjectDataProvider is probably sufficient.

Using the providers is fairly easy -- let's say we have some XML data that looks like this:

<?xml version="1.0" encoding="utf-8"?>
<taxrecords>
 
<entry name="Opal Harrison" state="AL" income="$51,466.81" age="27" />
 
<entry name="Eugene Black" state="FL" income="$13,314.89" age="71" />
 
<entry name="Opal Chang" state="NC" income="$225,115.15" age="41" />
 
<entry name="Gary Waters" state="WI" income="$151,788.49" age="39" />
 
<entry name="Xavier Davis" state="AK" income="$136,344.97" age="66" />
 
<entry name="Stacy Harrison" state="TX" income="$122,432.82" age="32" />
</taxrecords>

The goal is to put this data into a ListBox - displaying the fields in the following format:

Name
State, Age, Income

We could clearly do all of this from procedural code -- create an XmlReader object, load the data and render each XmlNode into the listbox.  However, this is the 21st century and so we want to avoid coding as much as we can and utilize the underlying framework support instead!

We can get the data loaded into a collection source through the XmlDataProvider.  This is easily done in XAML:

<XmlDataProvider Source="largeXmlFile.xml" x:Key="xmlData" XPath="/taxrecords" />

This will look for the file "largeXmlFile.xml", create an XmlDocument and load the file into memory.  Notice we supply an XPath expression as part of this to indicate what we'd like the data provider to hand us as the collection itself.  In this case, we want to see everything under the node "taxrecords" which is the root of the document.  An interesting facet of this provider is that it performs it's work asynchronously -- you can see this behavior when you load very large XML files.  The UI will come up first, completely empty and then suddenly be populated with data.  The behavior can be adjusted through the IsAsynchronous property of the data provider.  Setting this to false will delay the display of the UI until the data is fully available.

Another interesting thing about this class is that we can define the XML data inline within the XAML document.  You do this with the x:XData tag:

<XmlDataProvider x:Key="xmlData" XPath="/taxrecords">
   <x:Data>
       <taxrecords>
         
<entry name="Opal Harrison" state="AL" income="$51,466.81" age="27" />
         
<entry name="Eugene Black" state="FL" income="$13,314.89" age="71" />
              ...

       </taxrecords>
  
</x:Data>
</XmlDataProvider>

The next step is to bind this data to a ListBox control - this is a normal Data Binding expression:

<ListBox Name="lb1" Margin="10" IsSynchronizedWithCurrentItem="True" ItemsSource="{Binding Source={StaticResource xmlData, XPath=entry}}">

Notice how we use a new property of the BindingExpression called XPath.  This property allows you to identify which element(s) you want to load from the XML data source.  It is specific to this data provider and allows for any XPath expression to be supplied.  This will succesfully load each of the "/taxrecord/entry" nodes into the ListBox, but the data itself will show up as a blank line.  This, of course, is because the data is really an XmlNode object which the ListBox has no idea how to display.  To fix this, we supply a DataTemplate to render our data: 

<ListBox.ItemTemplate>
   <
DataTemplate>
      <
StackPanel>
         <TextBlock FontWeight="Bold" Text="{Binding XPath=@name}" />
         <
StackPanel Orientation="Horizontal">
            <
TextBlock Text="{Binding XPath=@state}" />
            <
TextBlock Text=", " />
            <
TextBlock Text="{Binding XPath=@age}" />
            <
TextBlock Text=", " />
            <
TextBlock Text="{Binding XPath=@income}" />
         </
StackPanel>
      </
StackPanel>
   </
DataTemplate>
</
ListBox.ItemTemplate>

Again, we use the XPath property to define what piece of information we are binding to -- attributes of our entry in this case.  This template will give us the format we are looking for:

We can add sorting, filtering and grouping using the normal CollectionViewSource support.  Here is a XAML file which will present the above UI complete with sorting by the age element.  Notice how the XPath expression now moves to the CollectionView.  This is because the CollectionViewSource creates a ListCollectionView to manage the XML nodes because the data provider supports the IList interface.  The binding expression on the listbox is now simply a binding to the collection view.

<Window Title="AsyncDataBind" Height="300" Width="300"
 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 
xmlns:cm="clr-namespace:System.ComponentModel;assembly=WindowsBase"
 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

<Window.Resources>

  
<
XmlDataProvider Source="largeXmlFile.xml" IsAsynchronous="True"
                            
x:Key="xmlData" XPath="/taxrecords" />

  
<
CollectionViewSource x:Key="collView" Source="{Binding Source={StaticResource xmlData},XPath=entry}">
     
<
CollectionViewSource.SortDescriptions>
        
<
cm:SortDescription PropertyName="@age" Direction="Ascending" />
     
</
CollectionViewSource.SortDescriptions>
  
</
CollectionViewSource>

</
Window.Resources>

<
Grid>
  
<
Grid.RowDefinitions>
     
<
RowDefinition Height="*" />
     
<
RowDefinition Height="Auto" />
  
</
Grid.RowDefinitions>

   <ListBox Name="lb1" Margin="10" IsSynchronizedWithCurrentItem="True"
               
ItemsSource="{Binding Source={StaticResource collView}}">

     
<
ListBox.ItemTemplate>
        
<
DataTemplate>
           
<
StackPanel>
              
<
TextBlock FontWeight="Bold" Text="{Binding XPath=@name}" />
              
<
StackPanel Orientation="Horizontal">
                 
<
TextBlock Text="{Binding XPath=@state}" />
                 
<
TextBlock Text=", " />
                  
<
TextBlock Text="{Binding XPath=@age}" />
                 
<
TextBlock Text=", " />
                 
<
TextBlock Text="{Binding XPath=@income}" />
               
</
StackPanel>
            
</
StackPanel>
         
</
DataTemplate>
      
</
ListBox.ItemTemplate>

   
</
ListBox>

   <Button Grid.Row="1">
     
<
StackPanel Orientation="Horizontal">
        
<
TextBlock Text="{Binding ElementName=lb1, Path=Items.Count}" />
        
<
TextBlock Text=" Items" />
      
</
StackPanel>
   
</
Button>

</
Grid>
</
Window>

Data binding in WPF is extremely powerful -- I am constantly amazed at how much procedural code you can dump in favor of markup with creative bindings.  In the next post I'll talk a bit more about asynchronouus bindings outside of the two data providers.

Until then..

Wednesday, January 17, 2007 4:57:58 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -
.NET | Code | WPF
# Friday, December 08, 2006

There's been a discussion going on within DevelopMentor for a couple weeks regarding concurrent GC and when it really applies.

The idea behind the concurrent collector is to do as much of the GC while the UI thread continues to process UI stuff and then only interrupt the application threads when memory is being shuffled around and fixups are occurring. This provides for more responsive UI applications at the expense of slower collections and a higher memory utilization.

The instructors who are involved with .NET were discussing this because of a discrepancy in various reliable sources - First, Maoni Stephens, the ultimate authority on all things .NET GC, stated in her blog entries that concurrent GC was the default behavior for the workstation version of GC (see http://blogs.msdn.com/maoni for more information on this).

This is well known, and now well documented in various places. However, Jeff Richter seems to say in his book "CLR via C#" that concurrent collections occur only on multiprocessor machines. Several other authors back this up (notably Stephen Pratschner in "Customizing the .NET Framework Common Language Runtime" and Joe Duffy in his "Professional .NET Framework 2.0" book; both are excellent btw).

So, we had some differing opinions from people in the "know". Our Effective .NET and Essential .NET courses were written around Maoni's blogs and so the diagram we presented showed concurrent collections even on single-processor machines since she didn't explicitly say it required multiple processors to turn it on. One of the guys noticed this and said "Wait! That's wrong!"

We tried to actually see the concurrent collection in action but it turns out that it's actually quite difficult to get this to happen because concurrent collections only occur on Gen2, which for a well-written application shouldn't occur that often. To add to the complexity, the CLR attempts to optimize this behavior - just because it can do the GC concurrently, it might not.  Finally, the thread which is used for this collection is actually created and destroy as necessary so it doesn't exist most of the time.

So, to settle the argument, Jason Whittington and I spent some time spelunking into the CLR this past week to see if we could spot the concurrent collection in action. With a little WinDBG and some symbols, I think we've put the question to rest once and for all (at least for us) :-).  If you scan the GC symbols in mscorwks.dll, you'll find a treasure trove of information; one of the things that caught my eye was this:

0:000> x mscorwks!WKS::gcheap::*
79f8c5dd mscorwks!WKS::GCHeap::Relocate = <no type information>
7a0d09d9 mscorwks!WKS::GCHeap::ValidateObjectMember = <no type information>
7a088e2a mscorwks!WKS::GCHeap::IsConcurrentGCInProgress = <no type information>
Disassembling that method showed me that it checks a flag in memory --
0:000> u mscorwks!WKS::GCHeap::IsConcurrentGCInProgress 
mscorwks!WKS::GCHeap::IsConcurrentGCInProgress:
7a088e2a a1701b387a      mov     eax,dword ptr [mscorwks!WKS::gc_heap::settings+0x10 (7a381b70)]
7a088e2f c3              ret
I tried putting a breakpoint at the end of the GC process and dumping that flag out when it was a Gen2 collection (the breakpoint itself stolen shamelessly from Maoni's MSDN article in November 2006):
0:000> bp mscorwks!WKS::GCHeap::RestartEE "j 
(dwo(mscorwks!WKS::GCHeap::GcCondemnedGeneration)==2)
'dd mscorwks!WKS::gc_heap::settings+0x10 L1';'g'"
But I didn't get much success seeing it set to "1" - I suspect that it requires a more complex application than I was using to cause the CLR to decide a concurrent collection is worth the effort. So I decided this was a dead end and started looking to see where the GC process determines that concurrent collections are allowed at all. I figured GCHeap::Initialize sounded like a good spot --
0:000> u mscorwks!WKS::GCHeap::Initialize
mscorwks!WKS::GCHeap::Initialize:
79ed6924 a14412387a      mov     eax,dword ptr [mscorwks!g_pConfig (7a381244)]
79ed6929 8b4058          mov     eax,dword ptr [eax+58h]
.....
79ed697b 51              push    ecx
79ed697c e823040000      call    mscorwks!WKS::gc_heap::initialize_gc (79ed6da4)
79ed6981 85c0            test    eax,eax
Going into that function yielded what I was looking for --
0:000> u mscorwks!WKS::gc_heap::initialize_gc
mscorwks!WKS::gc_heap::initialize_gc:
79ed6da4 56              push    esi
79ed6da5 e80cf1ffff      call    mscorwks!WKS::write_watch_api_supported (79ed5eb6)
79ed6daa 33f6            xor     esi,esi
...
79ed6dc6 c70564ce387a01000000 mov dword ptr [mscorwks!WKS::gc_heap::gc_can_use_concurrent (7a38ce64)],1
Looking at that particular memory location, I tried various configurations to make sure I had the right spot. First, I did a simple console app with no config file and dumped out the location on a multi-processor box:
0:000> dd mscorwks!WKS::gc_heap::gc_can_use_concurrent L1
7a38ce64  <b>00000001b>
Next, I set the application up in server mode (also on a multi-processor box):
<xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <gcServer enabled="true" />
  </runtime>
</configuration>
0:000> dd mscorwks!WKS::gc_heap::gc_can_use_concurrent L1
7a38ce64  <b>00000000b>
Showing that it was now off.. next I tried a VM session which emulates a single processor:
0:000> dd mscorwks!WKS::gc_heap::gc_can_use_concurrent L1
7a38ce64  <b>00000001b>

It appears that the CLR is capable of doing concurrent collections on a single processor! My final test was to try turning it off altogether via a configuration switch:

<xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <gcConcurrent enabled="false" />
  </runtime>
</configuration>
0:000> dd mscorwks!WKS::gc_heap::gc_can_use_concurrent L1
7a38ce64  <b>00000000b>

As a final note on this, Jason asked Maoni directly and her response was that concurrent GC does not depend on the number of processors - just as we are seeing above. So, apparently several primary sources are actually incorrect on this behavior. It just goes to show how complex the overall GC process really is -- simple in concept, but boy there are a lot of moving parts!
Friday, December 08, 2006 1:25:29 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
.NET | Debugging
I've updated ATAPI.NET in the samples page http://www.julmar.com/samples/atapinet.zip with several fixes and support for conferences, full transfers and phone support. I think almost everything is now wrapped - if you find any missing functions that you want/need ping me and I'll see what I can do.
Friday, December 08, 2006 12:11:22 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
.NET | Tapi
# Tuesday, November 14, 2006
I've gotten several email requests about using ATAPI from ASP.NET -- people have had trouble getting it to function properly so I figured I'd post an example of how it works. First, I'd recommend using ATAPI and not ITAPI3 - only because the latter pulls in COM objects which always makes things much more complex. The key thing to remember is where to hook up your events. Don't hook events inside your ASP.NET page-derived classes - that will keep the pages alive and cause memory leaks. Instead, use static methods (as presented here) or hook the events in global.asax or some other global shared class. I created a simple dialer in ASP.NET 2.0 through the following steps:
  1. Create an ASP.NET website
  2. Add a reference to ATAPI.DLL
  3. Add a Global Application Class (global.asax)
  4. Create the TapiManager class in your global application class
  5. Utilize the TapiManager from your pages
As an example, here is my global.asax class - I chose to store the TapiManager class into the Application property bag, but you could just make it a global as well if you prefer that approach.
void Application_Start(object sender, EventArgs e) 
{
    // Code that runs on application startup
    JulMar.Atapi.TapiManager tapiManager = new JulMar.Atapi.TapiManager("TestWebApp");
    if (!tapiManager.Initialize())
        System.Diagnostics.EventLog.WriteEntry("Application", "TapiManager failed to initialize");
    else
    {
        Application["tapi"] = tapiManager;
    }
}
    
void Application_End(object sender, EventArgs e) 
{
    //  Code that runs on application shutdown
    JulMar.Atapi.TapiManager tapiManager = (JulMar.Atapi.TapiManager)Application["tapi"];
    if (tapiManager != null)
        tapiManager.Shutdown();
}
Next, I added some markup to my default.aspx file to give me some server-side controls to manipulate TAPI with:
<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" %>
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <h1>Sample TAPI Dialer</h1>
        <asp:Label runat="server" Text="Select Line:" />&nbsp;&nbsp;
        <asp:DropDownList ID="lineList" runat="server" />
        <br />
        <asp:Label runat="server" Text="Number to dial:" />&nbsp;&nbsp;
        <asp:TextBox runat="server" Width="100" ID="number" />&nbsp;&nbsp;
        <asp:Button runat="server" ID="dial" OnClick="DialNumber" Text=" Dial " />
        <asp:Button runat="server" ID="refresh" Text=" Refresh " />
        <br />
        <br />
        <asp:ListBox runat="server" ID="events" Width="400" Height="300" EnableViewState="false" />
    </div>
    </form>
</body>
</html>
Finally, I added the code-behind to actually do the dialing. As part of this, I hook the appropriate events using static methods - not instance methods so I don't keep the page alive longer than a single request. I also store all my TAPI events in a global string collection so that when the page is refreshed, I can display the current set of events.
using System;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Collections.Specialized;
using JulMar.Atapi;

public partial class _Default : System.Web.UI.Page { static StringCollection data = new StringCollection();
protected void Page_Load(object sender, EventArgs e) { TapiManager tapiManager = (TapiManager)Application["tapi"]; if (!Page.IsPostBack) { if (tapiManager != null) lineList.DataSource = tapiManager.Lines; }
events.DataSource = data; DataBind(); }
protected void DialNumber(object sender, EventArgs e) { TapiManager tapiManager = (TapiManager)Application["tapi"]; string lineName = lineList.SelectedValue;
TapiLine line = tapiManager.GetLineByName(lineName, true); if (line != null) { if (!line.IsOpen) { try { line.Open(MediaModes.InteractiveVoice); } catch { line.Open(MediaModes.DataModem); }
line.NewCall += new EventHandler<NewCallEventArgs>(line_NewCall); line.CallInfoChanged += new EventHandler<CallInfoChangeEventArgs>(line_CallInfoChanged); line.CallStateChanged += new EventHandler<CallStateEventArgs>(line_CallStateChanged); }
if (number.Text.Length > 0) { TapiCall call = line.MakeCall(number.Text); data.Add(string.Format("Created call: {0}", call)); } } }
static void line_NewCall(object sender, NewCallEventArgs e) { data.Add(string.Format("New call: {0}, {1}", e.Call, e.Privilege)); }
static void line_CallStateChanged(object sender, CallStateEventArgs e) { data.Add(string.Format("CallState: {0} is now {1}", e.Call.ToString(), e.CallState)); }
static void line_CallInfoChanged(object sender, CallInfoChangeEventArgs e) { data.Add(string.Format("CallInfo: {0} {1}", e.Call.ToString(), e.Change)); } }
This deploys and executes properly on Windows 2003 Server and IIS6. I did not try it under XP or IIS5, although I see no reason why it would not work as shown. Hopefully this will help someone out there trying to use TAPI from within a website!
Tuesday, November 14, 2006 10:01:25 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -

# Friday, September 01, 2006
I was preparing a sample memory leak application for an Advanced C# class at Microsoft this past week and debugging through it with SOS.DLL ("Son of Strike"). My prepared application was an ASP.NET application that would leak memory by holding references to the page objects after they had completed their work. I did this by having the page hook up an event handler to a global event and then never remove the handler.

This, of course, is bad form because the System.Web.UI.Page object is intended to be a transient object - it goes away at the end of the request - in production code, I would really bind the event to a handler in global.asax instead. But as I said, this was a sample.

So, I was debugging through it prior to the class just to make sure it exhibited the behavior I was looking for. I run the web page a few times, noted my working set going up and never coming back down. Next, I used ADPLUS.VBS to take a hang dump of the process. I then loaded this dump up into WinDBG and started poking around. First, I looked at the heap and sure enough I saw a bunch of page objects:
0:000> .load sos
0:000> !DumpHeap -stat
total 36955 objects
Statistics:
      MT    Count    TotalSize Class Name
7b4ecd7c        1           12 System.Windows.Forms.ButtonInternal.ButtonPopupAdapter
7b481f00        1           12 System.Windows.Forms.LinkLabel+LinkComparer
7b475ca8        1           12 System.Windows.Forms.FormCollection
7b474f8c        1           12 System.Windows.Forms.Layout.DefaultLayout
7b4749e0        1           12 System.Windows.Forms.ClientUtils+WeakRefCollection
7b473ca8        1           12 System.Windows.Forms.Layout.ArrangedElementCollection
7a755834        1           12 System.Diagnostics.PerformanceCounterCategoryType
7a753394        1           12 System.Diagnostics.TraceOptions
7a71a710        1           12 System.Net.TimeoutValidator
.......
00166030      891       169744      Free
054d24d4     3128       187680 System.Web.UI.LiteralControl
0548cbd4      519       197220 ASP.default_aspx
791242ec     1545       297960 System.Collections.Hashtable+bucket[]
79124670     1185      1090500 System.Char[]
79124228    11961      1279380 System.Object[]
790fa3e0    19149      1561392 System.String
Total 110069 objects
So, next I used DumpHeap to just look at this specific type by giving it a metadata token:
0:000> !DumpHeap -mt 0548cbd4        
 Address       MT     Size
.....     
01854ff0 0548cbd4      380     
01860130 0548cbd4      380     
0186b2b4 0548cbd4      380     
018773f8 0548cbd4      380     
01882538 0548cbd4      380     
0188d6bc 0548cbd4      380     
01898840 0548cbd4      380     
018a39c4 0548cbd4      380     
018aeb48 0548cbd4      380     
total 519 objects
Statistics:
      MT    Count    TotalSize Class Name
0548cbd4      519       197220 ASP.default_aspx
Total 519 objects
I then used the very cool GCRoot command to determine why a page instance was still rooted and therefore not collectable.

Note: it appears that GCRoot doesn't work well inside VS.NET 2005 - apparently the SOS debugging extension is using some debugger API which isn't fully supported in VS.NET, so you need to familiarize yourself with WinDBG to do this.


0:000> !gcroot 018aeb48 
Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 0 OSTHread 3a8
Scan Thread 2 OSTHread e8
Scan Thread 3 OSTHread 1a8
Scan Thread 6 OSTHread 7d4
Scan Thread 7 OSTHread 2b4
Scan Thread 8 OSTHread fdc
Scan Thread 9 OSTHread eac
DOMAIN(001E5E08):HANDLE(Pinned):12312f0:Root:0226c498(System.Object[])->
018af940(System.EventHandler)->
0186c0ac(System.Object[])->
018af920(System.EventHandler)->
018aeb48(ASP.default_aspx)
With this output, I can tell that my default_aspx object is being kept alive through an EventHandler as I expected. The interesting thing about this output is I cannot tell which event handler is keeping it alive - i.e. there is nothing in this root list that points to a specific object holding it other than a object[]. That essentially means this is a static event and there isn't an actual object around on the heap for it. This just makes the debugging exercise more interesting - after all if it were an instance event then I would see the class name at the top of the root list and we could stop right here.

So, my next step is to dump the event handler to try to identify what method it is wrapping - I could then search the code for this method and find out where it is being bound. I dump out the EventHandler object:
0:000> !do 018af920
Name: System.EventHandler
MethodTable: 7910d61c
EEClass: 790c3a7c
Size: 32(0x20) bytes
 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
790f9c18  40000f9        4        System.Object  0 instance 018aeb48 _target
79109208  40000fa        8 ...ection.MethodBase  0 instance 00000000 _methodBase
790fe160  40000fb        c        System.IntPtr  0 instance 88962888 _methodPtr
790fe160  40000fc       10        System.IntPtr  0 instance        0 _methodPtrAux
790f9c18  4000106       14        System.Object  0 instance 00000000 _invocationList
790fe160  4000107       18        System.IntPtr  0 instance        0 _invocationCount
From this I get the internals of the EventHandler object. It gives me some specific information:
  • _target is the object the delegate is holding onto - my default_aspx in this case. The value better match up with my original object!
  • _methodBase is used for dynamic code and is null here.
  • _methodPtr is the method associated with the instance, or possibly a dynamically generated thunk for static methods. This is what I'm interested in.
  • _methodPtrAux is used for static methods; this holds the method descriptor and the _methodPtr is a dynamically generated block of code to remove the this reference. Noting that this is null, I can infer that this is an instance method bound to the delegate.
  • _invocationList and _invocationCount are used for Multicast Delegates -- these are both zero indicating that this is a single delegate and there is no chain to follow.

My next step is to try to get a valid method name from the _methodPtr so I convert that to hex and pass it into IP2MD.
0:000> !ip2md 0n88962888 
Failed to request MethodData, not in JIT code range
This is a pretty common error and simply means that the method may not have been JITted yet, or may be a dynamic block of code which never went through the JIT compiler. In .NET 1.1 we could start dumping method descriptors and trying to match up the address (DumpClass -md) for this class and it's base class.

However, under .NET 2.0 this rarely works anymore - the address doesn't appear to ever match up to a valid descriptor. However, it clearly is part of the managed heap due to it's address. So, failing to locate this address, I tried disassembling the code:
0:000> !u 0n88962888 
Unmanaged code
054d7748 e862289b74      call    mscorwks!LogHelp_TerminateOnAssert+0x3f5f (79e89faf)
054d774d 5e              pop     esi
054d774e cc              int     3
054d774f cc              int     3
054d7750 38c8            cmp     al,cl
054d7752 48              dec     eax
054d7753 05a0774d05      add     eax,54D77A0h
054d7758 0100            add     dword ptr [eax],eax
054d775a 0011            add     byte ptr [ecx],dl
054d775c 0000            add     byte ptr [eax],al
Humph. This doesn't even look like valid code to me.. this looks like random data, so I dumped it out:
0:000> dd 0n88962888 
054d7748  9b2862e8 cccc5e74 0548c838 054d77a0
054d7758  11000001 90000000 054d77a0 11000002
054d7768  90000004 00000000 054d77a0 00000000
The third and fourth DWORD look interesting because they appear to fall in the managed heap as well -- so I began to dump them out trying to figure out what they were. I found that the first value is a method descriptor:
0:000> !dumpmd 0548c838 
Method Name: _Default.OnDatabaseHasChanged(System.Object, System.EventArgs)
Class: 054ab574
MethodTable: 0548c86c
mdToken: 06000004
Module: 0548c35c
IsJitted: no
m_CodeOrIL: ffffffff
It is the real method bound to the delegate instance. The other DWORD appears to be an metadata reference to the event owner itself:
0:000> !dumpmt 054d77a0
EEClass: 0551940c
Module: 048ac9ec
Name: DatabaseMonitor
mdToken: 02000002  (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\leakypage\2a399ab5\b1e04c63\App_Code.onwg1zqj.dll)
BaseSize: 0xc
ComponentSize: 0x0
Number of IFaces in IFaceMap: 0
Slots in VTable: 8
From here I can see the module that this code is defined in (the dynamically generated App_Code directory) and the name (DatabaseMonitor). This gives me enough information to stop here and begin looking at the code itself - specifically where default.aspx binds it's OnDatabaseHasChanged method to the DatabaseMonitor static class defined somewhere in the App_Code directory. If I didn't have the source code available, I could locate the module and then save it out to a file through the savemodule command:
0:000> lm m App_Code_onwg1zqj
start    end        module name
04de0000 04de8000   App_Code_onwg1zqj C (no symbols)           
0:000> !savemodule 04de0000 c:\appcode.dll
3 sections in file
section 0 - VA=2000, VASize=504, FileAddr=200, FileSize=600
section 1 - VA=4000, VASize=2c8, FileAddr=800, FileSize=400
section 2 - VA=6000, VASize=c, FileAddr=c00, FileSize=200
I could then ILDasm or Reflector the generated assembly and look for my bug from that.

I love SOS and WinDBG.. if only they could match up managed source code to the image I'd abandon VS.NET as a debugger altogether..
Friday, September 01, 2006 1:18:41 PM (Central Daylight Time, UTC-05:00)  #    Comments [0] -
.NET | Code | Debugging
A DM colleague of mine, Neils Berglund noted his required applications under OS X and asked for feedback on what everyone else is using (assuming you are on OS X anyway).

The original question was what RSS reader are you using.. my preference is NetNewsWire as I was used to the Newsgator line of products when using Windows all the time so it made an easy transition for me. I also use MarsEdit to update posts on this blog -- it's not WYSIWYG but it keeps my HTML skills (if I ever had any) from drying up.

So, adding to Neils list, I also use --
  • Final Cut Express - for editing movies, I found iMovie to be too limiting.
  • CHMOX - to open and read .CHM (Windows Help) files.
  • DivX codecs - to play my 300+ .divx movies.
  • Smultron - a decent, quick color-coded text editor
  • Virtue Desktops - an awesome window manager.
  • Remote Buddy - allows the Apple Remote to be used to control other applications such as Power Point.
  • Microsoft Office - I just can't live without Word/Excel/Power Point. I know Apple has iWork, but it just isn't quite the same.
  • Flip4Mac - Codecs for .WMV (Windows Media), essential in a 99.999% Windows dominated world.
  • Coverflow - this isn't critical, but it's a fun app to show off - it let's you view your music through the album covers in a cool, flip-3d style fashion.

I'm also trying out a .mac membership for backup purposes. Not sure I'll stay with that, but it is automatic and seems to work even when I travel.

So, what things do you think are necessary applications under OS X?
Friday, September 01, 2006 11:15:50 AM (Central Daylight Time, UTC-05:00)  #    Comments [0] -
Real World
# Monday, August 28, 2006
One question I get a lot when teaching the VSTS course is "How can I move tasks or bugs from our existing system into TFS?"

The answer is quite simple: write a program that utilizes the Team Systems Object Model.

The Object Model is documented partially in the VSIP SDK -- if you intend to work with it, I highly recommend you go and grab that SDK from Microsoft, but here is a simple example of creating a bug in the first Team Project available on the server named TFSServer (you can imagine the rest which uses ADO.NET to pull your existing tracking tickets from whatever system you have):

   1:  using System;
   2:  using System.Collections;
   3:  using System.Collections.Generic;
   4:  using System.Text;
   5:  using Microsoft.TeamFoundation.Client;
   6:  using Microsoft.TeamFoundation.WorkItemTracking.Client;
   7:   
   8:  namespace EnterWorkItems
   9:  {
  10:      class Program
  11:      {
  12:          static void Main(string[] args)
  13:          {
  14:              TeamFoundationServer tfs = new TeamFoundationServer("TFSServer");
  15:              WorkItemStore wis = (WorkItemStore) tfs.GetService(typeof(WorkItemStore));
  16:   
  17:              Project teamProject = wis.Projects[0];
  18:              foreach (WorkItemType wit in teamProject.WorkItemTypes)
  19:                  Console.WriteLine(wit.Name);
  20:   
  21:              WorkItemCollection wic = wis.Query("Project='Test' AND Type='Bug'");
  22:              foreach (WorkItem wiEntry in wic)
  23:              {
  24:              }
  25:   
  26:              WorkItemType witBug = teamProject.WorkItemTypes["Bug"];
  27:              if (witBug != null)
  28:              {
  29:                  Console.WriteLine("Adding new bug to Team Project {0}", teamProject.Name);
  30:   
  31:                  WorkItem wi = new WorkItem(witBug);
  32:                  wi.Description = "This is a sample bug which was added through the object model";
  33:                  wi.Reason = "New";
  34:                  wi.Title = "You have Bugs! [Ding]";
  35:   
  36:                  wi.Save();
  37:                  Console.WriteLine("Added Work Item # {0} created by {1}", wi.Id, wi.CreatedBy);
  38:              }
  39:          }
  40:      }
  41:  }


Breaking this down a bit, the first main piece of code is the connection to the Team Server itself. This is accomplished on line 14 by creating a new TeamFoundationServer object. An optional constructor allows for credentials to be provided, otherwise it logs on as the current principle.

Next, we retrieve the WorkItemStore. Almost everything in the object model is accessed through the IServiceProvider interface which provides a GetService method where you pass in the System.Type object you want to work with. This is a nice versioning technique that is utilized in many other Microsoft technologies as well.

With the WorkItemStore, you can then query work item type definitions, one of which is necessary to create a WorkItem. You fill in the details for the Work Item you want to create and call the Save method (line 36) to commit the changes to the TFS store. The WorkItem id will then be valid and could be added to the existing bug tracking system as a forward link to the new information if you wanted.
Monday, August 28, 2006 6:45:13 AM (Central Daylight Time, UTC-05:00)  #    Comments [0] -
.NET | Enterprise
I'm a WPF Disciple
Search
Categories
Archive
<April 2007>
SunMonTueWedThuFriSat
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2010
Mark Smith
Sign In
All Content © 2010, Mark Smith
DasBlog theme 'Business' created by Christoph De Baene (delarou)