What is LogHelp_TerminateOnAssert?

Question

There is a similar question from a decade ago, but there was no good answer - hopefully things have changed since then.

I have a fairly multithreaded Winforms app based on .NET 4.72. I am looking at it with Process Explorer Threads view and it has a lot of clr.dll!LogHelp_TerminateOnAssert+0x6835 type calls. I've setup the Symbols path but it didn't really clear anything up for me.

I took a dump of the application and ran it through DebugDiag and WinDbg and didn't see anything suspicious that stood out.

So my questions:

• Should I be concerned with the large number of LogHelp_TerminateOnAssert calls?
• Is the application leaking memory?
• Does it have an excessive number of exceptions that don't filter down when I am running the app in Visual Studio?

The only entry from my code here is !get_FrameReceived and the stack for that thread is as follows:

The stack for the thread with the most cycles is like this:

Answer 1

on release build all these asserts are compiled into a simple ret something similar to

ifdef ( debug ) { function body here } elseif { ret } endif

so the symbols with such great offset are bogus

so you may need to load the actual symbols for that address for a sensible callstack

you can see the size of function in clr 4.0.30319 clr.dll is just 1 byte

0:000> x /v /t clr!LogHelp_TerminateOnAssert
pub func   100115a0             0 <NoType> clr!LogHelp_TerminateOnAssert (<no parameter info>)
0:000> .fnent clr!LogHelp_TerminateOnAssert
Debugger function entry 01bad5e0 for:
(100115a0)   clr!RtlUnwindCallback   |  (100115a1)   clr!memset
Exact matches:
    clr!RtlUnwindCallback (void)
    clr!_TlgDefineProvider_annotation__Tlgg_hClrProviderProv (void)

OffStart:  000115a0
ProcSize:  0x1
Prologue:  0x0
Params:    0n0 (0x0 bytes)
Locals:    0n0 (0x0 bytes)
Registers: 0n0
0:000> u clr!LogHelp_TerminateOnAssert l1
clr!RtlUnwindCallback:
100115a0 c3              ret

Answer 2

Large offsets

clr.dll!LogHelp_TerminateOnAssert+0x6835

means that the actual execution in that method is 0x6835 = 26661 bytes away from its beginning. It's unlikely that a method is that big. (As @blabb points out, it's a 1 byte method).

Usually you see that when you have not set up the symbols correctly (like in the linked original question), but you have that fixed.

Chances are that Microsoft has only release the public symbols of clr.dll and not the private ones. In that case, you'll only see the last known public method.

Start address

Please note that the column is named "Start address". Process Explorer will show the first entry on the stack.

So this is where everything starts. You seem to be concerned that this is where everything ends.

Note: some known internal methods like RtlUserThreadStart and BaseThreadInitThunk will be skipped when displaying the start address. Otherwise they'd probably all look the same.

What the thread is really doing is on the top of the list, i.e. ZwRemoveIoCompletion, so it seems to do some IO operation.

Your questions

Should I be concerned with the large number of LogHelp_TerminateOnAssert calls?

No. These are just the starting point for something good. The GetQueuedCompletionStatus() looks like there's some IO going on and .NET uses IO Completion Ports (IOCP) for you.

Is the application leaking memory?

You don't tell that from a look at call stacks. You tell that by looking at the memory over time.

If you have too much network IO going on and the network can't keep up with it, .NET may have more and more items in the queue, so it may look like a memory leak.

Does it have an excessive number of exceptions that don't filter down when I am running the app in Visual Studio?

You would also not tell that from the call stack. You would attach a debugger (e.g. WinDbg) and check for exceptions (like sxe clr), if you don't trust Visual Studio.