Understanding UMDH Warnings

Question

I am new to using UMDH, and I am having some trouble understanding how to proceed with some of the errors it is outputting. I follow the typical usage (from the MS site):

gflags -i OCES.exe +ust

In another terminal window:

OCES.exe

And then back in the original terminal window:

umdh -p:5712 -f:out1.txt

But I am getting the following warnings from UMDH

Warning:
Warning: UMDH didn't find any allocations that have stacks collected.
Warning: Use gflags to enable allocation stack collection.
Warning: Restart the application for the setting to be in effect.
Warning: A 32bit GFLAGS must be used. The command is:
Warning: gflags -i OCES.exe +ust
Warning:

When I make the second call to UMDH, I get the same error, and when I use UMDH to diff the two snapshots, I do not get any useful output (no stacks or backtraces). I have used UMDH on another computer and did not experience these same problems (the other computer is no longer available for my use).

The installation of UMDH is from the 32-bit version of "Debugging Tools for Windows" collection, I am running a 32-bit version of WinXP Professional, and my software is in C++ using Visual Studio 2008.

I have done a search on these warnings and have not found anything useful about them. Any help would be much appreciated.

It appears the executing gflags in the same terminal as the executable appears to not give the warnings (contrary to the example from MS, and what I experienced on my previous computer). But, I get the same warnings with our main app (not OCES.exe), which returns control to the terminal (OCES.exe does not; It locks the terminal). So I am "assuming" that the effects gflags might have limited scope. Is there a better way to approach the usage of gflags for an application that release control back to a terminal window? — Clifford Thompson, Oct 20 '10 at 18:01
`gflags` should affect the registry. You can check whether it worked using `gflags /i oces.exe` which dumps the current settings. Use `gflags` with no params and you should load the GUI version, you can check and set your EXE's flags this way too. — Steve Townsend, Oct 20 '10 at 18:10
@Steve. I will try this. If it does not work, it might be our main app rather than UMDH. It is a fairly large code base with a number of COTS products, so there might be something that gflags is not happy with. I am going to try some other leak tools like LeakDiag and DebugDiag. Thanks for all your help with getting a better understanding of UMDH, Steve. Much appreciated! — Clifford Thompson, Oct 20 '10 at 21:08

score 1 · Answer 1 · answered Mar 14 '11 at 13:16

Run gflags application and go to Image File tab. Enter your process name and press Tab. Now increase value in "Stack backtrace (Megs) to e.g. 64 or even 128. By default this value is 32Megs as far as I know and for multiple stack allocations this can be easily overrun.

Steve Townsend · Answer 2 · 2010-10-20T20:53:54.437

It's not clear from the description whether you did this, but you have to restart the process after setting the +ust flag for it.

The comparison will continue to fail until you get rid of the warnings on the snapshot runs.

EDIT:

This article indicates that if symbols are not set up properly for ntdll.dll, the tool will not work. Could you check this?

Problems That You Can Experience When You Use UMDH

The most common errors when you use UMDH occur because stack tracing is not enabled. Also, incorrect symbols for Ntdll.dll prevent UMDH from running. For the other symbols files, UMDH runs but the log file contains stack traces that do not have function names but instead have relative addresses inside modules. A distant third error is specifying a wrong PID.

Yes. The gflags call was before the call to OCES.exe. – Clifford Thompson Oct 20 '10 at 17:16 — Clifford Thompson, Oct 20 '10 at 17:16
@Clifford - is there anything else in `out1.txt`? – Steve Townsend Oct 20 '10 at 17:40 — Steve Townsend, Oct 20 '10 at 17:40

score 0 · Answer 3 · answered Oct 20 '10 at 18:24

@Steve - I moved the topic slightly from OCES.exe (our network engine) to our main app, but I am getting the same warnings (please see my follow above for the details of the main main app. Its that same code base as OCES.exe, it just adds other code). There is output in out1.txt like the following:

22 bytes + 1E at 151EA0 by BackTrace0
28 bytes + 18 at 151EE0 by BackTrace0
2D8 bytes + 18 at 151F20 by BackTrace0
314 bytes + 1C at 152210 by BackTrace0
314 bytes + 1C at 152540 by BackTrace0

This is slightly different than some of the output that I received on my previous computer:

C0 bytes + 18 at 154B88 by BackTraceB
    7C96EED2
    7C94B394
    7C918F21
    7C91F661
    7C91F225
    7C91EF58
    7C91ED13
    7C915BAA
    7C91D129

So I'm assuming that I am missing that stack trace information from out1.txt. I wonder if gflags has some limited scope on how it affects executables?

See my edit. btw - you can edit your own question with more data if you wish. — Steve Townsend, Oct 20 '10 at 20:52

Understanding UMDH Warnings

3 Answers3