20

Background: I am working on a WinForm based .NET 4.0 desktop application that has few threads and timers and uses some GDI processing for user controls. During my development I usually peep into sysinternal's Process Explorer to make sure that there isn't anything unusual with my application such as count of GDI handles or user objects etc.

Problem: While using Process Explorer, I found that Threads tab for my application's property in Process Explorer shows a lots and lots of entries of "clr.dll!LogHelp_TerminateOnAssert+0x58f68". Is this normal? I think it is not because non of other .net application (that I had written in the past) shows the same entry in their properties in Process Explorer.

Whats is LogHelp_TerminateOnAssert()? (I believe it is a function in clr.dll)

Why is LogHelp_TerminateOnAssert() getting called so many times?

Any pointers will be very helpful.

Thanks in advance.

Pavel Anikhouski
  • 21,776
  • 12
  • 51
  • 66
silverspoon
  • 1,085
  • 1
  • 11
  • 22

2 Answers2

10

clr.dll!LogHelp_TerminateOnAssert+0x58f68

The large number (+58f68) indicates that the actual method in clr.dll is far away from LogHelp_TerminateOnAssert(). You should probably fix the symbols and try again in order to get the correct call stack. You can then find out what the real method is.

It's not LogHelp_TerminateOnAssert(), so it's useless to find out what LogHelp_TerminateOnAssert() does.

To fix the symbols: in Process Explorer, go to Options/Configure Symbols, then enter

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

where c:\symbols is the path where you want to store the downloaded files.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
1

You mention using threads - since each thread gets its own stack it could be that the default stack size is being exceeded at some point causing the exception which is then trapped by the .NET runtime. What kind of work are you doing in the threads (recursion, lots of stack variables, etc)?

I believe default thread stack size is set at 1MB - try setting the stack size to 4MB in the thread constructor and see if the error persists.

Anthill
  • 1,219
  • 10
  • 20