Tracking Unusable Virtual Memory in VMMap

Tuesday, July 22, 2014

VMMap is a great Sysinternals tool that can visualize the virtual memory of a specific process and help understand what memory is being used for. It has specific reports for thread stacks, images, Win32 heaps, and GC heaps. Occasionally, VMMap will report unusable virtual memory, which is not the same as free memory. Here's an example of a VMMap report for a 32-bit process (which has a total of 2GB virtual memory): Where is this "unusable" memory coming from, and why can't it be used? The Windows virtual memory manager has a 64KB allocation granularity. When you allocate memory directly...
no comments

Announcing Tracer: A Generic Way to Track Resource Usage and Leaks

Tuesday, September 10, 2013

Tracer is a WinDbg extension I wrote last month to diagnose a resource leak that is not covered by well-known facilities like !htrace or UMDH. Tracking any resource leak starts with understanding where you are acquiring the resource and neglecting to release it – and with Tracer, you can do this for any kind of resource. Download Tracer and review its source code. The basic process of hunting for resource leaks is quite simple. For example, consider what UMDH does on your behalf. UMDH enables support in the operating system (specifically, in the Heap Manager...
no comments

Obscure WinDbg Commands, Part 4

Monday, August 26, 2013

In this final installment, we will review some miscellaneous commands that can make your life a bit easier. First, the .wtitle command. This command changes the title of the WinDbg window. It’s simple, sure, but makes it that much easier to work when you have multiple WinDbg windows open. Another command that helps with command discovery is .cmdtree. This command takes a specially-formatted text file and displays a tree-like menu that will execute these commands for you (yes, somewhat akin to the .dml_start command which we have seen previously). For example, given my command...
one comment

Obscure WinDbg Commands, Part 3

Monday, August 19, 2013

In today’s installment, we’ll take a look at two commands that make it easier to trace through program execution. The first command is wt, which traces through all the function calls performed in a certain code path and formats nice statistics illustrating what happened during that function’s execution. wt has a bunch of options that I won’t be showing here, but the general idea is that you let it trace through a lot of unfamiliar code and display statistics on what was going on in that code. For example, here I used a switch to filter out...
one comment

Obscure WinDbg Commands, Part 2

Thursday, August 15, 2013

In today’s post, we’ll take a look at some of the options available to us when using DML (Debugger Markup Language). DML is a very simple markup language that helps discover and execute new commands based on the output of existing commands. Many WinDbg commands (and extension commands as well) have support for DML. For example, here’s the lm D command, which displays DML output: In the command output above, when I clicked the “SillyThreadPool” link, the debugger executed another command for me, lmDvmSillyThreadPool, which displays module information. Again, there’s a bug of links that help...
one comment

Obscure WinDbg Commands, Part 1

Monday, August 12, 2013

I’m starting a short post series today covering some obscure WinDbg commands. Some of these are fairly useful, others are mostly good for extracting “wows” from your coworkers. Still, there’s a lot of ground to cover. Today’s two commands deal with inspecting thread call stacks. Real-world processes might have hundreds of threads in them, and figuring out who’s who can be pretty time-consuming. This is especially true if you are using the thread pool (.NET, Win32, or even your own), which often means you have dozens of thread pool threads waiting idly for work. The !uniqstack command...
no comments

Setting Up Symbols for Offline Environments

Thursday, August 8, 2013

Yawn. That was my first reaction too, but turns out many developers around the world (including me in the not-so-distant past) work in a disconnected environment with no access to the Microsoft public symbol server or a symbol proxy. This post is for you. Microsoft offers a set of symbol packages for each major Windows version and service pack. If your system administrator does not install updates, ever, this is good enough for you. You can find the symbol packages here. If you are getting sporadic updates, chances are that a large number of Windows binaries have been touched by these...
no comments

Searching and Displaying C++ Heap Objects in WinDbg

Monday, August 5, 2013

This is something I am pretty excited to tell you about. But first, some motivation. In managed applications, there’s a huge number of tools and ways to inspect the managed heap contents. You can use a memory profiler to see references between objects and inspect individual objects. You can use WinDbg with the SOS extension to dump all objects of a particular type and execute additional scripts and commands for each object. You can even write C# code that uses the ClrMd library to parse heap contents and write your own diagnostic tools. C++ has nothing of...
2 comments

Introduction to Performance Measurement Session

Wednesday, July 3, 2013

I delivered a short two-hour session today introducing performance measurement tools. We covered performance counters – including a demo of custom performance counters, the Visual Studio profiler (sampling, instrumentation, allocations, and concurrency), and finally capturing ETW information using PerfView. Introduction to .NET Performance Measurement from Sasha Goldshtein The slides and demos are available here. In the Allocations folder you’ll find an app that allocates memory rapidly because it uses string concatenation instead of StringBuilder. In the Leak folder you’ll find a classic memory leak. In the Concurrency folder you’ll find a naïve parallelization attempt...
no comments

Automatically Obtaining Source and Line Number from Symbol Name and Offset

Tuesday, June 25, 2013

Once upon a time, unmanaged code developers had to work very hard to correlate code offsets back to source file names and line numbers. One approach involved generating .cod files (assembly listings) for each module, and then painstakingly comparing the instruction offsets with the contents of the .cod file. For example, if you received a faulting stack trace from a client machine that had the frame BatteryMeter!TemperatureAndBatteryUpdaterThread+0xd0, you could go back to the .cod file for BatteryMeter.exe, look up the code listing for TemperatureAndBatteryUpdaterThread, and then look for the source line located at (or near) offset 0xd0. ...
one comment