Application dont respond after attaching Windbg RRS feed

  • Question

  • Hi, 

    i am trying to find memory leaks in an application which is of large size roughly dll will be around 1000 , many components like Win 32 dlls, .net dlls, COM dll exits in a application. 

    i am using latest windbg tool, After application launched , i attached the windbg debugger and set the symbol path (Microsoft and application symbols ) and do a .reload 

    After the reload the application will not respond. (it will show running in the task manager) but if i press a button the application will not perform next action. 

    i don't understand why it is like that. 

    my idea is to verify the heap and other verify open handle etc.. when the application is running rather than collecting dumps and analyzing.

    any one have any thoughts why the behavior is this. 

    appreciate your response. thanks.

    Thursday, July 9, 2015 12:45 PM

All replies

  • The debugger will inject a thread into the debugged process and fire an int 3 interrupt in the thread.  There are some narrow cases wherein this can lead to a deadlock.  Try starting your process in the debugger instead. 

    You may also want to look at a debug port reader, such as DbgView, to see if your program are throwing exceptions.  If you are specifically worried about leaks, take a look at umdh -- it's an excellent memory leak investigation tool.

    Thursday, July 9, 2015 6:49 PM
  • Hi Hein, 

    Now i am using umdh to identify memory leaks. how ever, when i see difference between two logs file generated by umdh , i see the call stack is in lower levels (not in application level). i mean i don't see a call in the call from application. 

    below is the call stack.

    +   57729 (  57729 -      0)      8 allocs BackTrace8BD
    +       8 (      8 -      0) BackTrace8BD allocations

    System.Drawing.ni!???+00000000 : 5EFCD8D5
    System.Drawing.ni!???+00000000 : 5EFC8B83
    System.Drawing.ni!???+00000000 : 5EFC8AF1
    System.Drawing.ni!???+00000000 : 5EFC8A06
    mscorlib.ni!???+00000000 : 6101A6FD
    mscorlib.ni!???+00000000 : 6101A53C
    mscorlib.ni!???+00000000 : 6101A442
    mscorlib.ni!???+00000000 : 61015F00
    mscorlib.ni!???+00000000 : 61015CAF

    Does it mean there are memory leak in .net Framework ? 

    Thursday, July 16, 2015 5:26 PM
  • >>Does it mean there are memory leak in .net Framework ?<<

    Would think, not necessarily, because FAIK
    UMDH is not perfect to analyze native memory leaks in .NET applications

    With kind regards

    Thursday, July 16, 2015 8:56 PM
  • Vijay,

    I would not think there are leaks in the .Net framework and I would work from the assumption that there isn't, until proven otherwise beyond reasonable doubt.

    As Wayne pointed out, umdh are not able to parse out the call-tree of the .Net calls.  However, given the references to System.Drawing and gdiPlus, you can infer that there may be issues in your drawing code.  It looks like it is performing an asynchronous visual update. That update may be happening more often than designed, or it may require some corresponding housekeeping somewhere else.  Another possibility is if you use a .Net control and are missing some cleanup calls on the ABI for it.  It's hard to say what's going on without more information.

    Thursday, July 16, 2015 10:02 PM
  • Thanks for the reply. 

    As i said my application is a mix of C++ and .Net. 

    Can you suggest me good tool to identify memory leaks in managed code ? 

    i have collected data of private bytes and virtual bytes, i notice the graph between private bytes and virtual bytes dont match. virtual bytes are increasing wrt private bytes. any suggestion ? 

    Friday, July 17, 2015 5:39 PM
  • I don't know the best tools for memory usage analysis with managed code.

    Are you absolutely sure you are leaking and not just using a lot of memory?  Have you tried calling GC.collect() to see if that makes a difference on your memory consumption? 

    Private bytes vs. virtual bytes is somewhat orthogonal.  More virtual bytes just means you are increasing the allocated address space, which you would do regardless of how and where you are consuming the memory.

    Friday, July 17, 2015 10:05 PM