"Source Server" - The best "Hidden" feature in Whidbey Debugging
On the drive to work today, Chris Sells asked me what was new & cool with Whidbey debugging. Somewhere on my list was "Source Server" support. Chris's ear's perked up at that.
I told him to dig around for an article, as I was sure somebody like John Robbins had already written about it. Turns out, it's not well covered at all (yet).
In a nutshell, source server allows the debugger to download on demand whatever source files you might need. For instance, if I break into a program and it's stopped somewhere in Windows or the CLR, I get the source code, rather than just a disassembly window.
It really is a developer's dream. One of the coolest things I've seen in my 15+ years in this business. Enabling it in Visual Studio 2005 is pretty easy: Tools | Options | Debugging | General, then select the "Enable source server support" button.
What's the catch? For this to work, you need to have a server set up in a specific way to dole out the requests from the debugger. Here at MS, most of our code is indexed on to the source server as part of the build process. Before you ask, I think it's highly unlikely that these will be exposed outside of Microsoft. :-)
However, nothing prevents you from setting up source server for your own code. The documentation and binaries are part of the "Debugging Tools for Windows" goodies. Why there? Because Source Server was originally developed for WinDbg, then subsequently supported by Visual Studio.
While you might not go to this effort if you're in a small development group, I can easily see bigger development organizations jumping on this capability once they know it exists.
Also, before you ask, I'm not the expert on setting up source servers. Never done it myself. I just know where the checkbox is in the IDE, and where the documentation for setting one up is. After all, "It just works!" Why would I need to know anything more? :-)
Comments
Anonymous
August 10, 2005
Actually, I could see this being usefull for smaller groups as well.
Take the Microsoft "Application Blocks" for example - they ship as source and binary. There's probably no point to recompiling it every time with your app and having to worry about all of it's internal complexity.
However, you could put the source from it on the source server and still be able to debug it.Anonymous
August 10, 2005
<<After all, "It just works!" Why would I need to know anything more? :-)>>
This does not fit at all with the Matt Pietrek that used to decompile the Windows kernel, hook API, dig into the internals of anything :-)
Getting old? :-)
Just kidding.
I love all your articles, and now I have discovered the blog.
Thanks, and keep doing it!Anonymous
August 10, 2005
Why wouldn't it fit in with what I did before? For me, reverse engineering is all about the fastest way to the essential information you needed. I always took advantage of the best information sources available. Now I just happen to have better access. :-)Anonymous
August 10, 2005
"Source Server" - The best "Hidden" feature in Whidbey Debugging [Via: Matt Pietrek ]
101 Code Samples...Anonymous
August 10, 2005
Actually documentation and utilities for source indexing are bured in last WinDbg SDK (and support perforce, vss, svn currently)Anonymous
August 11, 2005
Based on what I've seen in the MSDN forums, people are having different problems migrating their code...Anonymous
August 24, 2005
I am only a few months into DirectX programming, but this one just burned me so I thought I would share...Anonymous
August 24, 2005
I am only a few months into DirectX programming, but this one just burned me so I thought I would share...Anonymous
July 16, 2006
If you just want to go to the site: Go here: http://SourceServer.Osherove.Com .A team I work with neededAnonymous
October 15, 2007
PingBack from http://crashopensource.wordpress.com/2007/10/16/going-in-circles/Anonymous
June 16, 2009
PingBack from http://workfromhomecareer.info/story.php?id=2146Anonymous
June 16, 2009
PingBack from http://fixmycrediteasily.info/story.php?id=16700