.NET Zone is brought to you in partnership with:

Sasha Goldshtein is a Senior Consultant for Sela Group, an Israeli company specializing in training, consulting and outsourcing to local and international customers.Sasha's work is divided across these three primary disciplines. He consults for clients on architecture, development, debugging and performance issues; he actively develops code using the latest bits of technology from Microsoft; and he conducts training classes on a variety of topics, from Windows Internals to .NET Performance. You can read more about Sasha's work and his latest ventures at his blog: http://blogs.microsoft.co.il/blogs/sasha. Sasha writes from Herzliya, Israel. Sasha is a DZone MVB and is not an employee of DZone and has posted 207 posts at DZone. You can read more from them at their website. View Full User Profile

Setting Up an Offline Production Debugging Environment

05.02.2012
| 2703 views |
  • submit to reddit

If you’re doing production debugging in a closed environment—closed-down servers with no Internet access, or if you work at an institution that doesn’t have unrestricted Internet access from developer machines, this post will help you set up an offline production debugging environment. Incidentally, this post will also help if you’re going to host SELA’s .NET Debugging or C++ Debugging courses, and want to make sure your workstations are ready for the numerous hands-on labs.

First and foremost, you are going to need all the tools you plan using for production debugging. At the very least, this includes:

  • Debugging Tools for Windows
    Note there are 32-bit and 64-bit versions, you need whatever your application is using. For several releases now, the installation package is only available through the WDK or the Windows SDK, but you can follow the instructions here to configure the SDK web installer to download only the Debugging Tools for Windows installation package.
  • CLR Profiler
    The v4.0 version works for CLR 2.0 applications, so that’s the one you need.
  • Sysinternals Suite
    If you’re really low on disk space, the least you need are Process Explorer, Process Monitor, and VMMap.
  • .NET disassembler – any of the following will do:
  • Application Verifier
    Note there are 32-bit and 64-bit versions.
  • Debugging extensions

Next, you’re going to need debugging symbols for your environment. This includes debugging symbols for your own code, but more importantly, symbols for Windows, the CLR, and the .NET Framework versions your application is using.

In an online environment, obtaining symbols is trivial through the Microsoft symbol server. In an offline environment, you need to jump through a few hoops to make sure you have all the symbols set up, so here goes.

Windows symbols are available for download as symbol packages for various OS versions. As always, you need to make sure you’re downloading symbols for the precise operating system version on which your application runs. If there are several platforms you’re using, you’ll need symbols for all of them.

If you installed any hotfixes or updates from Windows Update, you’ll need to download symbols for them manually. Use the symchk.exe utility that ships with the Debugging Tools for Windows to obtain manually symbols on an Internet-connected machine. Follow these instructions to generate a text file on the disconnected machine and use it on a connected machine to download symbols.

.NET Framework symbols are available online on the Reference Source Code Center. These packages contain source code (!) and symbol files for the .NET Framework assemblies: mscorlib.dll, System.dll, and others.

CLR symbols are not available online as part of the .NET Framework symbol packages. You won’t usually need them unless you’re exploring CLR internals or dealing with very specific problems that require inspecting unmanaged call stacks of managed threads. To obtain CLR symbols, you’ll have to use the same technique mentioned above with symchk.exe.

Key CLR binaries and SOS.DLL are required for properly debugging dump files on a different machine. If you have access to the original machine, you can simply copy mscorwks.dll/clr.dll, SOS.dll and mscordacwks.dll from the %windir%\Microsoft.NET\Framework* directory corresponding to your .NET version. If you don’t have access to the original machine, you’ll have to track down the installation package for the appropriate CLR version and retrieve these binaries from it—I’ll cover this in a future post.

After following these instructions, you should have a fully functional offline production debugging environment. Additions and comments are welcome!

I am posting short updates and links on Twitter as well as on this blog. You can follow me: @goldshtn
Published at DZone with permission of Sasha Goldshtein, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)