0

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)

Pablx08
  • 1
  • 1

1 Answers1

2

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.

JonasH
  • 28,608
  • 2
  • 10
  • 23
  • Thanks for your answer. I think that the best option is to use memory dumps, but I have a problem generating it. I am editing my post to include this new issue. – Pablx08 Jul 21 '23 at 11:14
  • @Pablx08 you might want to checkout "ProcessExplorer", rightclicking a process should give you an option to save a minidump or full dump. Process explorer can also list managed threads and stack traces directly. But please do not add or change the actual question of an existing post. If you have a new, but related question, make a new post with a link back to the original one for context. – JonasH Jul 21 '23 at 11:33
  • Thanks @JonasH. It seems to be a good solution but I cannot do that because I need to do it programmatically. The application is in production on a Linux server... – Pablx08 Jul 21 '23 at 14:49