Home/ Questions/Q 5942505
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T16:15:45+00:00

This might be a duplicate, but I haven’t seen this exact question or a

  • 0

This might be a duplicate, but I haven’t seen this exact question or a similar one asked/answered with a date newer than the release of .Net 4.

I’m looking for a temporary hack that allows me to look through the call stack and get all calling objects (not methods, but the instances that hold the methods) in the stack. Ultimately I need their hashcodes.

Is this possible?

EDIT:

Whether it came across in my question or not, was really asking if there was a simple/built-in way to do this. Really, just a stop-gap fix until I can make breaking changes to other parts of the system. Thanks for the great answers. After seeing them, I think I’ll wait . . . 🙂

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What are you trying to achieve here?

    Have a look at a similar question I answered about a month ago: How to get current value of EIP in managed code?. You might get some inspiration from that. Or you might decide it is too ugly (+1 for the latter).

    If all you want to do is assemble ‘unique’ call paths within a program session, go right ahead: I’d be very sure to use an AOP weaver and thread local storage. It wouldn’t be too hard that way.

    Caveat 1: Hashes are not very useful for generic .NET objects

    A random object’s hashcode may vary with it’s location on the heap to begin with. For reference: on MONO, with the moving heap allocator disabled, Object::GetHash is this pretty blob of code (mono/metadata/monitor.c)

    #else
/*
 * Wang's address-based hash function:
 *   http://www.concentric.net/~Ttwang/tech/addrhash.htm
 */
    return (GPOINTER_TO_UINT (obj) >> MONO_OBJECT_ALIGNMENT_SHIFT) * 2654435761u;
#endif

    Of course, with the moving allocator things are slightly more complex to guarantee a constant hash over the lifetime of the object, but you get the point: each runtime will generate different hashes, and the amount of allocations done will alter the future default hash codes of the identical objects.

    Caveat 2: Your stack will contain alien frames

    Even if you got that part fixed by supplying proper deterministic hash functions, you will require each stackframe to be of ‘recgonizable’ type. This is probably not going to be the case. Certainly not if you use anything akin to LINQ, anonymous types, static constructors, delegates; all kinds of things could be interleaving stack frames with those of (anonymous) helper types, or even performance trampolines invented by the JIT compiler to optimize tail recursion, a large switch jump table or sharing code between multiple overloads.

    Takeaway: stack analysis is hard: you should definitely use the proper API if you are going to undertake it.

    Conclusion:

    By all means have a ball. But heed the advice

    1. your requirements are non-standard (underlined by the runtime library not supporting it); This is usually a sign that: you are solving a unique problem (but reconsider the tool chosen?) or you are solving it the wrong way
    2. You could perhaps get a lot more info by generating a flow graph with some handwritten simulation code instead of trying to hook into the CLR VM
    3. if you’re gonna do it, use the proper API (probably the profiler API since a sampling profiler will save exactly this: stack ‘fingerprints’ every so-many instructions)
    4. If you really must do it by instrumenting your code, consider using AOP
    • 0