Comments

• dhananjay_kr Member - All Emails Posts: 52

  April 2015

  When you press 'g' (Go) after the context is switched, the debugger breaks
  after some time when the context is switched back to the thread that you
  were actually debugging...
  
  On Fri, May 1, 2015 at 5:42 AM, wrote:
  
  > I'm debugging a file system minifilter in kernel mode, and stepping though
  > the code with F10 (p). Often, the step looks good (i.e., goes to the next
  > line), but the underlying context gets inconspicuously switched to another
  > thread. It's not readily apparent to me how I can get back to the original
  > thread without having to "bp \t". Is there any way to step-debug a single
  > thread with WinDbg in kernel mode without such context switching, which
  > effectively renders stepping unusable? Thanks!
  >
  > ---
  > WINDBG is sponsored by OSR
  >
  > OSR is hiring!! Info at http://www.osr.com/careers
  >
  > For our schedule of WDF, WDM, debugging and other seminars visit:
  > http://www.osr.com/seminars
  >
  > To unsubscribe, visit the List Server section of OSR Online at
  > http://www.osronline.com/page.cfm?name=ListServer
  >

  0 · Share on Facebook
• cristalink Member Posts: 2

  May 2015

  I just tried it, it doesn't seem to be the case. 'g' let it run until it hit a breakpoint set specifically on the thread I was stepping through. In other words, the debugger failed to "step" on that thread. The breakpoint was hit a way after the next step statement.

  0 · Share on Facebook
• dhananjay_kr Member - All Emails Posts: 52

  May 2015

  I am not sure why it's not working. Can you please try this:
  
  1. Place your breakpoint.
  2. When your breakpoint hits, disable all breakpoints.
  3. Start stepping through.
  4. When the context switches to different thread, press 'g'
  
  See if it breaks after some time...
  
  On Fri, May 1, 2015 at 10:17 AM, wrote:
  
  > I just tried it, it doesn't seem to be the case. 'g' let it run until it
  > hit a breakpoint set specifically on the thread I was stepping through. In
  > other words, the debugger failed to "step" on that thread. The breakpoint
  > was hit a way after the next step statement.
  >
  > ---
  > WINDBG is sponsored by OSR
  >
  > OSR is hiring!! Info at http://www.osr.com/careers
  >
  > For our schedule of WDF, WDM, debugging and other seminars visit:
  > http://www.osr.com/seminars
  >
  > To unsubscribe, visit the List Server section of OSR Online at
  > http://www.osronline.com/page.cfm?name=ListServer
  >

  0 · Share on Facebook
• OSR_Community_User Member Posts: 110,217

  May 2015

  <quote>
  I just tried it, it doesn't seem to be the case. 'g' let it run until it hit a breakpoint set specifically on the thread I was stepping through. In other words, the debugger failed to "step" on that thread. The breakpoint was hit a way after the next step statement.
  </quote>
  
  I've seen this happen if you have a breakpoint and a SECOND thread hits that breakpoint while you single step in the FIRST thread. I usually just disable the breakpoint (so I can ignore those other threads) and single step through the code, re-enabling the breakpoint when I'm done with that specific thread.
  
  Tony
  OSR

  0 · Share on Facebook
• cristalink-2 Member Posts: 79

  November 2019

  I am still experiencing this issue. Please let me clarify it.

  1. It's a file system minifilter. In IRP_MJ_CREATE precallback, I have the code that calls DbgBreakPoint() once the input filename matches a certain condition. I have breakpoints defined in WinDbg, but they were all disabled .
  2. Once DbgBreakPoint() is called and WinDbg breaks in, I check the current Locals to make sure the filename is what I expect. I also do ".thread" and note the current thread, which is "Thread A".
  3. I start stepping with F10 ("p"). The function is long and calls other functions, and I keep stepping, sometimes with F10, sometimes with F11. Everything looks OK.
  4. Eventually, at some point, I discover that I am in a completely different context. It is the correct line of code (the one I expect to be at after pressing F10), but it's a different thread (".thread" shows "Thread B"), and I am now in the callback that was called for a complete different filename (which wouldn't trigger DbgBreakPoint() at step 2).

  That is, while I was stepping Thread A with F10/F11, WinDbg inconspicuously switched the context so that I continued to step through the same function, but now in the context of Thread B!

  How can prevent WinDbg from doing this?

  0 · Share on Facebook
• Peter_Viscarola_(OSR) Administrator Posts: 8,996

  November 2019

  MY question is how can I prevent members of the forum from resurrecting threads that are long dead. Do you know?

  Like threads that were active 5 years ago...

  Despite having Posting Guidelines, a link to which appears on every single page of the forum, that asks people not to resurrect dead threads. They still do it.

  Peter

  Peter Viscarola
  OSR
  @OSRDrivers

  0 · Share on Facebook
• cristalink-2 Member Posts: 79

  November 2019

  I guess, locking old threads would do the job. But what's wrong with posting a follow-up in this particular case?

  0 · Share on Facebook
• Peter_Viscarola_(OSR) Administrator Posts: 8,996

  November 2019 edited November 2019

  What’s wrong is that it’s against a policy that’s documented on every single page of this site. Do you think this thread is special? Or do you think you’re special and don’t need to follow the rules? Or do you just want to argue with the mods, for no good reason, instead of ... you know... following the rules which we’ve established for the good of the community here on the site?

  

  And, when you read the Community Guidelines you'll see that is says:

  There are a number of other behaviors that are considered rules of "good conduct" for posting here on the forums. These include:
  1. Please do not revive "old" threads. Until we have the ability to block posts to "dead" (old, outdated) threads, we ask you to not reply to threads where the last post is more than a month old. If you have a comment/question/issue that's raised in a "dead" thread, start a new thread (you can post a link to the old thread if you want) and ask your question there.

  Peter

  Post edited by Peter_Viscarola_(OSR) on November 2019

  Peter Viscarola
  OSR
  @OSRDrivers

  0 · Share on Facebook