UMDH : Can't capture the heap snapshots anymore RRS feed

  • Question

  • Hi,

    I'm trying to capture the snapshot of heap allocation stack-trace using umhd.exe from Windows Debugger tools. It worked fine couple of times in the beginning however whenever I run it now, I get the following message.

    C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86>umdh.exe -pn:notepad++.exe
    Warning: UMDH didn't find any allocations that have stacks collected.
    Warning: Traces could not be callected because the Stack Trace Database is full.

    Warning: Increase the size of the Stack Trace Database using GFLAGS.

    I tried to increase the Stack Database size using GFLAGS but it didn't work for me. Seems like I need to clear up some cache or something like that.

    Any idea ?

    Friday, February 22, 2013 1:16 PM

All replies

  • I am having this problem too.  I use UMDH often and never saw that message until today.  I'm only seeing it under Windows Server 2012.  Are you running on Windows 8 or Server 2012 when you get this message?
    Saturday, February 23, 2013 2:45 AM
  • I'm using Windows 8 (64-bit) and still not able to figure out why is this happening.
    Saturday, February 23, 2013 4:21 PM
  • I spent some time over the weekend in debugging umdh. Apparently, it seems that CreateQuertDebugBuffer call is failing in umdh::CreateStackTraceDatabase(). I couldn't figure out what exactly it does and/or does it create any local cache file, etc.

    I really need to get it working.

    Monday, February 25, 2013 1:42 PM
  • +1. I'm seeing this on Win2008R2 x64. Adjusting the stack trace db size doesn't resolve the issue. 

    Update: The windbg tools on the machine were from 2009. Installing the latest version resolved the UMDH issue. Now to find the leaks... :) 

    • Edited by matty256 Friday, March 1, 2013 4:32 AM
    • Proposed as answer by matty256 Friday, March 1, 2013 4:32 AM
    Thursday, February 28, 2013 11:44 PM
  • I'm still having this problem with what I believe is the latest version, 6.2.9200.16384.

    Matty256, I think your case might be different.  This issue seems to be specifically related to using UMDH through the WOW64 layer in Win8/2012.

    Here are two other places I have seen this (no answers yet):

    Friday, March 1, 2013 5:33 PM
  • <del>Mudassir, are you seeing this on a virtual machine?  I am seeing this problem on two virtual machines running on Hyper-V under Server 2012, but I'm not seeing the problem on two physical machines running Server 2012.  I wouldn't normally suspect that virtualization could cause a problem like this, but my 4 machines have very similar configurations, and it's mysterious to me why the two VMs see this problem, and the two physical machines don't. </del>That was a silly and wrong suggestion, I found a VM where it does work for me.

    Perhaps some third-party software or a Windows update?  I'm starting to install the apps I normally use for debugging to see if one of them seems to make a difference.

    • Edited by RobinsonWM Friday, March 1, 2013 11:18 PM
    Friday, March 1, 2013 9:58 PM
  • RobinsonWM : This is happening on my host Windows 8 machine, not on Virtual Machine. I tried this on Windows 7 VM using Windows 8 SDK and it worked over there.

    matty256 - I've also tired to reinstall Windows 8 SDK on my Windows 8 machine but it didn't fix the issue.

    I also think the problem is with the new version of UMDH.

    Sunday, March 3, 2013 2:35 AM
  • I see that both of my threads I've opened so far has been referenced here already, and sadly I can so far only admit failure...

    I have done some tests to verify that it isn't WinDbg or UMDH itself that is the issue; Just create a simple test program and compile it for a x64 target and you'll get the correct heap information provided.

    As soon as you build the target as a 32 bit x86 executable instead, WinDbg and UMDH looses all track of the heap information.

    I have read various sources discussing improvements to the Windows kernel with regards to the heap management, to make it more secure. This would be shared between both Windows 8 and Windows Server 2012.

    My guess is that they've updated WinDbg and UMDH in general for the new heap data, but somehow missed the case of WOW64...

    If you have a go at just setting the correct gflags and starting your 32-bit process (assuming of course it doesn't crash), does the memory consumption go up considerably? If so you're most likely already generating the necessary data (in our case, the idle 32 bit application goes from 40MB to 140MB RAM usage just by enabling the user mode stack trace DB and heap tagging), just that the Tools somehow does not know how to use the new format of the metadata.

    Thursday, March 7, 2013 4:03 PM
  • Yes, the memory consumption was increased drastically in the application that I was testing with stack trace db enabled. In my case, it went up from ~140MB to ~1.5 GB which seems quite strange.

    The application can only be compiled with x86, therefore I didn't check it for x64 version. However, I checked it with another simple x86 and x64 application and had the same results as mentioned by Patrik above.

    I'm not familiar with the new heap data changes in Windows 8. However, I was able to generate the stack data when I ran UMDH first time with my application. After that, I started getting the error message. I think there is some problem with new version of UMDH in windows 8, it seems creating the stack trace db in the memory, but failing to log it.

    Thursday, March 7, 2013 5:23 PM