locked
Code for Profiler on x64 & .NET 4 for sampling threads

    Question

  • I have a profiler which just works fine with 32 bit. but just does not work in 64 bit. Has anyone been able to successfully get x64 and profiler api to work properly. I have seen other threads that DoStackSnapshot does not work for .NET 4. 

    I have tried various things including just using 

    StackWalk64 : in this case GetFunctionFromIP returns E_FAIL. so not usable

    I have also tried  RtlLookupFunctionEntry/RtlVirtualUnwind. Still no luck as DSS does not work and in combination with running GetFunctionFromIP , I have seen it blow up the stack and crash my profiler. 

    Has anyone got this to work ? Any ideas ?

    Sunday, October 28, 2012 6:42 AM

Answers

  • Some notes on using DoStackSnapshot...

    rajmny's solution of just buying a profiler is often the best one!  If you're not specifically in the business of creating and shipping world-class profilers, then it's typically best not to try to create your own.  Lots of pitfalls, and not lots of documentation.  If you're not planning to ship anything, but love to tinker and play around with low-level APIs in your spare time, then go ahead and have fun.  Just be prepared for some frustration along the way.  :-)

    That said, GetFunctionFromIP will normally return E_FAIL for any IP in a frame that is not a managed frame.  This can sometimes get confusing, as some frames you think might be managed actually are not.  Some methods in mscorlib may not actually contain IL in their implementation, and may instead be thunks that jump directly into clr.dll's native code.  In such a case, if you find an IP in that method, GetFunctionFromIP will return E_FAIL, since that IP belongs to the native clr.dll.

    It's also worth noting that there was a bug in .NET 4.0 (fixed in 4.5) which affected DoStackSnapshot on cross-thread walks on x64-only.  In that scenario, DoStackSnapshot would return CORPROF_E_STACKSNAPSHOT_UNSAFE if the target thread is in an OS system call (which is statistically the case a LOT, when you consider all the synchronization, waiting, and sleeping that typical threads do).  Generally, on x64, DoStackSnapshot has very little value anyway, since the stack is always walkable as per the Windows x64 calling conventions.  So using RtlLookupFunctionEntry, RtlVirtualUnwind, and GetFunctionFromIP is the recommended way to walk a stack on a sample on x64.

    Thanks,
    Dave

    Wednesday, November 21, 2012 5:53 PM
    Owner

All replies

  • How many api cannot work on 64bit machine?

    Did you install x64 version .net framework?

    Have a nice day.


    Ghost,
    Call me ghost for short, Thanks
    To get the better answer, it should be a better question.

    Monday, October 29, 2012 1:16 PM
  • OpenCover compiles to both 32 and 64 bit and is used for profiling processes running under each flavour, however I do not need to use the suggested APIs so have not encountered your issues.
    Monday, October 29, 2012 11:51 PM
  • but do u also support .net 4 ?
    Wednesday, October 31, 2012 7:05 AM
  • i look at what you do. it is ELT functionality. so you dont do sampling. so u ok.
    Wednesday, October 31, 2012 7:16 AM
  • does anyone from Microsoft even monitor this forum ?
    Wednesday, October 31, 2012 6:58 PM
  • Hi Rajmny,

    Welcome to the MSDN Forum.

    I am trying to involve some other one in this thread. Please wait it patiently, thank you.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, November 01, 2012 8:40 AM
    Moderator
  • It is ok. my boss wants me to drop this for  now. we bought a profiler component.
    Friday, November 02, 2012 4:18 AM
  • Some notes on using DoStackSnapshot...

    rajmny's solution of just buying a profiler is often the best one!  If you're not specifically in the business of creating and shipping world-class profilers, then it's typically best not to try to create your own.  Lots of pitfalls, and not lots of documentation.  If you're not planning to ship anything, but love to tinker and play around with low-level APIs in your spare time, then go ahead and have fun.  Just be prepared for some frustration along the way.  :-)

    That said, GetFunctionFromIP will normally return E_FAIL for any IP in a frame that is not a managed frame.  This can sometimes get confusing, as some frames you think might be managed actually are not.  Some methods in mscorlib may not actually contain IL in their implementation, and may instead be thunks that jump directly into clr.dll's native code.  In such a case, if you find an IP in that method, GetFunctionFromIP will return E_FAIL, since that IP belongs to the native clr.dll.

    It's also worth noting that there was a bug in .NET 4.0 (fixed in 4.5) which affected DoStackSnapshot on cross-thread walks on x64-only.  In that scenario, DoStackSnapshot would return CORPROF_E_STACKSNAPSHOT_UNSAFE if the target thread is in an OS system call (which is statistically the case a LOT, when you consider all the synchronization, waiting, and sleeping that typical threads do).  Generally, on x64, DoStackSnapshot has very little value anyway, since the stack is always walkable as per the Windows x64 calling conventions.  So using RtlLookupFunctionEntry, RtlVirtualUnwind, and GetFunctionFromIP is the recommended way to walk a stack on a sample on x64.

    Thanks,
    Dave

    Wednesday, November 21, 2012 5:53 PM
    Owner