How to log Parallel Stack info in a C# application in production

Is there any way to log or print the information of Visual Studio parallel stack window?

I have a c# multithreading application running in production that is experiencing an issue without leaving any clue. It seems to be a deadlock of something like that but I cannot replicate it in a development environment.

So I think it would be very helpful if I can log to a file the status of the app (the running threads and their call stack) when I detect programmatically that the issue is happening.

Thanks in advance

Edit: Thanks to the answers and after investigating I have found that the best option is to generate a memory dump and load it in Visual Studio. However, I have a new problem... I am using createdump for doing that and it works on a .Net process, but the thing is that the process we have in production is a java process that uses a .Net library with JNI, so createdump is not working for that process. Any ideas about how to handle that?

The error I am receiving is: open(/proc/69588/mem) FAILED 13 (Permission denied)

If the issue is a deadlock you should be able to take a memory dump. You should then be able to open this in Visual studio and investigate the program state. There are also portable debuggers, like dnSpy that could be used to attach to a running program and investigate the state.

Logging of callstacks is likely not good idea, since it will be slow you cannot capture a snapshot of any specific moment in time, since at least one thread need to run to do the capturing. If you insist you could look at get the stacktraces for all threads in c#.

But I would suggest using the general approach when debugging difficult issues. Find some way to reproduce the issue, so you have some way to know that you have fixed it. This might require changes to your testing environment to better match production.

Review the code, if it is a deadlock it has to do with locking. You should (ideally) only hold locks for a very short time, and you should be able to see exactly what code will run while holding the lock. Any code that could block while holding the lock is suspect, and anything running "unknown" code, like an event handler, could potentially block.

Improve the logging so you have more insight into what the system is doing. Use multiple logging levels and modules so you can narrow down the problem without being overwhelmed by logging messages.