Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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 |
Comments
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
>
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
>
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
I am still experiencing this issue. Please let me clarify it.
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?
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
I guess, locking old threads would do the job. But what's wrong with posting a follow-up in this particular case?
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:
Peter
Peter Viscarola
OSR
@OSRDrivers