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.

Answer 1

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.

Answer 2

@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?