View Full Version : synchronization issues

July 15th, 2013, 22:49
Wondered about this for some time. If I am single stepping through kernel mode, and I encounter a call to WaitForSingleObject, or the likes, like a Sleep function call, mutex, etc., how does my single-stepping affect the call?

With the processor running at millions of instructions per second, it's not an issue, but with me single stepping, I am wondering if I am setting myself up for a long wait, translating to thousands of single-steps. My understanding with a sync object is that the kernel suspends a thread till a required event is signaled, and that several threads may be waiting on the same event.

If I step through the sync object code, like WaitForSingeObject, and other threads are waiting, I could be there for a long time, stepping endlessly through code. If I jump over the call, I may be shunted back around to the call again, till the event is signaled. Does anyone know the proper way to handle such a timing event while single-stepping?

I am bothered by the fact that the call may be re-entrant somewhere along the line and that I'll miss an important detour leading to essential code if I step over it. I don't yet know enough about sync objects to know how they are employed. I have a decent idea but not good enough.

I have encountered situations many times in the kernel where I find myself stepping through a function that is unrelated to the thread I am tracing. For example, last night I was tracing a thread related to CreateFile, and calls to getfiletime and setfiletime after returning from the call lead me into ntfs.sys, which is what I wanted. However, I soon found myself in acpi.sys and drivers related to the USB system.

I may have taken a wrong turn but I suspect I could have been diverted by synchronizing calls. Those functions may be waiting for the same event as my thread is waiting for.

Alternately, I am simply walking a stack of drivers and have given up too easily.

July 17th, 2013, 14:58
I was thinking you might be able to make life a bit easier if you set some advanced 'bpx ... if tid == ...' breakpoints before stepping into code that might shunt you to another context. At least that way you can F5 the hell out of Dodge if you get trapped and should break back in your original thread context a few instructions from where you left it. Think of it as setting homing beacons or transport enhancers or whatever.

btw, I haven't had any luck with the underscore macro as described in the Sice manual, i.e.
bpx eip IF (tid == _tid)
instead get tid from 'thread' or '? tid'

You might even be able to tell when you've strayed into the wrong neighbourhood with these (as given in the Sice manual). IIRC the offsets are the kernel TEB and the esi/edi logic can be gleaned from disassembling SwapContext.

Watch a thread being deactivated:
bpx ntoskrnl!SwapContext IF (esi==0xFF8B4020)

Watch a thread being activated:
bpx ntoskrnl!SwapContext IF (edi==0xFF8B4020)

July 24th, 2013, 08:30
[Originally Posted by Kayaker;95065]I was thinking you might be able to make life a bit easier if you set some advanced 'bpx ... if tid == ...' breakpoints before stepping into code

Kayaker...sorry for delay in responding. Got caught up trying to upgrade an old motherboard to a newer Intel board. However, the existing system is XP and it did not occur to me that a new mobo wont run with an older XP installation. Got around it using a repair install but that wont work with the original install disk if the newer mobo is not listed on it. Ended up slipstreaming SP3 onto the original and that got me past a BSOD complaining about pci.sys.

That was the beginning of my troubles. The existing IExplorer was ver 6 and it whined about everything, refusing to allow me access to the activation screen. Finally upgraded it to IE 8 and everything became kosher. The old IE even shut down the Help and Support Centre along with other dependent goodies like System Information. It was integrated into Windows until Msoft was forced to remove it due to the competition act in the States.

Anyway, thanks for the tip. I'll get back to it in a few days now that I'm up and running again with my whiz-bang new mobo. Big difference between the ICH2 core and the ICH9 on an Intel board. I had a SATA optical drive that would not work on the ICH2 mobo and now it whirrs along like mad. Also, networking has improved drastically. I can now talk to my laptop easily via the onboard NIC and hopefully that translates to windbg over two machines.

Blabberer will be pleased.