Meaning of .Net Finalizer blocking on \KernelObjects\LowMemoryCondition event RRS feed

  • Question

  • Hello,

    I've looked at several "high memory usage complaint" dumps lately of .Net applications and have noticed that Finalizer thread is blocked waiting on handles to two similar events in several of them.   One handle points to just an undefined (at least as far as I can tell from a application/user dump) event like this:

    0:027> !handle 3f0 f
    Handle 000003f0
      Type          Event
      Attributes    0
      GrantedAccess 0x1f0003:
      HandleCount   2
      PointerCount  4
      Name          <none>
      No object specific information available

    And the other is a KernelObjects event:

    0:027> !handle 3a8 f
    Handle 000003a8
      Type          Event
      Attributes    0x10
      GrantedAccess 0x100001:
      HandleCount   9
      PointerCount  20
      Name          \KernelObjects\LowMemoryCondition
      No object specific information available

    From the MSDN description of the LowMemoryCondition event, this looks like the Finalizer wants to be signaled whenever a low memory condition occurs.   If so, is this just a normal run-time condition for the Finalizer that means nothing in terms of any particular dump?  

    Also: without a kernel dump where I can see event handle details, I don't know of a way to find out the nature of the other event on which the Finalizer thread is waiting.  (All I've seen for that event in a user dump is just an 3-digit hex integer which is meaningless by itself).   Does anyone know what that event is likely to be or how to find out what it is when working only from a user-mode dump?  

    Is a WaitForMultipleObjects for these two events just the normal condition for a Finalizer thread which is idled between re-runs?


    • Edited by Bob Riddle Thursday, February 7, 2013 5:55 PM
    Thursday, February 7, 2013 5:54 PM

All replies

  • Well, I had the time to force a dump with a simple Winforms C# app and confirmed that this pattern seems to be the normal state.   Then to try for more information, I forced a complete memory kernel dump.  Even with the latter dump, I'm still a bit puzzled about exactly what that second Event handle represents.   I had thought that with a kernel dump, I might see more detail about the event.   But even in that dump and both with/without being in my test app's process context, the only additional info I could see is only that it's a "synchronization event" vs. the unqualified "Event" that shows up in the user mode/application dump).

    (In that kernel dump, no other threads from other processes are shown as associated with that synchronization event).

    So if anyone has any light to shed on this, please reply to this thread.

    (BTW:  the reason I care about this nuance is that we have been pushing our Dev groups to intially make at least a cursory attempt to look at dumps of their applications instead of instantly pushing their dumps to me or escalating them to Microsoft.    The issue is that DebugDiag, which we have been recommending to our developers for obtaining a quick initial look at dumps of ASP.Net apps, always depicts this apparently normal scenario as a "blocked Finalizer" situation.   Our developers then waste time trying to identify the causes of what amounts to a normal situation.   It would be good to be able to explain exactly what the situation represents and how to differentiate it from a truely blocked Finalizer.    Without knowing more about how to identify that "normal" second synchronization event from any other second waiting-upon-event, I cannot simply tell them to ignore a "blocked finalizer" warning any time they see the wait for the "Low memory" notification).

    Also:  If this is condition is as it now appears to me, it would be nice if the DebugDiag team could tweak their product to better characterize this scenario as "Finalizer is simply waiting for something to do" instead of alerting to it in the same way they alert to a true "blocked Finalizer" where the thread really is functionally blocked due to a situation worth further investigation.)

    • Edited by Bob Riddle Tuesday, February 19, 2013 2:52 PM
    Tuesday, February 19, 2013 2:46 PM