Take a callstack of different process using one dot net application RRS feed

  • Question

  • Hello,

    I have a requirement like follows,

    I have multiple processes (which created using dot net framework 4.7.1) which is running in a machine.i have logging framework also in place. On top of that, I need to dump all my process call stack into a file.
    for doing this what I have to do. I think I can create one dot net application(may be windows service) which will monitor my processes and that will capture all call stack and put it into a file. Is that possible?
    Can anyone suggest a way to achieve this?

    i can achieve this by adding extra logs/trace in my code.But that is not acceptable.This tracing tool should be separate from my other process or production code.

    its like profiling tool


    • Edited by La07K Friday, November 15, 2019 8:01 AM
    Friday, November 15, 2019 7:58 AM

All replies

  • You can use the built-in profiling tool of VS2017+ Enterprise edition to take a snapshot at particular line and do analysis later.

    Friday, November 15, 2019 9:29 AM
  • " On top of that, I need to dump all my process call stack into a file."


    Michael Taylor

    Friday, November 15, 2019 2:51 PM
  • Programmatically you can use:



    william xifaras

    Friday, November 15, 2019 6:03 PM
  • If I understand what you are asking then you need to inject a DLL into each of the other processes.

    Sam Hobbs

    Friday, November 15, 2019 7:11 PM
  • This i need to verify any slent exceptions aere occured or not?


    Monday, November 18, 2019 6:15 AM
  • I mean i can use this application for capturing call stack for any application which is created by dotnet framework.

    Suppose i have an application called App1 which is running in a machine.I need to take callstack for this app1 execution using a  separate application which is created using C#.Net


    • Edited by La07K Monday, November 18, 2019 6:20 AM
    Monday, November 18, 2019 6:17 AM
  • You cannot capture the exceptions of another process outside of a debugger.

    Every answer you get here is going to be related either to the current process's code, starting the process as a child (in which you still cannot get access to the exceptions, or creating a hook DLL that has to be run in the context of each process (which is a security issue unto itself).

    Again, why are you doing this? What purpose do you have for capturing exceptions from other apps? Are these your apps? Why can't they just log to a central location like the event viewer or something?

    Michael Taylor

    Monday, November 18, 2019 2:44 PM
  • Thanks Michael....It was my requirement to analyse the possiblitty and feasibilty of this application.Exception logginng just a on requirement.They need complete stack trace from which method to which method call is going.Method names and corresponding class names.

    Is that possible capturing callstack for a one process execution using another application?


    Tuesday, November 19, 2019 9:50 AM
  • Firstly that is only remotely possible with .NET apps or with apps that have PDBs installed. Without that information you're not getting anything other than function addresses.

    Secondly, exceptions are point in time so the only way to get this information is to be in the handler chain when the exception occurs. Exception handlers are per process (and often per thread) so you'd have to hook them all. That cannot be done without injecting a DLL into each process. Given that some apps are native apps and some are .NET this can get tricky. I guess an alternative is to generate a minidump which would capture the current app status but if an exception isn't occurring then you'd just get a dump of the process.

    Ultimately I think your solution is going to involve hooking into WER somehow. But this would only be for unhandled exceptions, which probably makes sense. Unfortunately I don't have any experience in this realm. Note that for your own apps you can certainly handle exceptions and log them but for processes you don't own I think WER is your only choice.

    Michael Taylor

    Tuesday, November 19, 2019 2:47 PM
  • Thanks Michael for your valuable inputs.


    Wednesday, November 20, 2019 4:29 AM
  • Hi La07K,

    Has your problem been solved? If so, please click "Mark as answer" to the appropriate answer, so that it will help other members to find the solution quickly if they face a similar issue.

    Best Regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Wednesday, November 20, 2019 8:07 AM
  • I think its possible.

    Please check the below url

    Already one tool is available in market


    Tuesday, November 26, 2019 10:23 AM
  • Reread the description of this product. As we've stated before the only app that can reach into other processes and access their error information is debuggers. That is what this product is, well a profiler at any rate but it is a similar (but simpler) concept. The "non-instrumented" version installs itselfs as a .NET Profiler which allows it to profile your code. Unfortunately this also means it'll slow things down. It's up to you if that is the route you want to go.

    Rereading your original post I still don't see an answer as to why you need to be able to dump the stack of your own processes from a separate process. Are you just trying to get more detailed exception information? If so then have you looked into using the standard Win32 crashdump API? This is technically how WERs gets its information but hooking into the API would allow you more finegrained control including what to grab. Technically you can use this API to grab your process at any point in time but it is most commonly used for crashes. 

    This doesn't meet the requirements of your original post in that it isn't going to work for processes you don't own nor is it a standalone process which is why I ask the question of whether you actually need this stuff. 

    Michael Taylor

    Tuesday, November 26, 2019 2:46 PM