John Robbins' Blog

PDC 2008 Thoughts

2008-11-07T00:17:08Z

Just when you thought everything was said about the PDC, I thought I'd add a couple of notes from my perspective. I'd planned on doing this earlier, but am still recovering from all the parties and had to wait for the Mike Mathis to upload the best picture of the PDC, which is below. Fellow Wintellectual Bethany Jones and I are pointing at something very familiar to .NET developers the world over. We had just done the Simpson's Ride at Universal Studios and were looking at the photos they take of you on the ride, when BAM, we were looking at a NullReferenceException! Even at a party, I can't get away from my job! Sadly, there wasn't a keyboard on the kiosk or I would have debugged it for them.

As always, we had quite a blast at the PDC and got to talk to a ton of folks at the Wintellect booth. I enjoyed finally meeting Keith Hill to thank him for the Power Shell Community Extensions, which I use every single day. Also, I was thrilled to meet Greg Duncan, the guy who reads a billion developer blogs so you don't have to! Greg has saved us all countless hours by sifting through all the stuff going on in our world and posting the most important stuff. I also got to meet one of my heroes, Mario Hewardt, the co-author of Advanced Windows Debugging, the book I always wanted to write but am not smart enough to do. Now I just need to find Daniel Pravat, the other co-author.

As the PDC is always the place to be in our business, the booth traffic was fantastic. I had far more interesting conversations than I can count. Thanks a million to all of you that stopped by the booth because I enjoyed meeting all of you. Like past shows, we had the Wintellect Challenge to test your developer knowledge. In honor of Jeff Prosise's pre con, the questions were all on SilverLight. If you got four correct, you got a t-shirt and if you got five out of five, you got the amazingly, super cool, make-all-your-friends-jealous, Willie the Wintellectual bobble head. Jeff did too good of a job in his pre con because we ran out of bobble heads by the end of the show. Next time we'll make the questions harder!

On the first day, I wore my 1993 PDC polo shirt thinking it would establish my true geek credentials. Sadly, not many people noticed the shirt. However, those that did all were amazed I could still fit into a 15 year old shirt. Frankly, so was I! As I was looking around the PDC, I realized why almost no one recognized my shirt: most of the attendees were in first grade in 1993.

To me, the most exciting things announced at the PDC were, of course, the new stuff coming up from the Diagnostic team in Visual Studio 2010. The Historical Debugging will literally change the way you use the debugger! Being able to step forwards and backwards as you're debugging mean it will be so much easier to solve problems. I also love all the cool stuff coming up in the profilers as well such as a much improved UI and Contention analysis where you'll finally see when and where you're grabbing all your synchronization locks. Oh, I almost forgot mention that now you can open up managed minidumps in Visual Studio 2010 and you'll be able to see everything from variables to call stacks and everything in between. That will definitely cut down on much of the SOS pain.

As for the big announcements at the PDC, I thought Windows Azure will be very interesting going forward. The idea of letting someone else worry about the hardware and networking appeals greatly to me. I absolutely loved the federated ID integration so you can project your Active Directory user accounts and permissions into the cloud. As a small business owner, I would love to move some of our internal systems into Windows Azure as soon as possible. Of course, there are still a huge number of questions to be answered about what we can and can't do when running under Windows Azure. I've seen no discussion of debugability and diagnostics and that concerns me a little. Its one thing to debug an Azure application on your desktop (would that be called the "Fog" environment?), we all know that most problems only occur in production.

I was joking around at the PDC that with Windows Azure, everyone will know exactly how much their bugs cost. I'm sure Microsoft will be charging for storage, CPU, and bandwidth. If you've got a runaway loop someplace, you'll see that reflected directly in your billing. Being able to quantify exactly how much you'll save with efficient coding will definitely help justify investments in code quality.

Of course, Windows 7 is big news and so far the impressions around the web seem to be quite positive. I thought it was brilliant when Steve Sinofsky demonstrated Windows 7 running well on a machine with 1GB RAM. That did more than anything to dispel any preconceptions about using Vista as the base for Windows 7. I'm also happy to see a lot of work going into the new user interface options which I believe will improve everyone's productivity. Of course, I do have to say that after 15 years it's really nice that we can finally rearrange the tabs in the taskbar!

A friend of mine who didn't make it to the PDC asked me how I thought PDC 2008 compared to the previous ones I'd attended. I thought PDC 2008 was one of the more important ones. Like the 1993 PDC, you knew this is a time where Microsoft is betting the company on a new direction. Obviously Windows Azure and Oslo are game changers, but this also marks the third release of Visual Studio Team System and Team Foundation Server. TFS is bringing testing and debugging tools we've only dreamed about before. It's one heck of an exciting time to be a developer!

Save the date: PDC 2009 will be November 17-20, 2009 back in Los Angeles!

Totally Awesome Windows Trick

2008-10-23T05:48:24Z

While I prefer the term "particular", some (especially my wife and all my friends) would call me "anal-retentive." For example, I am, ahem, particular where my windows show up on the screen. I have all the applications I run set to their specific locations and nothing makes me uninstall an application faster than one which can't remember its last location. OK, maybe I need to come to terms with the fact I am anal retentive.

As usual I was running a million applications and everything was going swimmingly. Somehow I manage to right click in the task bar and accidentally clicked the Show Windows Side by Side context menu item:

My world came crashing in on me because here's what showed up on one of my monitors:

Ahhhhhhhhhh! My! Windows! Moved! For someone as anal-retentive as me the only response at this point was a sever hyperventilation session. I definitely did not want to spend the next hour rearranging all the windows on all my monitors again. Out of frustration I walked away from the computer (OK, I got a beer), and I sat down prepared to manually move everything back.

Thanks to the beer, I had a small brain storm: I wonder if CTRL+Z works? Figuring I had nothing to lose, I gave CTRL+Z a press and all my windows moved back right back to where they originally were! I immediately raised my beer and toasted in the direction of Redmond (40 degrees magnetic from where I sit). Totally, completely and utterly awesome! I'm running Vista so I double checked this on Windows XP and it works there as well.

Some of you are thinking "yeah, duh, that's been in Windows for a million years." Well, I've been using Windows for a million years (since 1.04!) and I've never known this butt saving trick was there. To me, little things like this fall into "the great customer service" bucket and it's a great example for all of us to follow. While not the greatest customer service story ever, I'm definitely happy to be using Windows right now!

PDC Open Session: The Future of Diagnostics and Debugging/Tuning

2008-10-22T23:42:18Z

There's a ton two tons of interesting stuff coming up from the Diagnostics team in Dev10: the kind of stuff that completely changes the way you debug and tune! John Cunningham, the development manager for all diagnostic tools in Visual Studio, and I were talking and we thought it would be great to have a community discussion on the future of diagnostics, debugging, tuning, and tools. I know there's a lot of interest in the topic now that we move to cloud and wide distributed computing. Do you have ideas how you think tools and techniques should work in the future? Do you want to hear more about people who live and breathe debugging and performance tuning are thinking what your world will look like? Most of the Diagnostic team dev leads and managers are speaking and/or working at the PDC and will be at this open space session. They want to hear your thoughts as well as share their own. Tell your friends to be there, it'll be the most interesting discussion at the PDC.

It looks like I can't create the open session from the PDC web site and only at the PDC so John and I though the best time would be right after his talk on Tuesday October 28 at 1:30. That way you've had the chance to see the amazing stuff coming up in Dev10 and will be primed to talk about the near future as well as the tools and techniques you'll be using in five years. I'll post the final time and room here on my blog as well at the Wintellect booth at the PDC. Spread the news far and wide, here's your chance to really sit down with the Diagnostic team and make your voices heard!

See You at the PDC!

2008-10-22T23:40:59Z

This is like my seventh PDC! My first PDC was 15 years ago in 1993 and I still have the Windows plastic slinky on my bookshelf. Anyway, I'll be at the 2008 edition of the PDC so please stop by the Wintellect booth and say hello. As I'll be at the PDC to see some of the new stuff too, I'll be in and out of the booth all day. If you do come by the booth, I'll be the one avoiding doing any work so I'm easy to spot.

Jeff Prosise will obviously be there as he's giving the SilverLight pre-con on Sunday. As it sounds like six million of you have signed up for it please do me a huge favor and give Jeff a hard time for me. Seriously, Jeff has all sorts of great stuff to truly get you up to speed on the hot off the web release of SilverLight.

There's going to be some great debugging and tuning talks at the PDC you have to put in your schedule. The first is Visual Studio Debugger Tips & Tricks by John Cunningham (Tues, 12:15). John leads the Visual Studio Diagnostic Team and has been working on the debugger basically forever so you'll really see how to take advantage of things in it. Another session on your must see list is Improving .NET Application Performance and Scalability by Steve Carroll, Ed Glas (Weds, 1:15). Steve and Ed live and breathe the Visual Studio profiler so you'll learn how to find those hard performance problems easily. I expect everyone to be at both of those sessions!

CrashFinder 2.8 – Yes, Native Code Still LIVES!

2008-10-22T01:19:00Z

While .NET gets all the press, love and attention, hard core C++ native development still pays the bills for many of us. As it's just a few days before the mass geekfest which will be all about everything .NET I thought it was time to release a new CrashFinder! Grab the latest version here with all its 32-bit and 64-bit goodness. I've fixed all the bugs everyone's reported so this is the one you'll want to use.

As Visual Studio 2008 has been out for over a year, and I needed to update the symbol engine code to use later versions of DBGHELP.DLL, I've had to drop support for previous versions of Visual Studio. If you do need to use an earlier version of the compiler, you'll need to set up the latest Platform SDK and use the headers and libs from it. If you don't want to destabilize your development environment, you can probably just get by with copying DBGHELP.H and DBGHELP.LIB and setting up your project to include and link against them respectively, as that's all that you need.

Speaking of DBGHELP, I was asked a good question the other day: if I want to use tools like CrashFinder, or do my own symbol loading, how to I use a symbol server? If you read the docs for SymInitialize, it says if you set the second parameter, the symbol path, to NULL, DBGHELP.DLL will use _NT_SYMBOL_PATH to find symbols. The person asking the question was deploying the latest DBGHELP.DLL from WinDBG with their application but they never saw symbols from the Microsoft symbol servers in their load application. To get the full symbol server support, you'll also need to drop SYMSRV.DLL in the directory where you install DBGHELP.DLL. The Debugging Tools for Windows package (AKA WinDBG) includes the most recent DBGHELP.DLL and SYMSRV.DLL. The great news is that both are fully redistributable with your applications. If you need to prove this to your company's lawyers, see REDIST.TXT in the Debugging Tools for Windows directory.

Most of you reading this don't remember the original article for which I wrote CrashFinder, which was over ten years ago in April 1998 Microsoft Systems Journal. (For some reason lately I have felt compelled to scream "Get off my grass!" and take naps.) I've been deeply honored over the years for everyone who's told me they found it useful. Thank you.

As always, if you find any bugs or have feature requests either write in the comments or email me (john at this company's domain).

WinDBG .cmdtree File That Eases Some SOS Pain

2008-09-17T18:55:00Z

Roberto Farah and Brad Wilson figured out the undocumented, but extremely cool .cmdtree WinDBG command. It lets you create a custom WinDBG window that contains any commands you want displayed in a tree control just waiting for you to double click on them. It makes using WinDBG a lot less painful, especially for SOS debugging.

Since I do a lot of SOS debugging, I created the following .cmdtree file to make using SOS a little easier. I've also included Steve Johnson's great SOSEX extension as well.

windbg ANSI Command Tree 1.0
title {"SOS Commands"}
body
{"SOS Commands"}
{"Load SOS and SOSEX"} {".loadby sos mscorwks;.load sosex"}
{"Modules"}
{"All Modules"} {"lm D sm"}
{"Loaded Modules"} {"lmo D sm"}
{"Loaded Modules (verbose)"} {"lmvo D sm"}
{"Modules w/o symbols"} {"lme D sm"}
{"Threads"}
{"Managed Threads"} {"!threads"}
{"Native Threads"} {"~"}
{"Thread Pool Threads"} {"!threadpool"}
{"Sync Block Deadlocks"} {"!dlk"}
{"Stacks"}
{"Current Managed Stack"} {"!clrstack"}
{"Current Managed Stack Parameters and Locals"} {"!vars -w"}
{"Current Native Stack"} {"kP"}
{"Current Dump Stack"} {"!dumpstack"}
{"All Managed Stacks"} {"~*e!clrstack"}
{"All Managed Stack Parameters and Locals"} {"~*e!vars -w"}
{"All Native Stacks"} {"~*kP"}
{"All Dump Stacks"} {"!eestack"}
{"Memory"}
{"Stack Objects"} {"!dso"}
{"GC Heap"} {"!eeheap -gc"}
{"Heap Stats"} {"!dumpheap -stat"}
{"Objects > 500 bytes"} {"!dumpheap -min 500"}
{"Objects > 1000 bytes"} {"!dumpheap -min 1000"}
{"Gen 2 Objects"} {"!dumpgen -stat 2"}

Because the file format the .cmdtree command is fairly fragile, you can download the above file here. When it comes to creating your own .cmdtree files, always makes sure to leave a blank line at the end of the file or the .cmdtree command can't load the file. Also, only use one space for indenting and separation.

After you fire up WinDBG, to show the Window, execute the following command:

.cmdtree c:\util\sos-cmdtree.txt

In playing around with the .cmdtree command, I noticed that WinDBG happily lets you execute the command multiple times so you can open up different sets of command files. While SOS will always be a little painful, with the .cmdtree command you don't have to type as much anymore.

NetMassDownloader 1.5 Has Complete Support for VS 2008 SP1

2008-08-31T04:30:48Z

Now that the .NET Reference Source Code for .NET 3.5 SP1 has made it up to Microsoft's servers, Kerem Kusmezer and I updated NetMassDownloader to support populating your symbol server cache directory with all the source code and symbols. Microsoft did some tweaks to the debugger with SP1 and the symbols are expected to be in a MicrosoftPublicSymbols directory under your symbol cache in order to download the reference source files in the debugger. I also cleaned up the program output, fixed a problem where NetMassDownloader wasn't delete temporary files correctly, and handled the case where the download PDB files have source server information but is missing the HTTP download info.

If you've used a prior version of NetMassDownloader, it's probably best if you delete your cache directory and start fresh. Also note that NetMassDownloader 1.5 assumes that if you are using VS 2008 you have applied SP1. VS 2005 and CodeGear are still supported as they were before.

If you're like me and want to use both the reference source code server (http://referencesource.microsoft.com/symbols) as well as Microsoft's normal public PDB server (http://msdl.microsoft.com/download/symbols) so you can get the public symbols for the operating system and the other things you debug, you'll find that the debugger downloads the symbols to both your symbol cache directory and the MicrosoftPublicSymbols directory underneath it. Since not everyone uses both Microsoft symbol servers, I didn't add the support to NetMassDownloader to copy the symbol files from the MicrosoftPublicSymbols to the main symbol server cache. I manually copied the folders after running NetMassDownloader and the debugger is happy.

With the recursive directory support in NetMassDownloader, it's trivial to grab all the .NET 3.5 SP1 reference source. Here's the command line I used on Vista x64 to grab both the 32-bit and 64-bit .NET binaries:

Netmassdownloader –d c:\windows\Microsoft.NET –d "c:\Program Files\Reference Assemblies"

With an empty symbol cache, it'll take a while so you might want to let the command run over lunch. If it's still running when you get back, there's always Solitaire.

As always, please file bug reports and features request as the NetMassDownloader page on CodePlex.

So You Want To Set a Windows Journal Recording Hook on Vista? It’s Not Nearly as Easy as You Think!

2008-08-30T01:37:09Z

Eons ago in Internet years, I wrote what proved to be a very popular tool, Tester, the latest edition appeared in my second book. With it you could record and playback UI automation scripts. While Tester wasn't perfect, the number of companies using it as their automation tool of choice was very gratifying. In fact, there were so many, I probably should have made a business out of updating and supporting the tool. At least it was very gratifying to know I'd produced something useful!

Since I rarely do any UI development, I don't need Tester that much myself. Today, I had a need so grabbed the code with the thought of giving it a quick dusting off so I could use it on Vista x64. After 20 minutes of some tweaks and adjustments to move the application to 64 bits, the real work started. My debug builds were always asserting because SetWindowsHookEx was returning false when my recorder application tried to set the WH_JOURNALRECORD journal recorder to record all the mouse and keystrokes. The last error value was access denied so I simply thought that I needed to run the recorder process with elevated rights. If only it were that easy, because I still got the access denied when running with high integrity as well.

It turns out lots of people were reporting the same issue, but all the reports were from way back in the Vista beta days. After several hours of searching I'd run across several articles where there were discussion about how the journal recording hook was used by key loggers and other nefarious programs so Microsoft was making changes in Vista to close that hole. While I was all in favor of closing the hole, how in the heck was I going to get my simple recorder application to work?

According to some of the forum reading it looked like people got journal recording working by turning off UAC. That was totally unacceptable to me as I have written before I like UAC. Anyway, turning off UAC just for journal recording was the easy way out and made me feel dirty. I dug in for battle and fired up the search engines hard. As I never found this information in one spot, I thought I'd put it here in case someone else wants to use a journal recording hook.

Your program's manifest has to be set to requireAdministrator for the execution level. Because a journal recording hook falls into the accessibility portion of windows, the uiAccess must be set to true. Here's how you'll set those up in the Linker, Manifest File section of the property page:
The output binary must be digitally signed with a valid certificate. Read about how and where you can get reasonably priced certificates here.
You won't be able to run your application where you built it. This was the hardest item for me to figure out and it wasn't until I ran across a random forum entry that provided the missing clue. You must copy the binary that sets the recording hook into a directory under the C:\Program Files directory. That's the only acceptable place for accessibility applications to run. By copying the binary, you can run the application and get your hook set. Of course, if you are going to distribute your application, you'll need to have your installation put it in the C:\Program Files directory and not allow the user to change it.
You won't be able to start your binary under the debugger even if it's properly located in the C:\Program Files and you've started the environment with elevated rights. Visual Studio will give you the following error:

Unfortunately, clicking on the Help button brings you to a "Information Not Found" page so it's a mystery. For you WinDBG users out there, the uiAccess set to true bothers WinDBG as well if you try to start the application from the debugger:
To debug your journal recording application, you'll have to start it and attach the debugger. You'll want to make sure your application gives you a chance to attach before you start doing a lot of work.

Since this took three hours of my life to figure out I thought I'd share the solution in case someone else needed the information. While it would have been nice to have all this information in the journal recorder documentation, I'm really glad Microsoft shut down the security hole!

Random Thoughts on Visual Studio 2008 SP1

2008-08-12T05:23:04Z

As the world knows, Visual Studio 2008 SP1 is out so start your download engines. I've installed it on one machine so far and I thought I'd mention a few things I found interesting.

The install took exactly an hour for me and was far better than the Visual Studio 2005 SP1 torture. After the first Next click I just let it run and didn't have to baby sit it. I installed off the ISO version as I didn't want to take any chances. I wanted all the bits with me as I was more afraid of a partial or corrupt install with the "piece at a time" download. The machine I installed on had the Team Suite edition so I knew I'd need everything anyway.
While many Microsoft folks have blogged about their team's particular adds to SP1, you can find the complete list of added features and bug fixes in Knowledge Base article 945140. Based on the number of features added, the version number really needs to change. However, I'm not complaining!
All my .NET applications certainly feel much faster because of the .NET Framework 3.5 SP1 speedups. I wish I would have taken some startup timing statistics because even WPF applications start reasonably quickly now.
Visual Studio has a new icon! I guess that will make it easier for us to tell the difference between Dev 9 and the rapidly approaching Dev 10.
Is there a story behind the option dialog UI change? Notice that the checkboxes are now flat instead of 3-d.
I love the new debugger option to cancel Symbol Server PDB file downloads. This is a great option on slower connections:
Another favorite debugger feature is that on managed code the debugger looks when you are stepping into a method and if it's a small property or operator, it turns the step into a step over. Now you don't have to apply the DebuggerStepThroughAttribute to all your one line methods.
Now the debugger knows about the .NET Reference Source Code out of the box. Unfortunately, as far as I can tell, Microsoft has not posted the correct PDB files for the .NET 3.5 SP1 release. There are PDB files up on the public symbol servers, but they do not contain any of the Source Server indexing. The previous version of System.PDB was 6.68 MB. Now it's 595 KB and definitely contains none of the appropriate reference strings. Also, my NetMassDownloader just returns Bad Request when trying to access the code. I'll let you know what I find out from Microsoft.
My personal favorite new feature is that Step Into Specific has finally made it to managed code. Say you have a line of code like the following:

OuterMethod ( InnerMethod ( ) );
Prior to SP1, if you did a Step Into, you always stepped into InnerMethod whether you liked it or not. Now, if you want to step into OuterMethod, right click on the line and behold the magic of Step Into Specific:
The TFS updates are totally dreamy. Brian Harry has the complete list here.

Just Where Did Those Performance Counters Go?

2008-08-01T21:53:41Z

On a particular Vista machine, I was setting up a PerfMon view to monitor the .NET memory performance of an application and ran into a problem. The.NET Memory # Bytes in All Heaps Performance Counter wasn't in the list of performance counters. That was quite odd so I checked if that Performance Counter was there in Process Explorer by adding it to the main window display. Since Process Explorer has all the Performance Counter names hard coded, that would tell me if the problem was with the Performance Counter Library itself as PerfMon builds the list dynamically.

After pressing OK, Process Explorer showed no values at all in the columns. That pretty much proved that there was something seriously wrong with the Performance Counters on that particular machine. Without those performance counters it's pretty hard to do monitoring and performance tuning! Comparing two machines side by side, I noticed that the problem machine was missing a metric ton of other Performance Counters.

A few quick internet searches got me to the Microsoft KB article 300956, which discusses how to manually rebuild Performance Counter Libraries. If you read over that article, you start to get very scared very quickly because it tells you to manually replace files on the machine with the files from the installation CD, a bunch of manual registry editing, and so on. Fortunately, at the end of the article, they mention that running LODCTR /R from an elevated prompt (note the /R uppercase is required) will rebuild the Performance Counter Library including third party and extension performance counters.

Figuring I had nothing left to lose, I gave it a run. After shutting down PerfMon and Process Explorer, I restarted both and was very happy to see all the Performance Counters reappeared. After a big sigh of relief, I thought I'd write up what worked in case you are missing some Performance Counters. Of course, this advice comes with the usual Internet warning: Worked on My Machine ™.

Debugger Settings Visual Studio Add In– Easily Copy Breakpoints between Machines

2008-07-21T02:45:18Z

So there I was knee deep in a great debugging challenge. On one machine, I had set up somewhere around 15 advanced breakpoints that had all sorts of properties set such as conditionals, hit counts, and so on. As I was feeling like I was getting close to the bug, I wanted to set up an identical debugging session with those breakpoints on another machine. While I could have manually recreated all those advanced breakpoints, I tried to cheat. Your breakpoints, along with Watch window variables, window layout, and other session state items are stored in a hidden file, <Solution Name>.SUO. I copied that file over to the other machine and opened the solution file. Visual Studio promptly crashed.

The .SUO file is the bane of your existence. Nearly all the problems you encounter with Visual Studio are the result of a corrupt .SUO file. Sadly, it seems all it takes to corrupt the .SUO file is your heart beating. In other words, whenever you have Visual Studio crash, refuse to debug, or behave strangely it's the .SUO file's fault. Whenever anyone asks me about strange Visual Studio behavior, my instantaneous response is "Delete the .SUO!" When it comes to Visual Studio hygiene, deleting the .SUO file is right up there with cancer screenings.

As I am tired of manually setting my breakpoints again on other machines and sick of the .SUO corruption bug I decided to solve it once and for all. I wrote a Visual Studio 2008 add-in, Debugger Settings, which makes it easy to save and restore your solution's breakpoints. It also makes it easy to create and apply different breakpoint sets on a solution, which is something I've wanted in Visual Studio for a long time. You can download the code for Debugger Settings here.

Debugger Settings is at version 1.0 and I would love to hear your feedback. Please note that I've only done my testing on Visual Studio Team Suite, but Professional Edition and above should have no trouble. Debugger Settings will not work with the Expression versions as they do not support extensibility.

Debugger Settings currently only saves and restores breakpoints but does work with both .NET and native C++ projects. I would love to be able to get and set the Watch window variables, but it does not look like that can be done without extensive reverse engineering. However, if there's enough demand, I might be persuaded to give it a go. Another feature I'd like to add is the ability to save and restore custom Exceptions added to the debugger's Exception dialog. Please let me know if you have other features or find problems.

Installing Debugger Settings

After downloading the zipped code, unzip it keeping the directory structure intact.
You may not need to do this step, but I've always had problems with Visual Studio not loading my add-ins correctly if I put them in the defalt Documents\Visual Studio 2008\AddIns directory. That may be because I've got my Documents directory in a domain redirected folder. If you get a FileNotFoundException with a code of 0x80131047 attempting to load Debugger Settings, you'll want to add the <unzip dir>\DebuggerSettings\Debug directory to the Add-in file paths by going to the Options dialog, Environment, Add-in/Macros Security dialog:
Because Visual Studio has a problem finding assemblies in the same directory as the .AddIn file, you'll need to edit <unzip dir>\DebuggerSettings\Debug\DebuggerSettings.AddIn and in the Assembly elements, enter the complete path to DebuggerSettings.DLL.
Restart Visual Studio.

Using Debugger Settings

Debugger Settings works mainly in the background, but you can set its options in the Options dialog.

By default, Debugger Settings will save any breakpoints you have set when you close a solution to a .DebuggerSettings file in the same directory as the solution. When you open a solution, Debugger Settings will look for the .DebuggerSettings file and reset any breakpoints that were not set from an existing .SUO file.

Debugger Settings adds four commands to the IDE, which should be self explanatory:

DebuggerSettings.RestoreFromFile
DebuggerSettings.RestoreSolution
DebuggerSettings.SaveToFile
DebuggerSettings.SaveSolution

As an example, to save a set of breakpoints to a named file, you'll go to the Command window and execute the DebuggerSettings.SaveToFile command. If you don't specify a filename as the parameter to the command, you'll be prompted for the filename with the File Save dialog.

There are four types of breakpoints that Visual Studio supports: file, function, address, and data (for native C++ development). My original intent was to support all the breakpoint types, but when you attempt to set an address or data breakpoint through the Visual Studio automation model, the breakpoint is immediately set to disabled. Hopefully a future version of Visual Studio will let us automate setting those two breakpoints. The good news is that file and function breakpoints are the huge majority of breakpoints. I implemented the work to set address and data breakpoints in case this gets fixed in the upcoming Visual Studio 2008 Service Pack 1.

One other limitation of the Visual Studio automation model is that there's no way to know if a Tracepoint has the message disabled. The Breakpoint2.Message property is always set to the default string value. Thus, if you have a Tracepoint set to execute a macro, but not output the trace string, as shown below, Debugger Settings will enable the Print a message checkbox simply by setting the Message property.

Wrap up

The implementation of Debugger Settings is very straight forward. The only moderately interesting technique I used was to work around the fact that the Breakpoints.Add method does not support setting Tracepoints directly. Visual Studio's code metrics reports only 467 lines of code so far in Debugger Settings. If I can figure out how to get the Watch window variables, I'm sure the code size will grow exponentially.

Let me know either in comments to this entry or through email (john at this company's domain) if you find Debugger Settings helpful or find problems. Also, any feature requests strongly considered.

Paraffin 1.04 – A New Switch and Easier Updates

2008-07-11T22:42:19Z

If you're using WiX 2.0, my Paraffin tool can help you automate some of your setup chores. To read more about Paraffin, see the three part article, Part 1, Part 2, and Part 3.

Thanks to Matthew Goos who sent me the patch, there's a new –dirref when creating the initial .WXS file. That allows you specify the DirectoryRef element Id value. The default is INSTALLDIR.

When updating an existing file, I now allow you to specify both –ext and –direXclude switches so you can add additional extensions and directories to ignore. Any new ignored extensions or directories are added into the output file comment section so they are there the next time you update.

Thanks to all of you who have downloaded Paraffin. If you're using Paraffin, please let me know as I'm curious if others find it useful. Numerous people have asked if there's a WiX 3.0 compatible version on Paraffin. Right now there isn't but I'll update Paraffin to support WiX 3.0 as soon as the WiX team declares a stable 3.0.

Grab the latest Paraffin here. As always, let me know if there are any features you'd like to see or bugs that need squashing.

In Defense of Vista and the Challenges Facing Windows 7

2008-07-10T06:13:45Z

Perception is everything. That applies to everything in life and certainly applies to Vista. It doesn't take much web searching to find plenty of commentary indicating that Vista has not been well received and is often downright hated. In a lot of ways, I think Vista's been given a bad rap, and my opinion is that it is quite a bit better than it gets credit for. In this article I want to talk about what I think Microsoft did right with Vista. Is it perfect?--of course not, but no software ever is. Additionally, I want to address where I think many of the Vista problems are coming from. Finally, I want to also discuss what I see are the challenges Microsoft faces with Win7 given the Vista perception and how Microsoft can negate them.

Before I start, I need to say that I'm definitely not either a marketing person or much of a business person. I'm software developer who's bet my whole career on developing for Microsoft operating systems. I started with DOS 5.0 and switched to Windows 3.0 as soon as it came out. While some of you will say that makes me old, I prefer to think that means I have a long term perspective on Microsoft and its position in the developer mindshare. As a reminder, these opinions are my personal opinions.

Vista, especially after SP1, is definitely better than Windows XP. Every time I have to use Windows XP or Server 2003, I find myself really missing some of the features and abilities I've grown to love in Vista. As I was reading yet another screed against Vista, I jotted down the six key things I find invaluable about Vista. There are many more, but these are the ones that are important to me as a user and developer.

User Access Control (UAC)
The most important point Vista has is that it is the most secure operating system Microsoft has ever released. The reason for that is UAC finally keeps people from running with administrator credentials by default. Having run as a non-admin on XP and Server 2003 for nearly nine years, I'm much happier than I was being forced to use the RUNAS tricks. I can honestly say I've never found the UAC pop ups annoying or too frequent.
While many people have complained that Microsoft should have implemented something like UNIX security, I think UAC is the best compromise for the reality of the Windows world. Microsoft has to deal with a ton of poorly written software from third party developers who assumed everyone was an admin just like they were. While some of this fault lies with Microsoft, a majority of it belongs to developers who won't or can't follow the design guidance. Microsoft has been issuing recommendations and steps for years on how to correctly write software, but developers certainly haven't been listening.
What always bothers me is when I see someone recommending that you turn off UAC. If you turn off UAC and run all processes with administrator rights, you deserve all the viruses and slowdowns you'll get. Microsoft does a good deed working to make the OS secure and these "experts" go off and completely ruin the security. I wish Microsoft had not allowed UAC to be turned off.
Mobile Computing
Another Vista feature that makes my life better is that mobile computing finally works consistently and reliably. Back when I had Windows XP and Windows 2000 on my laptops, it was always an adventure opening a sleeping laptop. You just never knew if it was going to wake up. With Vista on multiple laptops, it's just works.
Search on the Start Menu
The search in the Start menu is simply brilliant. I've become addicted to it and whenever I go back to Windows XP or Server 2003, I'm always stumbling over how to open files or start programs. The OS now gets out of my way and doesn't interrupt my thoughts nearly as much.
Ink Input
As a Tablet PC fanatic, I love how Vista has made ink and the pen first class input for the OS compared to how it seemed to always be a tacked on feature in previous releases. I work best by writing things down by hand and Vista's trainable handwriting recognition means I easily get 98% to 99% accuracy when searching for things in my beloved OneNote. It's very sad how few people have gotten to use a Tablet PC because Bill Gates is right: a pen is a wonderful way to interact with a computer.
Better Scalability
In my opinion, Vista scales better than previous Microsoft operating systems. In the past, I was always in the habit of shutting down applications unless I was actively using them. As a developer, I always gave most of the machine to development tools because the more programs you had running the slower everything got. With Vista, I'm rarely shutting anything down and running tons more applications. Right now on this Vista x64 machine there are five instances of Visual Studio 2008, five PowerShell windows, Winamp with G-Force, three Internet Explorer sessions, OneNote, Outlook, Word, Process Explorer, and those are the just the open windows. I do more on a machine than 95% of users do, and Vista handles it easily.
Fewer Reboots
Finally, I never reboot. What's the old developer answer to everything on Windows? Reboot. Back on Windows 2000, I rebooted three to five times a day. On Windows XP, I generally rebooted every day. With Vista, I only seem to reboot on patch Tuesday. Both my desktops and notebooks running Vista go weeks between reboots.

There are many other positives to Vista, such as Media Center, and so on. Having felt Vista was pretty good, I wanted to give it credit given all the negative reports floating around. I'm definitely not discounting the bad press, because a lot of it is true. What I want to turn to now is where I think the blame lies for the perceptions around Vista.

Many of the problems with Vista have been entirely self-inflicted by Microsoft. From the beginning, they "over promised and under delivered." What it looks like to me is that almost nothing we were promised at the 2003 Longhorn PDC was actually delivered. The stream of announcements saying this feature and that feature were being cut started the Vista perception long before it ever shipped. I know I'm stating the obvious here, but I think it's one of the major issues that affects perception with Vista.

The whole "Vista Capable" fiasco certainly didn't help. The story is that Microsoft labeled computers with Intel integrated graphic chips as able to run Vista, when they clearly could not. (Am I the only one who thinks it's ironic that Microsoft did this to help out Intel, but Intel decides to repay Microsoft by refusing to upgrade its corporate machines to Vista? Wow!) My father got stuck with one of these machines from a major manufacturer and even I couldn't get Vista running well on it. The only sliver of good that would come out of this is if Microsoft really learns a lesson.

While everyone's taken Microsoft to task over Vista, part of the blame also belongs to the computer Original Equipment Manufacturers (OEMs) such as Dell, HP, Toshiba, and Lenovo. It's not like the manufacturers didn't have sufficient warning Vista was coming, but many of the problems people attribute to Microsoft are the direct fault of bad drivers for just about all devices. Add in the horrible out-of-box experience you have with your average computer that comes with Vista installed and it's no wonder Vista looks bad.

Most of you reading this are developers. What do we do when we get a new machine? Completely wipe it out and reinstall the OS. We're fortunate enough to have things like our MSDN subscriptions so we have the real OS DVDs we can use along with the technical expertise to get things working. Your average person is scared to death to do that because they don't know how to get rid of the garbage on the machine so they suffer with it. Even the machine has a backup partition where they can reinstall the OS, that image contains all the garbage the user wants to get rid of in the first place. I'm annoyed that Microsoft has allowed this to happen.

At least there's something average users can do today to avoid this mess: buy Apple hardware. I've blogged about how I put Vista x64 on my Mac Pro long before it was officially supported by Apple. Based on the traffic and comments in that entry, there are quite a few people doing the same thing because they want to control the machine and not just deal with the garbage from traditional PC manufactures.

You'll see in a second why Apple makes the best Vista machines, but first compare my experience with the Mac Pro with the hell I had to go through with my Lenovo X60 Tablet PC. As a super experienced Windows developer who has done everything from drivers out on Windows, it took me eight hours to figure out what was the minimum set of driver software I needed to use the machine. Why can't Lenovo (or Dell, or HP) give me a single install that puts on nothing but the minimum drivers necessary? Apple can do it, why can't the others? I sent a bill to Lenovo for my time getting the machine in the state that it should have been delivered. Unfortunately, I have never heard anything back. Maybe I should turn them over to a collection agency. In Lenovo's favor, they have started allowing us to uninstall some, but not all, of the garbage with their latest machines.

What makes Vista x64 so stable and wonderful on my Apple Mac Pro is that all the core drivers come from Microsoft out of the box. If you can avoid any drivers from a manufacturer and just use those in the Microsoft install, you'll have much better luck because they are so much better tested. I highly recommend never installing any drivers from Windows update that come from any manufacturer. Yes, that includes video manufacturers. Based on my experience over the years I think little or no driver testing is done outside Microsoft. If Microsoft includes it with the OS, it's been really tested and you can trust it.

So this is where we are with Vista today, but Microsoft is hard at work on Windows 7. Microsoft will finally have to deliver "Wow" when they ship Windows 7. They have to under promise and totally over deliver in order to remove the perception problems with the operating system. This is going to be hard, but if any company can do it, Microsoft can. They have great people; they just need to be turned loose.

In my opinion, there are two key things that must be at the forefront for Windows 7 development. The first is that Microsoft has to seriously crack down on the OEMs. They've tried to do this in the past with the Windows Logo program, but it's basically a joke. For the first time Windows Logo must be something with teeth that ensures that drivers and user mode software works correctly. I feel Microsoft must require that every computer manufacturer delivering Windows 7 includes the Windows 7 install disk and a single install that installs nothing but the minimum drivers necessary to make the machine work.

In order to ensure the drivers for everything are solid and workable, Microsoft has to spend some of that pile of cash they have to help anyone developing a driver to get the driver right. This could mean continuing to force more drivers into user mode or it could mean providing even more developer support. It will definitely include developing testing resources to ensure the drivers are beat to death and earn the improved Windows Logo before they can be shipped. It's obvious the device manufacturers are not doing sufficient testing, so Microsoft will have to help them do it.

In the final part of the OEM crackdown, Microsoft also must completely own the initial out-of-box experience for the operating system. Based on how bad it was when I initially booted my Lenovo, where there were actual ads when I logged in the first time, there's no way anyone will think anything favorable about Microsoft. Those initial impressions are critical, and Microsoft can't trust them to anyone else.

The other thing that Microsoft needs to do with Windows 7 is to target today's hardware, not the top of the line hardware for 2010 when it's expected to ship. The relentless focus of the whole development effort needs to be on speed. The average user should go "Wow! I installed Windows 7 on my machine and it feels so much faster now." That's what it will take to completely eliminate the "Vista's a big fat pig" perception that exists today.

Even though I make my living with Windows, I use OS X on a Mac Book Pro for basically one application: iPhoto. I've found nothing on Windows that works as well as it does. I'm not a professional photographer; I just enjoy taking pictures of my vacations and life. iPhoto does exactly what I need to make my photo management simple and easy. I've been using OS X since 10.1 so I've seen a few operating system upgrades from Apple. Each upgrade of the OS always feels faster and seems to do more with less memory. With Windows and Vista today you just know that you have to buy a new computer in order to make the operating system work as advertised. This is Microsoft's last chance to change the perception, so it's absolutely critical.

One of the hard lessons I've learned in my many years of Microsoft operating systems development is "small code is good code." At the World Wide Developer's Conference in June, 2008, Apple announced Snow Leopard, OS X 10.6. You can read more about the feature list in Snow Leopard at Roughly Drafted. What's most interesting to me is that Steve Jobs specifically said that the features are for developers and not the end user.

At first I thought the features in Snow Leopard were interesting, and then word trickled out about the shrinking size of applications under Snow Leopard. The following chart, with full credit to Roughly Drafted, really caught my attention.

Apple's doing many things to shrink down the binaries, but it's blindingly obvious that they are focusing on making everything fast and efficient. That's exactly what Microsoft has to do with Windows 7 to keep in the game. The rumors are that the same version of OS X will run on a small iPhone as well as a maxed out Mac Pro desktop. If that's the case, Microsoft needs to be very worried.

Microsoft really has their work cut out for them with Windows 7. Vista is actually quite good, but the general perception is such that they have to execute to perfection in order to eliminate the negativisms thrown their way. Microsoft has responded very well in the past when they have real competition. With Apple's OS X market share nearly 8%, it's high time for the Windows team and executive management to unleash the creative forces inside Microsoft.

I'm very curious what other developers feel about Vista and what the challenges are for Windows 7. Do you disagree with my good assessment of Vista? What do you think Microsoft needs to deliver with Windows 7? Write in the comments or your own blog entry.

Software Development Meme

2008-07-10T05:44:02Z

So Charles Petzold tagged me for this Software Development Meme and did that hurt. Just kidding. J It's the first time I've been tagged since I was like five years old. Anyway, here goes:

How old were you when you first started programming?

26. Yes, I was a really late bloomer. In fact, that's positively decrepit in the computer world. I'm amazed they even let me use a computer at that age.

How did you get started in programming?

As my first job was Special Operations Communications Sergeant (AKA a Green Beret) the only civilian skills I had qualified me as a night watchman or a member of Tony Soprano's mob crew. Fortunately, I got hired as a manual laborer at an environmental research firm who gave me more than enough rope to hang myself. I needed to track ambient air sampling canisters I was shipping out so I wrote a big Lotus 123 macro driven spreadsheet to help. My bosses were impressed with it and kept giving more and more programming work to do.

What was your first language?

English, which I learned that as a child. Oh, you meant computer programming language, sorry. That would be SAS when I was at the environmental company doing statistical analysis for Non Methane Organic Compound (NMOC) research.

What was the first real program you wrote?

In college at NCSU, I wrote an embedded debugger for an Intel 8051 CPU for the Computer Organization and Logic 311 (Electrical Engineering for CS majors), the "death" class in the CS program. That's what sparked my interest in debuggers and solid code.

What languages have you used since you started programming?

SAS, Lotus 123, Quattro Pro, Turbo Pascal, x86 Assembler, Visual Basic, C, C++, x64 Assembler, C#, and VB .NET.

What was your first professional programming gig?

While in college, I had a full time software engineering job where I wrote a Windows 3.0 GUI application for the Center for Disease Control so AIDS researchers could share information better. It was one of the most motivating projects I ever worked on.

If you knew then what you know now, would you have started programming?

Absolutely! It sure beats getting shot at in the jungle. I feel extremely fortunate that I got started before Windows took over the world and I was able to ride that wild train. I was extremely lucky and was able to start my 32-bit development career the day Windows NT 3.1 Beta 1 shipped in 1992, which made me one of the first outside Microsoft doing NT development. I think that bet paid off.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Learn the insides! If you don't know how the environment you're using works, you have zero hope of understanding how to effectively use it. By knowing how things fit together makes it much easier to figure out when things go wrong as well.

What's the most fun you've ever had ... programming?

Pretty much every time I help solve a bug that has someone stuck. I just get such a thrill out of digging in and fixing a horrific problem. That intensity and focus while you're working with others on hard problems is pure joy.

So Who's Next?

I shall tag my fellow Wintellectuals: Keith Rome, Steve Porter, Sergio Loscialo, Rik Robinson, and Andy Hopper.

Hear My Interview on Debugging

2008-07-09T05:03:44Z

Craig Shoemaker recently interviewed me about my favorite topic, debugging, of course, for Pixel 8. We had a great time on the interview and I even got to tell one of my favorite debugging war stories. We also talked about all the parts of .NET that every developer should know. Head on over to Pixel 8 and grab the download for your Zune/iPod/MP3 Player and hear me laugh a lot.