0

I am developing a .Net profiler.. I use ILRewriting for this..

I need to trace the managed thread creations and destroys.

Need to know the threading related function that will be called at the beginning of the thread and during the end of the thread , i can inject my code to it and record whenever the event happens.

Any ideas about the default function that will be called at the time of thread creation and ends..??

OR else is there any other way to capture the managed thread creation and destroying events??

I know that we can trace by setting the threading event mask.. but i need to capture particular managed threads not all the threads..

valiano
  • 16,433
  • 7
  • 64
  • 79
Sel_va
  • 588
  • 5
  • 25
  • 2
    You don't use IL rewriting to write a profiler. You use the CLR's built-in support for profiling. ICorProfilerCallback::ThreadCreated() and ThreadDestroyed tells you what you need. – Hans Passant Oct 31 '14 at 11:49
  • That's ok @HansPassant.. But the main thread (which starts for page load) is not getting destroyed even after the page load is completed ,(i.e) even after the `unloadrecursive` is called .. I dont know what is the problem with it. – Sel_va Oct 31 '14 at 12:11
  • One more thing.. As far as I read I came to know that the `ThreadID` comes in `ThreadCreated` function in the profiler dll is a ManagedThreadID .. But for the same thread if I get in the C# code the ManagedThreadID is some other number eg. 10 or 11 . using `CurrentThread.ManagedThreadID` . So here which is the managedthread id.. ?? I am confused totally.. – Sel_va Oct 31 '14 at 12:15

1 Answers1

2

As Hans pointed out, the CLR notifies the profiler of thread creation/destruction using ThreadCreated and ThreadDestroyed callbacks. Note: If the runtime shuts down before the thread terminates, then you won't get the ThreadDestroyed callback ... but I think the more likely reason you don't get the ThreadDestroyed callback is that IIS (I assume by 'page load' you are referring to asp .NET pages) decided to keep the thread around for future requests as an optimization, it may decide to terminate it later if it thinks it has enough other threads.

Also, regarding your second comment on the question, there is no relation between ThreadID and ManagedThreadID. I believe the ThreadID is a reference to an internal data structure (treat it as an opaque value, don't try to interpret it) and the ManagedThreadID appears to be a simple number sequentially allocated as threads first enter managed code. If you want identify which ThreadID corresponds with which managed thread, I can think of 3 options:

  • Check the thread name using the ThreadNameChanged callback (Note: If the thread name is set before the thread starts, then this will be raised before the ThreadCreated callback)
  • Check the OS thread id using the ThreadAssignedToOSThread callback
  • Have the profiled code call into the profiler to provide it with context (either using pinvoke or by calling a method that is instrumented for this purpose)
valiano
  • 16,433
  • 7
  • 64
  • 79
Brian Reichle
  • 2,798
  • 2
  • 30
  • 34