A long strange trip through WinDbg all because of a powershell script, followed by some linkdumps

72 views
Skip to first unread message

Justin Dearing

unread,
May 4, 2013, 1:41:26 AM5/4/13
to nynj-winterna...@googlegroups.com
I want to write up some blog posts, but that might not happen. I figured I'd put in the long unedited form here. Hopefully I can edit it later, or at least someone can find this via google if it wold benefit them.

It all started when I wrote a powershell script to update the diff and merge tools in Visual Studio. During that time I discovered that while VS2010 has exes for trhe builtin diff and merge, in 2012 it was a DLL in the GAC:
Microsoft.VisualStudio.TeamFoundation.VersionControl, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

So I spent some time looking through the decompiled sources of that dll with ILSpy. I found the diff and merge classes, but I didn't know where the hooks were if I wanted to write my own diff and merge dll. 

I then got the crazy idea that maybe I could debug devenv.exe, set a Conditional breakpoint  to RegOpenKeyEx pointing to the registry key that pointed to the diff program, and watch the diff class get initiated.

Well I figured out how to do that with Visual Studio developer, WinDbg, and Rohits API Mointor. Here are some links relating to that:

Then I discovered on Paul Randal's blog, callstacks generated in SQL Server don't seem to respect the symbol serverJonathan Kehayias showed an easy way to generate call stacks in the ringbuffer. I did some inconclusive research, but from what I've discovered, it should work.

So anyway, I have not actually fully solved either original problem (reverse engineering the DLL entry point for diff merge in VS2012, and using the symbol server for ringbuffer stack traces in Sql 2012), but I've gotten more comfortable with windbg, 

Finally a linkdumo

Reply all
Reply to author
Forward
0 new messages