A note about using UMDH: You can trace
both Microsoft and non-Microsoft related
processes and services by running UMDH
commands; however, to actually capture the
component name involved in the leak, you’ll
need the corresponding symbol file for that
component. Some vendors don’t make their
symbol files public; if you don’t have access
to the symbol file, the information in the
UMDH output file will be limited to only the
component’s load address and exclude the
component name and function being executed.
So, to get any meaningful output from
UMDH, you should specify
at least the Microsoft symbol
path, as explained earlier.
Interpreting UMDH
Output
When you open the output
file—comparefiles.txt in Figure
1—at the top you’ll see
the first thread of execution
(thread for short), two lines
followed by a succession
of lines grouped together.
Threads represent a running
task inside a process; they’re
components and functions
that have memory allocated.
Every process must have at
least one thread to be able
to load and run. The top two
lines are the thread’s summary
information, and the group of lines under
the summary information represents each
thread entry in that process. Let’s look more
closely at the output and what it means.
The first two lines of the thread stack
show comparative memory-usage information
from the two snapshots. The first hexadecimal
number, +113faf000, represents the
delta change in memory consumption from
the first snapshot to the second. So in our
example, you can see a change of more than
4.6GB of memory (113faf000-0 = 4.6GB). To
see the delta value, you can convert the hex
value to decimal by using the Windows calculator’s
Scientific view (you can access the
calculator either through the Start menu or
by running calc.exe).
The next number, 81df8, represents the
number of actual allocations that occurred
to consume the memory. 81df8 hex represents
531,960 allocations. This high number
of allocations is normal, considering this
thread is responsible for more than 4GB of
memory. The next part, BackTrace8117, is
the internal ID with which the system has
tagged this thread.
The thread at the top of the UMDH output
is the thread that consumed the greatest
amount of memory, so that’s where you’ll
start investigating the memory-leak problem.
Each thread in the output file consists
of the component’s load address (e.g., in
the first entry, 77EDCA76), the component
filename (or DLL name—ntdll in the first
entry), and just after the ! sign, the function
within the DLL that was executed (e.g.,
!$$VProc_ImageExportDirectory).
You can use the UMDH output to start
your troubleshooting investigation by
reviewing the components in the output file
and, if necessary, updating them to their latest
versions. If the components involved in
the process are up-to-date and the leak still
occurs, your next step is to call tech support
or research the problem further.
Using UMDH Information
You can further narrow down and possibly
solve the problem by researching it online.
For example, I searched on information
from the sample UMDH snapshots—the
string “repdrvfs wmi leak,” including “wmi”
because the leak occurred in a Windows
Management Instrumentation (WMI) process
and “repdrvfs” because that component
name was high on the thread stack (i.e.,
the thread that was consuming the most
memory) and repeated several times (indicating
that the repdrvfs DLL was involved
in the consumption of memory). My search
found a TechNet article that provided the fix
for the problem, at support.microsoft.com/kb/838884. Thus, when you select components
to search, you’ll probably be most successful
searching those that are both high on
the thread stack and repeated.
Of course, you won’t solve all leaky-application
problems by using UMDH. However,
using UMDH for troubleshooting leaky
processes will provide key information that
can significantly reduce
the time needed to resolve
a technical support issue.
Check out the Microsoft
Advanced Windows Debugging
and Troubleshooting
blog (blogs.msdn.com/ntdebugging) for further guidance
in identifying and resolving
Windows technical issues.