Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Stepping a thread

cristalinkcristalink Member Posts: 2
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!

Comments

  • dhananjay_krdhananjay_kr Member - All Emails Posts: 52
    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
    >
  • cristalinkcristalink Member Posts: 2
    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.
  • dhananjay_krdhananjay_kr Member - All Emails Posts: 52
    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
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    <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
  • cristalink-2cristalink-2 Member Posts: 79

    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?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,467

    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

  • cristalink-2cristalink-2 Member Posts: 79

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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,467
    edited November 4

    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

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE