CODEWITHSUNDEEP
.netvisual-studiomultithreadingdebugging
vgru
vgru

Reputation: 51292

Suggestions for debugging a multithreaded app

I have problems with step-by-step debugging of a multithreaded .NET application in Visual Studio 2008.

With each stepped line, Visual Studio gets slower and slower (it takes more and more time to jump to the next line) and usually hangs after several lines (I get the "Visual Studio is busy" balloon tip), and I need to stop debugging.

I suspect the problem is due to the fact that application has several TCP/IP clients connected, which means that every time I make a breakpoint, their network buffer gets filled until I continue my application. Whenever I use F10 to step over to the next line of code, Visual Studio shortly awakens all other threads for them to handle the input data.

Does anyone have experience with such problems, and suggestions on how to avoid them?

Upvotes: 5

Views: 311

Answers (3)

sll
sll

Reputation: 62544

This is not an easy task at all, I believe you understand this. So very important to have a clear understanding of threading and synchronization mechanisms which are provided by .NET Framework. Only after doing this you can start designing a thread synchronisation and management.

I would suggest to define clear names for your threads and introduce extensive logging, log4net would be a good choice because provides you a thread safe and robust logging instruments.

Visual Studio tips:

See more here: Debugging Multithreaded Applications

EDIT: Added more tips

Try to identify which application logic states really useful to be debugged manually and use conditional breakpoints if it is possible so you can avoid extra breaks of debugger:

Upvotes: 7

Yoopergeek
Yoopergeek

Reputation: 5642

This suggestion may be a long shot, but here I go: Any chance the app you're trying to debug is a WinForms app, and you have a watch-window open?

In the past, before I stopped using Watch Windows almost entirely, I remember experiencing your slower-n-slower scenario. I could repeat it if my breakpoint was hit in the context of a non-UI thread, and the watch window's polling of values included UI-bound values, the debugger would be silently swallowing cross-thread exceptions, and it would just get slower and slower and slower until it was unusable.

Closing watch windows got rid of the delay entirely.

Upvotes: 1

Shamim Hafiz - MSFT
Shamim Hafiz - MSFT

Reputation: 22114

As acoolaum pointed out, it's better to use timed logs to view any exceptions or crash reports. Also, you could add conditional compilation to use alternate paths which won't cause any hangup. For example, when debugging functions that rely on getting information from TCP/IP, use a mock function that just returns the string without actually performing any TCP/IP communication.

There are libraries created just for doing this kind mocking. You may like to check out one of those.

Upvotes: 2

Related Questions