views:

2131

answers:

4

I am writing a multi-threaded Windows application in Microsoft Visual C# 2008 Express Edition. Recently, the debugger has been acting strangely.

While I am Stepping Over lines of code using the F10, sometimes it will interpret my Step Over (F10) command just like a Continue command (F5) and then the program will resume running and the debugging session will be done.

Does anyone know why this happening? In what circumstances can the Step Over command result in the debugger stopping?

It's not a problem with the code being debugged: it doesn't just happen on particular lines of code. It happens on a random line that is different each time I run the debugger.

It's not a problem with my keyboard: the same thing happens when I just click Step Over in the Debug toolbar.

It may be a problem with the other threads in my program. Maybe one of them is randomly doing something that has a side effect of interrupting the debugger. Is that possible?

Thanks in advance!

+4  A: 

I've seen this a few times. It generally happens when there's a context switch to another thread. So you might be stepping through thread with ID 11, you hit F10, and there's a pre-emptive context switch so now you're running on thread ID 12 and so Visual Studio merrily allows the code to continue.

There are some good debugging tips here:

Tip: Break only when a specific thread calls a method: To set a per-thread breakpoint, you need to uniquely identify a particular thread that you have given a name with its Name property. You can set a conditional breakpoint for a thread by creating a conditional expression such as "ThreadToStopOn" == Thread.CurrentThread.Name .

You can manually change the name of a thread in the Watch window by watching variable "myThread" and entering a Name value for it in the value window. If you don't have a current thread variable to work with, you can use Thread.CurrentThread.Name to set the current thread's name. There is also a private integer variable in the Thread class, DONT_USE_InternalThread, this is unique to each thread. You can use the Threads window to get to the thread you want to stop on, and in the Watch window, enter Thread.CurrentThread.DONT_USE_InternalThread to see the value of it so you can create the right conditional breakpoint expression.

EDIT: There are also some good tips here. I found this by googling for 'visual studio prevent thread switch while debugging'.

Damian Powell
The express edition doesn't have a Threads window. The conditional break point on the thread name sounds interesting, though.
Don Kirkby
+1  A: 

I find using a logfile is very handy when dealing with multiple threads.

Debugging threads is like the Huysenberg principle - observe too closely and you'll change the outcome !

+1  A: 

You ought to take a look at this KB article and consider its matching hotfix.

Hans Passant
Thanks! I haven't had the opportunity to confirm that this hotfix works, but It seems like it should because they mention the exact same problem that I was having.
David Grayson
A: 

Try this http://support.microsoft.com/kb/957912. Worked for me.