views:

162

answers:

2

We want to only break in a certain thread. Any idea how to do that? I can't seem to find a way to break on that condition.

I should have been more specific in the text. As the title suggests, I would like to break on the context switch into the thread.

+1  A: 

You need to setup a breakpoint filter. Right click on the breakpoint and select the Filter option. It will present a dialog that allows you to filter the breakpoint to specific thread ids, thread names, process ids, process names or even machine names.

If I wanted a breakpoint to only function on thread with id 42 i would use the following filter expression.

ThreadId = 42
JaredPar
Yep, I know about those. I want a breakpoint set when a thread is started or woken up.
Tim
+1  A: 

I'd be surprised if there were a way to do this in a user-mode debugger.

Imagine: you set a breakpoint for when thread 42 gets switched in. The breakpoint hits. The debugger is activated. Now a different thread is activated, and thread 42 is no longer active!


I suggest you try Process Monitor from Sysinternals (now part of Microsoft). You can limit it to only capture thread and process events, producing something like the following:

20:43:51.9162409    lsass.exe   440 Thread Create       SUCCESS Thread ID: 5420
20:43:51.9166730    lsass.exe   440 Thread Create       SUCCESS Thread ID: 7916
20:43:53.2990544    svchost.exe 736 Thread Create       SUCCESS Thread ID: 5540
20:43:53.7664146    svchost.exe 736 Thread Create       SUCCESS Thread ID: 7384
20:43:53.7985662    svchost.exe 736 Thread Create       SUCCESS Thread ID: 1888
20:43:54.2444922    wmiprvse.exe    3144    Thread Create       SUCCESS Thread ID: 6300
20:43:54.2466447    svchost.exe 736 Thread Create       SUCCESS Thread ID: 5636
20:43:54.2480367    wmiprvse.exe    3144    Thread Create       SUCCESS Thread ID: 6624
20:43:54.2515443    svchost.exe 736 Thread Create       SUCCESS Thread ID: 7392
20:43:55.5332047    devenv.exe  4640    Thread Exit     SUCCESS Thread ID: 4696, User Time: 0.0000000, Kernel Time: 0.0000000
20:43:55.9179052    Explorer.EXE    3176    Process Create  C:\WINDOWS\system32\verclsid.exe    SUCCESS PID: 3356, Command line: /S /C {2559A1F4-21D7-11D4-BDAF-00C04F60B9F0} /I {000214E6-0000-0000-C000-000000000046} /X 0x401
20:43:55.9179079    verclsid.exe    3356    Process Start       SUCCESS Parent PID: 3176
20:43:55.9179101    verclsid.exe    3356    Thread Create       SUCCESS Thread ID: 7108
20:43:55.9354621    verclsid.exe    3356    Thread Create       SUCCESS Thread ID: 940
20:43:55.9521113    verclsid.exe    3356    Thread Create       SUCCESS Thread ID: 2704
20:43:56.5259637    verclsid.exe    3356    Thread Exit     SUCCESS Thread ID: 2704, User Time: 0.0000000, Kernel Time: 0.0000000

You can do all sorts of other filtering as well, which should allow you to keep the utility running until the problem occurs, even in production.

John Saunders
The user mode debugger runs in a different process so it sounds possible to me. The OS would have to expose some things to the debugger I wouldn't expect though.
Joshua
@Joshua: think it through: that's still a context switch. Maybe the OP isn't interested in "context switches", but rather changes in wait state.
John Saunders
We are trying to debug a nasty problem where a thread is started by a 3rd party library. We are not sure where in the process initialization this thread is started... I am not sure else how to diagnose this.
Tim
I did think it through. The break would be hit on switching to any thread of this process if it wasn't the thread on this process that was just preempted.
Joshua
Thanks John - we need the debugger to break when the thread starts execution. I am not exactly sure how the process monitor information is going to help. I think I am missing something. We are stepping through our code - we do not have the source to the third parties, but we want to figure out what is going on in the initialization. (If we can) We are of course looking at assembler in the debugger at this point
Tim