The Right Stuff

I just finished watching Ingo Rammer’s sessions on debugging from NDC 2010:

• Advanced Debugging with Visual Studio
• Hardcore .NET Production Debugging
• (All videos are available as a Torrent)

While I consider myself experienced in debugging with Visual Studio I still didn’t know the Ctrl+B trick Ingo shows in the first session to create breakpoint groups, for example to break on all methods named WriteLine.

Ingo’s second session goes into detail how to start with WinDbg. During his talk Ingo wrote down quite a lot of WinDbg commands that I copied and extended a bit for my own reference.

# Use debugger according to architecture that is being debugged.

# Drag exe onto WinDbg to start debugging.

# Debugging services:
# 1. Using Global Flags
#  - On "Image File" tab, enter service exe
#  - Set debugger to cdb.exe -server tcp:port=1234
# 2. Start service
# 3. Start WinDbg
#  - connect to remote session: tcp:server=localhost,port=1234
# Also works (unsecured) over networks

!help

.loadby sos mscorwks # CLR 2
.loadby sos clr      # CLR 4, both after the debuggee has loaded the CLR
.chain               # Shows loaded extensions

sxe <event code> # Stop
sxn <event code> # Notify
sxi <event code> # Ignore
# ... on <event code> exceptions (for example, <event code> = clr)

g            # Go
.cls         # Clear screen

!pe          # Print exception
!clrstack    # Display stack trace
!clrstack -a # Stack trace with additional information (parameters and locals)
# If there is no stack information the JIT optimized the code away (i.e. inlining).
!dumpstack   # Another way to get the stack trace

!u <address> # Unassemble code at <address>
# Look for calls into managed code (to the right) to find the line/call that caused the exception.
# <assembly>_ni = Native image

!do <address> # Dump object
!da <address> # Dump array
# To copy addresses: Left double-click a numeric value, double right-click to copy it to the command line.

~            # Show all (managed and unmanaged) threads
!threads     # Show managed threads
~2s          # Switch to thread 2 (#2 in the unnamed column)
!runaway     # Show thread execution times (user-mode) - to find hanging threads

!dumpheap    # Show heap information, 1 line per instance
!dumpheap -stat # Heap statistics, most memory-consuming at the bottom. MT = class "pointer"
!dumpheap -stat -type TextBox # Show instances of classes containing "TextBox"
!dumpheap -type TextBox
!dumpheap -mt <type> # Dumps all instances of "TextBox" or <type>
!gcroot <address> # Why is the instance at <address> in memory?
# Domain = new GC root that reference <address> (~ static instance)
# Ignore WeakReferences, look for (pinned) references

# Create dumps from code:
[DllImport("DbgHelp.dll", SetLastError = true]
static extern bool MiniDumpWriteDump(
    IntPtr hProcess,
    int processId,
    IntPtr fileHandle,
    int dumpType, // 0x0 or 0x6 for managed code
    IntPtr exceptionInfo,
    IntPtr userInfo,
    IntPtr extInfo);

After listening to the Hanselminutes episode on Microsoft Solver Foundation (MSF) I decided it’s time to give it a shot today. Solver Foundation seems to be a solution to a set of constrained problems I sometimes face:

• Sharing costs and calculating minimal money transfers after trips with my friends, where each friend spent some money.
• Giving out questions to attendees of our User Group “Boot Camps”: Speakers prepare ~20 questions, ranging from easy to moderate levels. We assign each attendee an easy question and one to chew a bit upon. Further, every question should be given out to two attendees, so in case someone doesn’t make it to the meeting we’re still able to cover the question.

Something I don’t remember Scott Hanselman and his guest talking about is that Solver Foundation comes with an Excel Add-In that is supposed to make creating models easy easier, no code needed. Along with the “Solver Foundation for Excel Primer” document that is installed along with the binaries I figured Excel would be a good way to start looking into Solver Foundation.

After the MSI ran, I started Excel but didn’t find the Solver Foundation tab that’s advertised in the primer. The COM Add-Ins dialog said something about that the Add-In could not be loaded. Nice! Luckily the Event Viewer was more helpful in terms of error messages where I found this beauty of an exception:

Microsoft.VisualStudio.Tools.Applications.Runtime.CannotCreateCustomizationDomainException:
Customization could not be loaded because the application domain could not be created.
---> System.IO.FileLoadException: Could not load file or assembly 'MicrosoftSolverFoundationForExcel, Version=1.0.6.4890, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

My first guess was that an old MSF assembly was referenced and I decided to go with an assembly binding redirect for excel.exe. Didn’t help. The next step was to get into the innards of VSTO deployment. What I found in the MicrosoftSolverFoundationForExcel.vsto and MicrosoftSolverFoundationForExcel.dll.manifest files wasn’t surpising: Several references to old versions of MSF. None of which were deployed by the MSI installer, so Excel trying to load such dependencies failed.

<assemblyIdentity name="MicrosoftSolverFoundationForExcel" version="1.0.8.6048"…
<assemblyIdentity name="MicrosoftSolverFoundationForExcel" version="1.0.6.4890"…

I updated both references to the match the installed version 2.0.2.8632, just to find myself faced with another error saying that the manifest’s digital signature is broken.

Now was time to contact my friend Lars Keller who is an expert in VSTO development. Lars told me that I would have to re-sign the .vsto and .manifest files to make the signature reflect my changes. The Office Development with Visual Studio blog has the full details.

1. I had to create a certificate that can be used for code signing:

   makecert -r -pe -n "CN=Your Name" -b 01/01/2010 -e 01/01/2099 -eku 1.3.6.1.5.5.7.3.3 -ss My

2. Export the certificate as a PFX file using certmgr.msc
3. Create a backup copy of the MSF Excel Add-In .manifest and .vsto files
4. Open a Visual Studio Command prompt and navigate to the manifest's location
5. Make edits to the manifest file correcting the assembly versions of MicrosoftSolverFoundationForExcel to 2.0.2.8632
6. Update the digital signatures for both the manifest and the VSTO file:

   mage.exe -update MicrosoftSolverFoundationForExcel.dll.manifest -CertFile <your-cert.pfx> -Password <cert-export-password>
   mage.exe -update MicrosoftSolverFoundationForExcel.vsto -appmanifest MicrosoftSolverFoundationForExcel.dll.manifest -CertFile <your-cert.pfx> -Password <cert-export-password>

7. Restart Excel, the Solver Foundation tab should be on the ribbon

(Tested with Office 2010 beta.)

Scott Hanselman recently wrote about the Debugging Tools for Windows and their usefulness in conjunction with Process Explorer. Today I needed the Debugging Tools on a server where an ASP.NET application was running with 100% load on one CPU core with lots of context switches.

When you open Process Explorer's Threads tab for a certain process, Process Explorer will approximate function names and display offsets if the Debugging Tools are not installed. When Process Explorer is configured to use the Debugging Tools and Microsoft Symbol Servers it will display actual function names instead of obscure offsets.

Offsets	Function Names

Being the kind of guy I am, I opted for a minimal installation of the Debugging Tools, that is just the "Tools" and "Helpful Tools" branches displayed in the installer. This also installs dbghelp.dll which is needed for Symbol Server support. After setting the NT symbol path environment variable and pointing Process Explorer to %ProgramFiles%\Debugging Tools for Windows\dbghelp.dll everything should have worked. So I opened Process Explorer, displayed the properties of some process, opened the Threads tabs …and saw function offsets.

What happened? After some Filemon investigation I found that the symbol path wasn't touched by Process Explorer, no PDBs were downloaded and thus just offsets could be displayed. I got the idea that some Debugging Tools component was missing and installed the full package. Lo and behold, the function names were shown!

After playing around I found that the only component you need install to get Symbol Server support is the "Debuggers" branch. This will also get you WinDbg, a basic yet powerful debugger for Windows with plugin support. Mental note: Try WinDbg.

Aren't these the tools from the basement, Torsten? :-)