To each and every one of you who attended my TechEd session – thanks! There are so many interesting talks and I appreciate the fact you have chosen mine.
As I promised, this post is a summary of slides, demo code and the transcripts of each demo I’ve shown throughout the session. (As soon as the session recording will be available, I will update this post with a link to it.)
I divided the demo transcripts into a series of posts because they are fairly long. You can find everything I’ve written regarding the TechEd at the TechEd08 blog tag.
My primary objectives in this session have been to:
- Make you aware of the business importance of production debugging;
- Introduce you to tools that make production debugging as fun and as easy as it can be;
- Emphasize the importance of understanding the theory behind the tools and the frameworks that we’re using.
The issues we have looked at included (in chronological order, not necessarily the degree of complexity):
- Using the Application Compatibility Toolkit to fake an OS version to an application so that is agrees to run;
- Capturing a dump file (using Task Manager, ADPlus, and a variety of other tools) and opening it in Visual Studio;
- Dissecting a managed memory leak using WinDbg, SOS, CLR Profiler and Hawkeye;
- Analyzing a native deadlock using Vista’s WCT and SOSEX‘s deadlock detector;
- Disentangling a thread waiting for an invalid handle using WinDbg, the !htrace extension and Application Verifier;
- Understanding the activity of an application from a bird’s eye view and in a detailed graph using the Windows Performance Toolkit (xperf).
I’ve blogged about some of those tools in the past in a comprehensive post titled Debugging and Investigation Tools.
The first demo I’ve shown has to do with the options we have before diving in and looking at debugger spew. In the first demo, when I launched the PictureViewer client, I encountered the following screen:
Clearly, this application has got to be kidding. I’m on Vista! What is this nonsense about upgrading to Windows 2000 or Windows XP?
Well, it appears that this application is somehow detecting the operating system version, and treating that information incorrectly. If only the original application developers (that’s myself) used a future-OS emulating tool such as Application Verifier… Oh well, what can you do.
To understand how the application is detecting the OS version we have two paths to follow. The first alternative is using Process Monitor to see if the application is accessing the registry or some file paths to determine the OS version. The second alternative is using APIMon or API Logger to determine whether the application is calling an API such as GetVersionEx.
Once we have established the source of the application’s fallacy, we can resolve the “problem” immediately. The Application Compatibility Toolkit features the ability to produce a compatibility shim which is basically a big bunch of lies that Windows can tell to your application. (By the way, the toolkit won’t install on a 64-bit OS.)
One of these lies is a version lie – the compatibility shim can emulate the GetVersionEx API or the relevant registry keys to make sure the application really thinks it’s running on a different version of Windows. There are many cool compatibility shims and much more work going on at Microsoft in this direction, but the one we are looking for in this case is either the VirtualRegistry shim (to redirect registry access) or the other version lie shims.
What you’ll need to do is open the Compatibility Administrator and add a compatibility database for the PictureViewer client application. The compatibility fix you will need to add is the VirtualRegistry fix, and the command line for that fix can be “NT51” (meaning the registry keys relevant for OS version detection will emulate Windows XP). When you’re done, you can save the compatibility database to an SDB file. (Just looking at the list of preinstalled compatibility fixes makes you realize the power and potential of the AppCompat shims.)
One way or another, once we have the shim ready as an SDB file, all we need to do is install it on the target machine using the sdbinst command line utility:
After doing that, the client application launches successfully.