title: WinDbg and .Net x64 Assembly : Step-By-Step Walkthrough for hitting a breakpoint in a C# source
body: <p>I am having very hard times using WinDbg to track a simple object reference in a C# Forms App.
  I have found a very nice tuto by Chris Lovett : <a href="http://www.screencast.com/t/NWY2Njcx" rel="nofollow">GCRoot Demo</a> on using "SOS" in VS' Immediate Window<br>
  <strong>Unfortunately, I am debugging an x64 App</strong> and recompiling my App into 32-bit will bias the test conditions I am willing to recreate. <br><br>Trying to load SOS in an x64 Assembly results, as expected, in the following error :<br><br>
  <code>Error during command: extension C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll could not load (error 193)</code></p>
  
  <p>So, as WinDbg seems to manage x64, that's the way to go for me.<br> However, getting it to work with managed code is not a straightforward task.<br>
  Putting a simple breakpoint into the attached source results, unsurprisingly, into the following error : <br><br>
  <code>Unable to insert breakpoint 0 at 00000000 010e000f, Win32 error 0n998</code><br>
  <code>"Invalid access to memory location."</code><br><br>
  This is consistent with the guidelines given by Naveen Srinivasan.on his <a href="http://naveensrinivasan.com/2010/03/10/debugging-net-framework-source-code-within-windbg/" rel="nofollow">Blog</a> <br>
  However, when I try to use the ” sxe ld” / “.loadby sos” / ”.load sosex" workarounds suggested in that same web page, I get the following error : <br><br>
  <code>The call to LoadLibrary(sos) failed, Win32 error 0n2</code><br>
  <code>The system cannot find the file specified.</code><br>
  <br>So I guess the latter commands are also SOS-related<br></p>
  
  <p>I have also tried to follow an older post from <a href="http://dotnetdebug.net/2005/06/08/setting-a-breakpoint-in-windbg-for-managed-code/" rel="nofollow">Eran Sandler</a> which explains exactly how to proceed to set a breakpoint in WinDbg for Managed Code. But I am suspecting the name2ee command he is using to be "SOS" specific, thus making it rather unusable in my case (I am getting same kind of LoadLibrary error).</p>
  
  <p>I am really confused and helpless here. I feel I am bumping on walls whatever direction I take. I am two inches far from giving up and recompiling the whole App into 32-bit to debug it, as I've already lost almost 2 working days on this.</p>
  
  <p><em>All this is only the first step towards what I want to achieve, which is to track all the references to a "Trackee" object in a more complex App, using gcroot.</em></p>
  
  <p>Than you for your help.</p>
  
  <p><br><br>
  <em>Dummy Sample code : DebugTest.cs :</em></p>
  
  <pre><code>namespace DebugTest
  {    
      public partial class Form1 : Form
      {
          String Trackee;
          public Form1()
          {
              InitializeComponent();
              Trackee = "Where is Charlie";
          }
  
          private void button1_Click(object sender, EventArgs e)
          {
              label1.Text = Trackee; // &lt;&lt; Trying to put a breakpoint here
          }
      }
  }
  </code></pre>
  
  <p><br></p>
  
  <p><strong>ANSWER : Walkthrough</strong></p>
  
  <p><strong>1 -</strong> "loadby sos.dll clr" makes it possible to call all SOS stuff. (including "name2ee" command to follow Eran Sandler's steps.)<br>
  <strong>2 -</strong> The following command puts a breakpoint efficiently into the Managed code of some method. Example: 
  <code>!bpmd DebugTEst.exe DebugTest.Form1.button1_Click</code><br>
  <strong>3 -</strong> I am still unable to have a real visual debugger behavior as break point is hit logically as shown in the command window, but not visually in source window.<br>
  <strong>4 -</strong> By affecting to Trackee a specific Type (<em>MyString, for ex.</em>) I was able to track the Object's adress using <br> <code>!DumpHeap -type myString</code>
  which give the following ouput :</p>
  
  <pre><code>  Address               MT              Size
  0000000002bd33e0 000007ff000581d0       24 
  </code></pre>
  
  <p><strong>5 -</strong> Then after performing a <code>load vgcroot</code> and <code>!vgcroot 0000000002bd33e0 C:\graph.dgml</code> I was able to find and visualize all the references to my Trackee.</p>