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

Home› WINDBG
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Stepping a thread

cristalinkcristalink Member Posts: 2
in WINDBG
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!
· Share on Facebook

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
    >
    · Share on Facebook
  • 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.
    · Share on Facebook
  • 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
    >
    · Share on Facebook
  • 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
    · Share on Facebook
  • 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?

    · Share on Facebook
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,893

    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

    · Share on Facebook
  • 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?

    · Share on Facebook
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,893
    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

    Peter Viscarola
    OSR
    @OSRDrivers

    · Share on Facebook
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!

Sign In Register
Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA

Categories