Debugging threads in Visual Studio 2005

[Ken Allen]

I have been using Visual Studio 2005 for some time now, and generally it
works fine. Recently I have been adding some threading logic to one of
my applications to permit the user interface to be updated while some
other process (CPU or I/O bound) is executing.

Before I added the threading the code worked fine and I could set
breakpoints anywhere and they were hit very quickly.

After adding the threading, the code executes very quickly, even
producing an exception, as long as there are not breakpoints in the
threaded code. As soon as I set a breakpoint in the threaded code, it
can take 30-45 seconds for my breakpoint to be hit! Even when I do hit
the breakpoint, and debug command (Continute, Step Over or Step Into)
seems to abort the thread!

Am I missing something in the configuration of the IDE?

-ken

 

[Michael Nemtsev]

Hello Ken,

It could be everything, like race conditions, deadlock.
The problem seems to be in the code

KA> I have been using Visual Studio 2005 for some time now, and
KA> generally it works fine. Recently I have been adding some threading
KA> logic to one of my applications to permit the user interface to be
KA> updated while some other process (CPU or I/O bound) is executing.
KA>
KA> Before I added the threading the code worked fine and I could set
KA> breakpoints anywhere and they were hit very quickly.
KA>
KA> After adding the threading, the code executes very quickly, even
KA> producing an exception, as long as there are not breakpoints in the
KA> threaded code. As soon as I set a breakpoint in the threaded code,
KA> it can take 30-45 seconds for my breakpoint to be hit! Even when I
KA> do hit the breakpoint, and debug command (Continute, Step Over or
KA> Step Into) seems to abort the thread!
KA>
KA> Am I missing something in the configuration of the IDE?
KA>
KA> -ken
KA>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch

 

[Ken Allen]

The actual exception I was attempting to track down was in my code, but
the behaviour of the debugger when setting a breakpoint in anything
other than the main thread is not.

I found the exception problem and fixed it, and now the code runs
properly, but if I set a breakpoint in the thread code, when it is to be
hit there is a large delay (10-60 seconds) before the debugger is
invokded. Once the breakpoint is hit, the only thing I do is press F11,
F10 or F5 and the thread seems to terminate. When I hit the breakpoint
the thread is active, and if I do not set a breakpoint, the code work,
so this is something in the IDE.

-ken

 

[Jon Skeet [C# MVP]]

It could be everything, like race conditions, deadlock.
The problem seems to be in the code

None of that should give the symptoms shown IMO, and frankly if the
problem *is* in the code, wouldn't you expect to be able to at least
have a crack at it in the debugger? It sounds like it's either a
debugger bug, or something very odd going on.

 

[Reto Ravasio]

I have the exact same problem :-(

the location where the debugger freezes and then aborts the thread is moving
around while the program grows. it happens exactly once after restarting the
debug session and it happens always on a newly spawned thread. It doesn't
matter whether i single-step or run up to the breakpoint, it fails at the
same breakpoint.

retrying the exact same sequence after the failure works perfectly.
thanks to the new 'edit and continue' feature i don't have to restart the
debugger that much.

i think its a bug in the ide, the debugger or both

reto