greggm's WebLog

Notes from debugging a managed memory leak

2009-10-30T00:49:00Z

Recently, I spent a while digging into a managed memory leak. This is a pretty well-worn blog topic, but I figured I would add my two cents to it anyway, as I found a few things that I didn't notice in the existing blogs.

First, Rico wrote up the basic approach back in 2004, so you should start by reading this - http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx. This will give you an intro to using sos.dll in WinDbg.

What I would like to add:

#1: How to decide if you have a leak in the first place.

Since GC's happen non-deterministically, it can be hard to know if you actually have a managed leak. For example, if you look at memory usage at the end of a user scenario, you will likely see memory usage all over the map based on when the last GC happened. The best technique I found for this is to stop after gen-2 collections. This isn't perfect since gen-2 collections can still happen at any time in your code, but it still gives you a better estimate then stopping after user scenarios.

To stop after the next gen-2 GC: !findroots -gen 2

Note that this command is new for the CLRv4 version of sos.dll (also available in Silverlight). I am assuming that you could achieve similar functionality with a well-placed breakpoint in older CLRs, but I am not familiar enough with the inner workings of the GC to tell you where.

#2: Use CLRProfiler to visualize the leaks

This may have been specific to my scenario, but I didn't have a lot of success with !gcroot. I had more success understanding the problem by loading up a .log file in CLRProfiler (http://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-8926-862b40aa0cd0&DisplayLang=en). One note that I found here was to _not_ use '-xml' when saving out the log as CLRProfiler doesn't understand the XML format.

To save the log out: !TraverseHeap c:\users\greggm\desktop\myheap.log

#3: !gcroot doesn't show roots in CCW's

When native code calls into managed code from COM, native code gets a CCW (COM callable wrapper). If native code leak's its CCW, the managed object will be leaked, but !gcroot will not tell you why.

Tracing calls to QueryInterface on a managed object

2009-07-24T00:31:00Z

To date, one difficulty with implementing COM interfaces in managed code is that until now there has been know way to debug into QueryInterface. With CLR v4, its now possible to modify your object to trace calls to QueryInterface using the new ICusomQueryInterface interface (see MSDN).

Example:
[ComVisible(true)]

sealed class MyObject : IMyInterface, ICustomQueryInterface

{

CustomQueryInterfaceResult ICustomQueryInterface.GetInterface(ref Guid iid, out IntPtr ppv)

{

Debugger.Log(1, "MyObject", "MyObject: QI'ed for " + iid.ToString() + "\n");

ppv = IntPtr.Zero;

return CustomQueryInterfaceResult.NotHandled;

}

};

What to do with a machine that doesn't support Hyper-V...

2009-05-12T19:41:00Z

In my little corner of the world, during the last year (give or take) Hyper-V went from something that a few people were playing with to something that every single person couldn't live without. The huge benefit to us is the 'snapshot' feature, which allows us to instantaneously get a test machine back to clean state.

This left me with one problem - what to do with my old test machine which was too old to support Hyper-V, but too new to just throw away. Fortunately, Win7 came to my rescue by adding support for booting off a VHD (virtual hard disk). Now I can use differencing virtual hard disks, as a poor-man's Hyper-V and still get some millage out of my old test boxes.

Basic reimaging procedure:

Boot to my physical hard drive
Delete the current differencing disk
Create a new differencing disk
Boot back to my differencing disk
Rejoin the domain and install my test software (Visual Studio in my case)

Here is how I set this up:

Installed Win7 to my physical hard drive
After that install completed, I created a new Virtual Hard disk from the Disk Management MMC tool (Computer Management->Storage->Disk Management). I created a fixed Virtual Hard drive but I actually think that I dynamic disk would have been better since most of the parent virtual hard disk will remain empty. I named this file c:\windows7.vhd.
Boot to the Win7 installer again to install a second partition of Win7 on the VHD
After the installer finishes initializing, go to the repair tools and open a command prompt

Run 'diskpart'
select vdisk file=c:\windows7.vhd.
attach vdisk
exit

Now continue the Win7 installer, select the virtual disk as the partition to install to. Note that in RC builds, Win7 will warn you that Windows cannot install to this partition, but this warning appears to be ignorable.
After the install completes, install anything else to that parent partition that you need (ex: development tools, baseline libraries, etc).
Boot back to the physical hard drive.
Create a new differing vhd using the 'diskpart' tool (create vdisk file=c:\windows7.diff.vhd parent=c:\windows7.vhd)
Add a new boot menu entry for the differencing vhd, and set it as the default:

bcdedit /copy {guid_of_vdisk} /d "Win7 (Diff VHD)" this will create a new boot entry and assign a Guid to it
bcdedit /set {guid_of_copy} device vhd=[C:]\windows7.diff.vhd
bcdedit /set {guid_of_copy} osdevice vhd=[C:]\windows7.diff.vhd
bcdedit /default {guid_of_copy}

Boot to your new diff vhd and test away

Disabling script debugging in VS 2008 + IE8

2009-04-07T03:11:00Z

Visual Studio 2008 shipped with a feature to automatically enable script debugging when starting IE8 from Visual Studio. In other words, if you are using VS 2008 and IE8, there is no longer a need to tweak IE options to debug your site.

However, this feature unfortunately created a problem which we didn't notice before VS 2008 shipped - web sites which create a large number of dynamic documents can perform quite poorly under the debugger, and now there is no option to run your site outside the debugger. If you open solution explorer and see the document list under 'Script Documents' dance up and down, you are running into this problem.

Work around:

This work around requires the Silverlight 2 Tools for Visual Studio 2008 SP1 to be installed. So if you don't have these tools installed, you can download them from Microsoft (http://www.microsoft.com/downloads/details.aspx?familyid=C22D6A7B-546F-4407-8EF6-D60C8EE221ED&displaylang=en). If this is not an option for you, there is some alternative work arounds at the bottom of this blog post.
Right click on your project and open up project properties
Go to the 'Start Options' sheet, and click the 'Silverlight' button at the bottom of the screen. Because the debugger cannot debug both Silverlight code and Script code at the same time, this will disable Script debugging and therefore avoid the problem.

Request for feedback:

If you want to disable script debugging, I would love to hear about your scenario. We are aware of the performance issues with applications that create many documents. We hope to address this in a future version of Visual Studio.

Alternative work around – disable all script debugging:

Open a new command prompt (start->run, cmd.exe). If you are on a 64-bit computer this needs to be a 32-bit prompt (start->run, c:\windows\syswow64\cmd.exe)
reg add HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\AD7Metrics\Engine\{F200A7E7-DEA5-11D0-B854-00A0244A1DE2} /v ProgramProvider /d {4FF9DEF4-8922-4D02-9379-3FFA64D1D639} /f

If you are using Visual Web Developer Express, replace 'VisualStudio' with 'VWDExpress':

reg add HKLM\SOFTWARE\Microsoft\VWDExpress\9.0\AD7Metrics\Engine\{F200A7E7-DEA5-11D0-B854-00A0244A1DE2} /v ProgramProvider /d {4FF9DEF4-8922-4D02-9379-3FFA64D1D639} /f

If you want to restore your computer so that you can debug scripts again:

reg add HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\AD7Metrics\Engine\{F200A7E7-DEA5-11D0-B854-00A0244A1DE2} /v ProgramProvider /d {170EC3FC-4E80-40AB-A85A-55900C7C70DE} /f

Work around for performance problems caused by 'anonymous code' nodes:

Some sites run into problems being debugged due to numerous "anonymous code" nodes in solution explorer. For these sites, instead of disabling script debugging completely, it's possible to disable just the 'anonymous code' nodes. This requires Visual Studio 2008 SP1. To do so:

reg add HKCU\Software\Microsoft\VisualStudio\9.0\Debugger /v HideAnonymousScriptCodeNodes /t REG_DWORD /d 1 /f

Script debugging broken in VS 2005 after installing IE8

2009-04-01T20:16:00Z

[Note: This post has been updated with new information]

There is currently an issue in VS 2005 after you install IE8 where script debugging is broken. If you are using VS 2008, this will not be a problem.

Brad Sullivan posted the work around in the debugger forum. Here is what he said:

IE 8 has a feature called Loosely-Coupled Internet Explorer (LCIE) which results in IE running across multiple processes.
http://www.microsoft.com/windows/internet-explorer/beta/readiness/developers-existing.aspx#lcie

Older versions of the Visual Studio Debugger get confused by this and cannot figure out how to attach to the correct process. You can work around this by disabling the process growth feature of LCIE. Here's how:

1) Open RegEdit
2) Browse to HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet Explorer -> Main
3) Add a dword under this key called TabProcGrowth
4) Set TabProcGrowth to 0

Note that If you are using a 64-bit computer, you want to edit the 32-bit registry.

In addition to this, IE's installer will re-disable script debugging. So you will need to reenable it:

Open Internet Explorer
Go to Tools->Internet Options
Switch to the Advanced tab
Uncheck 'Disable script debugging (internet explorer)'

One finial note - if you are attempting to debug a browser extension or ActiveX control written in native or managed code, you may experience the same problem. This will happen on all OSs with VS 2005, and on XP/Server 2003 with VS 2008. In this situation, you need to follow Brad’s work around.

[July 10th Update]: We recently discovered another issue with Script Debugging after installing IE8. The issue does not always repro, which is how we missed it, but there is a workaround. To work around:

Install Visual Web Developer 2008 Express Edition, which is a free download from http://www.microsoft.com/express/vwd/Default.aspx.
Optional step: Uninstall Visual Web Developer express

This will update the Visual Studio shared script debugging files (the files shared between every version of Visual Studio to enable script debugging) from the Visual Studio 2005 version to the 2008 version, and will thus work around the issue.

Exceptions Dialog explained (or what does 'User-Unhandled' mean)

2008-12-31T21:38:00Z

We recently had some questions on our internal Visual Studio Debugger forum about the exceptions dialog. So I decided to take a stab at explaining it.

Just My Code

The first step to understanding this dialog is to understand a feature called 'Just My Code' (enabled/disabled with 'Tools->Options->Debugging->Enable Just My Code'). Just My Code is currently a managed-only debugging feature. When enabled, the debugger divides up all the code running in the debugged process into two groups - your code, and non-user code (system code). It then tries to hide the details of system code from you so that you can concentrate on looking at your own code.

User-Unhandled Defined

Next concept to explain: 'User-Unhandled' exceptions. An exception becomes 'User-Unhandled' after:

An exception travels through your code (your code either throws the exception or calls into system code which throws an exception back to you)
-and-
Your code doesn't catch the exception
-and-
The exception is caught by system code

In other words: 'User-unhandled' does not necessarily mean that your app is actually crashing. The debugger is trying to tell you about an exception which is probably interesting before this exception is swallowed up by the system. After catching the exception, the system might fall over and die, or it might be totally expected (in which case you should go to Debug->Exceptions and turn off stopping on 'User Unhandled' exceptions for your app).

Example: You are building a WinForms app which has a bug in its handler for some button which will cause it to deref null. If you run this app outside of a debugger, and then attach the debugger, WinForms will quietly swallow the exception. But if you have 'User unhandled' exceptions enabled, the debugger will stop and you can easily find out what went wrong.

Now to the dialog

Now that we have the concepts, let's explain how they are expressed in the dialog.

For exceptions that don't support Just My Code (C++ Exceptions, Managed Debug Assistants, Win32 Exceptions, Common Language Runtime Exceptions if Just My Code is disabled) – the debugger will show the 'User-Unhandled' checkbox as checked and disabled. What this is trying to tell you is that this setting is 'N/A'. For this type of code, the debugger doesn't divide the world up into user code and non-user code. So an exception could never go user-unhandled.

For these exceptions, the 'Thrown' column has the same meaning that it does in other debuggers (WinDbg calls this 'first chance', VS 2002/3 referred to this as 'Break' instead of 'Continue').

For exceptions Common Language Runtime Exceptions (with Just My Code enabled): Both the 'Thrown' and 'User-Unhandled' column can be checked. 'User-unhandled' has the meaning discussed above. Checking 'Thrown' will cause the debugger to stop when either user code throws the exception, or when system code throws the exception back to user code. In other words, the debugger will not stop for internal exceptions within the system code.

What about unhandled exceptions? The debugger always stops on unhandled exceptions since the process will otherwise exit. Since the debugger always stops, there doesn't need to be a checkbox for this one.

Attaching a debugger at startup

2008-09-12T22:30:00Z

Sometimes you need to debug a process, and you need to attach the debugger right away, but you cannot launch the process under the debugger. For example, if the process you need to debug is a Windows Service, the Windows Service Manager must launch the process. How can you debug it?

Here are the two easiest solutions:

#1: Windows includes registry settings under the ‘Image File Execution Options’ key that can help you debug this. I blogged about this before back in February of 2005 (http://blogs.msdn.com/greggm/archive/2005/02/21/377663.aspx). Most of the information is that blog is still correct. A few updates worth mentioning though:

Visual Studio 2008 can support session 0 processes on Vista or Server 2008.
Visual Studio 2008 can support 64-bit operating systems. The only remaining 64-bit restriction is that 64-bit managed processes cannot be debugged this way since the .NET Framework does not support managed+native debugging of 64-bit processes.
Visual Studio 2005 does not support this feature on Windows Vista or Server 2008. You will need to upgrade to 2008 for these operating systems.

#2: You can add code to your app to cause it to pause waiting for a debugger to attach. I am attaching an example header file for making this work. We ship several executables that embed similar code for this reason. Just call ‘RuntimeDiagnostics::CheckPauseOnStartupOption()’ as the first line of code in your main routine. You can do something verify similar for managed code as well. Just call ‘System.Diagnostics.Debugger.IsAttached’ instead of IsDebuggerPresent.

int _tmain(int argc, _TCHAR* argv[])

{

RuntimeDiagnostics::CheckPauseOnStartupOption();

return 0;

}

Then set this registy key if you need your app to pause:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sample.exe]
"PauseOnStartup"=dword:00000001

Writing a script debugger without using the MDM

2008-06-09T21:21:00Z

Today’s blog is about writing your own script debugger.

Visual Studio has provided ‘Script’ debugging for a long time. In this context, ‘Script’ refers to script run by jscript.dll or vbscript.dll such as the script code in Internet Explorer, classic ASP scripting, or the cscript/wscript programs. Long long ago, someone provided a sample for creating your own script debugging utilizing the active script debugging interfaces (ex: IRemoteDebugApplication).

However, this sample relied on a Microsoft executable called mdm.exe (IMachineDebugManager/CLSID_MachineDebugManager). After Visual Studio 2003, Visual Studio stopped shipping mdm.exe. So today, I wanted to provide a brief summary of how one could port an mdm.exe-based script debugger to the newer interfaces. Mdm.exe provided essentially two related features -- it allowed a debugger determine what script applications where currently running, and there was an eventing interface that let a debugger be informed when a new script application started. These features worked because the debugger component inside of the target process (pdm.dll) would connect to mdm.exe whenever a new script application was created.

Today, these features have been moved to pdm.dll. So now, pdm.dll is loaded in both the debugger and in the target process. In the target process pdm.dll still continues to do the same work as it has always done. However, now one can also load pdm.dll into the debugger process to obtain the old MDM features.

PDM now has a new CLSID for the work that it does in the debugger process – CLSID_MsProgramProvider. It exposes an AD7 interface for obtaining this information: IDebugProgramProvider2.

There is sample code attached to this blog which demonstrates how to launch or attach to a program using these new interfaces.

Reporting a Visual Studio crash to Microsoft

2008-05-22T21:47:00Z

Background

Sometimes Visual Studio crashes. It would be nice if this wasn’t the case, but unfortunately it happens. However, like many Microsoft applications, Visual Studio has Error Reporting so that when a problem happens, you can tell us about it in one click. However, sometimes you would like to actually tell a live human about your crash. There are a number of advantages to doing so:

A human might be able to tell you about a work around that Windows Error reporting doesn’t know about.
A human can tell you if this crash was something that we could diagnose.
It helps to make sure your issue is really fixed. When a developer at Microsoft looks at a Windows Error report, all we see is where the crash happened and some local variables. Sometimes we can figure out what was happening and create a repro to confirm our fix. This is the best case, but it often doesn’t happen this way. More often we need to either guess what a fix is but not test the fix, or we are unable to even guess what a correct fix might be.

For these reasons you might want to also report the issue through the Visual Studio product feedback center.

What to do

Step #1: Go to http://connect.microsoft.com/site/sitehome.aspx?SiteID=210 and enter a bug.

Step #2: In the bug, include the ‘bucketing information’. You can find this information by:

Open the event viewer (Right click on Computer and go to ‘Manage’; click on the ‘Event Viewer’ tree item).
Open the ‘Application’ section
Look for the entry that happened about the correct time and had the source set to ‘Application Error’
Copy the content and paste it into the bug, it should look something like:

Faulting application devenv.exe, version 9.0.30428.1, time stamp 0x4815597f, faulting module scriptle2.dll, version 9.0.21022.8, time stamp 0x47317e18, exception code 0xc0000005, fault offset 0x0000328c, process id 0xfbc, application start time 0x01c8bc39887cac69.

Visual Studio 2008 SP1 Beta

2008-05-17T03:09:00Z

In case you missed it, Visual Studio 2008 SP1 Beta has been released:
http://www.microsoft.com/downloads/details.aspx?familyid=CF99C752-1391-4BC3-BABC-86BC0B9E8E5A&displaylang=en

For the debugger, Visual Studio 2008 SP1 contains:

As with all service packs, fixes for all the significant bugs that we found since Visual Studio 2008 RTM.
Improved support for downloading symbols and PDBs for the .NET Framework and other Microsoft products.
Improvements for using Visual Studio with non-local symbol stores (such as the Microsoft public symbol servers)
Step into specific for managed. We have had this feature with native for years, with SP1 we added this support for managed as well. If a line contains multiple function calls, you can right click on the line in the editor and select which function you would like to step into.
Step filtering for managed. There is now an option to stop stepping into property get routines.

We want to try and get the RTM version into customer’s hands as soon as we can, so this means there isn’t too long for us to act on customer feedback. So if you are interested, give it a whirl soon.

One very important note: If you have installed any Visual Studio 2008 hot fix, make sure that you run this tool _before_ installing Visual Studio 2008 SP1 Beta:
http://code.msdn.microsoft.com/RemoveKB944899

If you would rather not run a tool, manual steps can be found here:
http://blogs.msdn.com/heaths/archive/2008/05/16/kb944899-should-be-removed-before-installing-visual-studio-2008-sp1.aspx

Visual Studio Remote Debugger Service user account requirements

2008-05-15T23:18:00Z

I was asked today -- Why does the Visual Studio Remote Debugger Service need to be run as an administrator?

Since it doesn't appear that this information is documented, I figured I would provide an answer. Running the remote debugger service as an administrator is really a recommendation rather than a requirement. The actual requirement is:

Account must have the 'logon as service' privilege
Account must be able to connect 'backwards' to the Visual Studio computer over the network. For this reason, on a domain, its easiest if the service is running under Local System, Network Service, or a domain account. If you want to run it as a local account see: http://blogs.msdn.com/greggm/archive/2004/10/04/237519.aspx
Account must have rights to debug the target process. This means the service needs to either run under the same account as the process to be debugged, or the service needs to run as an administrator.

We recommend running the service as an administrator because:

The service only allows connections from administrators, so there is no security reason why running it as an administrator is bad.
Running it without administrative privileges may put the user in a situation where the Visual Studio user has access to debug a particular process, but since the remote debugging service lacks these rights the Visual Studio user is not allowed to debug the process.
It’s a lot easier to setup this way, and there is enough that can go wrong with remote debugging already.

Exception Filter Inject

2008-04-21T22:14:00Z

Recently I have found the need to have an exception filter in some C# code that I have written. Since there is no language support for this, I wrote an IL instrumentation tool:

http://code.msdn.microsoft.com/ExceptionFilterInjct

For debugging scenarios, the value of this tool is to make it easier to save a minidump of exceptions. Unfortunately, there is not yet a rich Visual Studio experience for managed minidumps, so you will need to use sos.dll (see http://msdn2.microsoft.com/en-us/magazine/cc164138.aspx).

Advice on creating a code generator

2008-03-28T21:07:00Z

I have been spending some time recently creating a custom code generator that outputs C++ and C# code from a custom XML format. This blog is about some of what I have learned while working on this.

Advice #1: Use '#line'

There is a really cheap way to get a debugging experience for your custom language: #line. With #line, you get to change the debug info that ilasm/csc/vbc/cl writes into the PDB so that the debug info points back to the original source file instead of the one that your code generator creates. This is quite handy if you custom language has at least parts where there is a strong connection between the generated code and the custom language. Notes:

There is not a similar technique to allow you to re-associate variables, so I would advise using the original names of variables if possible.
If a line of the original source expands to multiple lines of the generated code, just repeat the #line before each line of the generated code.
There is an issue with this technique if your source language is XML-based in VS 2008 RTM. Visual Studio hopes to correct this problem in SP1.
In C#, you can use this technique with #pragma checksum to set the checksum of the source file. This is useful if you expect to have a bunch of source files with the same name (ex: default.aspx) or if you are already grabbing the checksum for some other reason. Otherwise, it is probably overkill for a custom code generator. Note that the GUID with #pragma checksum identifies the hash algorithm (ex: MD5 is { 406ea660-64cf-4c82-b6f0-42d48172a799}).

Example:

Generated file:

static void Main(string[] args)

{

#line 1 "HelloWorld.ExampleLanguage"

Console.WriteLine("Hello World");

#line default
}

HelloWorld.ExampleLanguage (custom language source file):

Hello World

Advise #2: Use XML

XML is a great way to do a custom language these days because at no cost, you get a lexer, a parser, syntax validation, a language sevice, and your compiler gets to work with deserialized classes instead of with text. Here is the procedure that I would recommend:

Figure out what you would like your language to look like by writing a bunch of examples.
Run xsd.exe over your examples to create the start of a schema.
Open up the generated schema and start making changes. You might need to make changes because the generated schema wasn’t specific enough (ex: you have an enumerator that it has represented as a string), or because your examples had bugs in it, or because you want to add documentation.
Once you have the schema vaguely correct, it is time to use xsd.exe to create class files from your schema. This allows you to use XmlSerializer.Deserialize to create classes from the input XML with little work. You want to create a build step to do this as you will be changing your schema often.
Hookup the schema file so that you can run it as part of compilation. This provides you with a pretty good set of validation without effort. I did this by embedding the schema as a resource in my compiler, but obviously you could also leave it as a file that your compiler opens.
(Optional) Use sgen.exe to generate the serialization assembly -- XmlSerializer depends on a generated assembly to perform the serialization/deserialization. By default, this assembly is generated dynamically, but you can also use sgen.exe to generate this assembly up front.
When you edit your language, edit in Visual Studio and make sure that the XML editor has your schema open. The XML editor will pick up schema items that are in your project, and it will also pick up schemas that are in the Visual Studio 'schema directory'.

Example target for running xsd.exe:

<Target Name="GenerateXSDClasses"
    Inputs="Example.xsd"
    Outputs="$(IntermediateOutputPath)\Example.cs">
    <Exec Command="$(RunManagedToolPath) xsd.exe Example.xsd /classes /fields /namespace:ExampleCompiler /out:$(IntermediateOutputPath)"/>
</Target>

</ItemGroup>

You would also need to wire the target into a property group that runs before compiling

Example of embedding the schema as a resource:

Example of using the schema:

public static void InitializeSchema()

{

if (s_schemaSet != null)

{

throw new InvalidOperationException();

}

System.Reflection.Assembly ThisAssembly = typeof(MyType).Assembly;

Stream stream = ThisAssembly.GetManifestResourceStream("ExampleCompiler.Example.xsd");

XmlReader schemaDocument = XmlReader.Create(stream);

s_schemaSet = new System.Xml.Schema.XmlSchemaSet();

s_schemaSet.Add("http://schemas.microsoft.com/vstudio/Example/2008", schemaDocument);

s_schemaSet.Compile();

}

XmlReaderSettings settings = new XmlReaderSettings();

settings.ConformanceLevel = ConformanceLevel.Document;

settings.Schemas = s_schemaSet;

settings.ValidationEventHandler += MyValidationEventHandler;

settings.ValidationType = ValidationType.Schema;

using (XmlReader reader = XmlReader.Create(filename, settings))

Advise #3: Check in the custom compiler output

If you are writing a very high quality compiler that you are trying to productize then, when people use your compiler, you would have them wire it into their build process such that they would input your custom language and get back a dll or exe.
But this is not necessarily the correct bar for a custom code generator. In my case, I am creating a truly custom compiler. Very few people are going to author the input language, and it doesn’t make sense to expend valuable QA resources directly testing the compiler (rather they would test the generated code). So rather than taking the output of my compiler and directly building these files, I instead checkin the compiler output as a baseline, and the build process runs the custom compiler and compares the output to the baseline. If they differ, it issues a build error.

There are a number of valuable properties that I get out of this 'baseline' approach:

If I edit the compiler, testing the compiler becomes very simple. I just do a build and see if I got the same result that I expected.
If I edit the input, I get confirmation that the compiler did what I expected. I need to diff the baseline output against the new output and validate that I got expected changes.
Compiler bugs turn into build breaks. If I had a bug in my custom compiler where the output was incorrect, rather than going silently unnoticed instead the bug turns into a build break.

Automatically reading source files from TFS

2008-03-20T01:53:00Z

I recently stumbled upon a blog that explained how to use the Source Server technology to enable the debugger to automatically download source files from TFS. This is useful when you work on a software project that is large enough that you debug against modules that are built by your build lab instead of being built locally.

Here are instructions for setting up Team Build: http://jelle.druyts.net/2007/12/09/SettingUpSourceServerForTFSBuilds.aspx

After doing this, you will also need to configure the debugger. John Robins has instructions for doing that in MSDN Magazine. Go down to the 'Debugging in Visual Studio 2005' section.

The debugger team is expanding

2008-03-18T02:42:00Z

The Visual Studio Debugger team is expanding, and is looking for candidates. If you are interested in applying for a position, we have openings in Dev, Test and PM.

Some great things about working on the debugger:

You are helping to improve a tool which millions of developers use every day. There are few software development tools which impact more people.
You get to use what you sell. There aren’t too many places where you can work on software that you also get to use. But you will have this experience on the debugger team.
You get to play with lots of cool technology. People are always inventing new platforms, and they are always going to need debugged.
Great team -- you will get to work with a team of talented and fun people. You will also get to work with me :)