Isolating my code for debug

Of course there is a lot of code running on the computer at any given time. How can I isolate the software that I need to test during a kernel debug session so that for example, I am not breaking on every single RtlEnterCriticalSection call for every other program? Or should I just go into memory and kill all other processes except those needed to run my software? Is there a trick to this? Thanks.

What do you mean by that? Do you want to be able to single-step your code? The kernel debugger allows that. Do you want to set a breakpoint on NT function? Set a breakpoint on the call in your code.

xxxxx@toddcullumresearch.com xxxxx@lists.osr.com wrote:

Of course there is a lot of code running on the computer at any given time. How can I isolate the software that I need to test during a kernel debug session so that for example, I am not breaking on every single RtlEnterCriticalSection call for every other program? Or should I just go into memory and kill all other processes except those needed to run my software? Is there a trick to this? Thanks.

Even if you got rid of user-mode processes, there’s still a lot of
kernel code calling RtlEnterCriticalSection. You’ll need to find
another way.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

One could make wrapper functions for APIs you want to debug break on, so then you set a breakpoint MyDriver!DebugRtlEnterCriticalSection instead of RtlEnterCriticalSection.

A thing I also sometimes do for debugging is make a little single thread trap using InterlockedIncrement, so I can activate a breakpoint in my code only for the first processor to hit the breakpoint, and other processors see the variable is non-zero and don’t break. You can also set a breakpoint, and manually disable it when the first processor hits it, but if I have a breakpoint I’m using a lot, it’s easier to use the single threaded breakpoint. It’s difficult to single step when multiple cores are trying to step through a function at the same time. My brain follows 1,2,3,4 much better than 1(5),2(5),1(3),3(5),1(8),2(3),4(5) when stepping.

Maybe I’ve always done it the hard way, but I don’t know of a windbg step command that only will break on the same core.

Jan

On 7/14/17, 3:11 PM, “xxxxx@lists.osr.com on behalf of xxxxx@toddcullumresearch.com xxxxx@lists.osr.com” wrote:

Of course there is a lot of code running on the computer at any given time. How can I isolate the software that I need to test during a kernel debug session so that for example, I am not breaking on every single RtlEnterCriticalSection call for every other program? Or should I just go into memory and kill all other processes except those needed to run my software? Is there a trick to this? Thanks.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Alex yes I must set a bp on a Kernel Nt function but it’s happening upon initial loading of the program before my entry point occurs. Using bu has gotten me pretty close because apparently it sets a deferred bp for a similar purpose. Jan I might be able to give that a go as well thanks.

If I just want to break on a particular driver calling a particular API, I
can sometimes get away with using an access breakpoint on the import table.
This is easiest if you already have symbols:

kd> x ntfs!*exallocatepoolwithtag
89a6e784 Ntfs!_imp__ExAllocatePoolWithTag =
kd> ba r4 89a6e784
kd> g
Breakpoint 0 hit
nt!ExAllocatePoolWithTag:
829c4006 8bff mov edi,edi
kd> k
# ChildEBP RetAddr
00 807d57f4 89a30d65 nt!ExAllocatePoolWithTag
01 807d5814 89affebf Ntfs!InitializeNewTable+0x97
02 807d5858 89b00a94 Ntfs!NtfsInitializeRestartTable+0x6d
03 807d5ad8 89b7bb68 Ntfs!NtfsCheckpointVolume+0xa22
04 807d5b2c 89b1c281 Ntfs!NtfsCheckpointAllVolumesWorker+0x64
05 807d5b8c 89b7bccc Ntfs!NtfsForEachVcb+0x167
06 807d5d04 8298be07 Ntfs!NtfsCheckpointAllVolumes+0xf2
07 807d5d54 82f000da nt!ExpWorkerThread+0x129
08 807d5d90 829a9555 nt!PspSystemThreadStartup+0x178
09 00000000 00000000 nt!KiThreadStartup+0x19

If you do not have symbols you just need to find the function you want in
the IAT:

kd> !dh ntfs

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES

52000 [80C] address [size] of Import Address Table Directory

kd> dps ntfs+52000 l80c/@$ptrsize

89a6e784 829c4006 nt!ExAllocatePoolWithTag


-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

One could make wrapper functions for APIs you want to debug break on, so
then you set a breakpoint MyDriver!DebugRtlEnterCriticalSection instead of
RtlEnterCriticalSection.

A thing I also sometimes do for debugging is make a little single thread
trap using InterlockedIncrement, so I can activate a breakpoint in my code
only for the first processor to hit the breakpoint, and other processors
see the variable is non-zero and don’t break. You can also set a breakpoint,
and manually disable it when the first processor hits it, but if I have a
breakpoint I’m using a lot, it’s easier to use the single threaded
breakpoint. It’s difficult to single step when multiple cores are trying to
step through a function at the same time. My brain follows 1,2,3,4 much
better than 1(5),2(5),1(3),3(5),1(8),2(3),4(5) when stepping.

Maybe I’ve always done it the hard way, but I don’t know of a windbg step
command that only will break on the same core.

Jan

On 7/14/17, 3:11 PM, “xxxxx@lists.osr.com on behalf of
xxxxx@toddcullumresearch.com xxxxx@lists.osr.com
xxxxx@lists.osr.com> wrote:

Of course there is a lot of code running on the computer at any given
time. How can I isolate the software that I need to test during a kernel
debug session so that for example, I am not breaking on every single
RtlEnterCriticalSection call for every other program? Or should I just go
into memory and kill all other processes except those needed to run my
software? Is there a trick to this? Thanks.


NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>

Scott, that was very helpful as I hadn’t yet touched mem access bps yet in this way on WinDbg. Thank you so much!

Are you debugging user mode or kernel mode?

Kernel mode. I needed to figure out an issue with how the program was loading into memory so it was mostly NtCreateSection and memory manager related stuff.