>> I don’t think EIP of the miniport driver will
The problem is, if he wants to have backtrace information following the
whole call hierarchy, then he does needs OS symbols and his driver symbols
at least to make an
accurate backtrace, or else he will fail . For first level only EIP is
enough. He needs FPO data uploaded into his driver for a good stack trace.
> ZwGetThreadContext
Nope , Im not reffering to it. If you think, this API wont help you anyway.
Its used to fetch user mode execution register set. You need the thread
register set exactly as its in the moment of a execution context switch.
There are no APIs at all to give you this IIRC.
> Would you be able to share this with us
Not completly, but the key is : thread state tracking , IPIs and barrier
waits . Note that
my technique is very good for patching, but not for stack backtracing. You
dont only
need to ensure that no threads running on other CPUs are not executing the
code you intend
to modify at run time, but to ensure that no thread at all, even if is
currrntly not running,
was not preempted or yeld execution while executing the code range which
needs to be patched.
Also, you may want to read this, I found it helpfull while I designed my
final algorithms(my code is a bit more than a patcher)
http://www.cs.wisc.edu/~tamches/tamches.html
Regards, Dan
----- Original Message -----
From: “Prasad Dabak”
To: “NT Developers Interest List”
Sent: Tuesday, July 30, 2002 3:52 PM
Subject: [ntdev] Re: EIP of last running process in timer interrupt
> Hello,
>
> Yes, EIP will be on interrupted thread’s stack,
> however, I don’t think EIP of the miniport driver will
> be immediately avaiable. There could be multiple trap
> frames at that point.
>
> >You can access the
> > context information in
> > other ways
>
> Are you referring to ZwGetThreadContext etc. This
> anyway won’t be available at raised IRQL. OR you are
> talking about some other low level functions?
>
> About SMP system, I forgot to mention one point. I
> used KeSetTargetProcessorDpc and KeSetInsertQueueDpc
> for each processor and the DPC routine used to raise
> IRQL to dispatch level and then wait in a loop till
> the code patching is done.
>
> > There is at least one, which works preet well,
> > altough is a ugly hack
>
> Would you be able to share this with us.
>
> Thanks.
> -Prasad
>
>
> — Dan Partelly wrote:
> > >> AFAIK, it is not possible to get the exact EIP.
> >
> > In his scenario , he only needs the EIP of the
> > interrupted thread. That will
> > be on current ring0 thread’s stack ALWAYS.
> > Guaranteed.
> >
> > >> and walking their stack to figure out if some
> > thread is executing
> >
> > Is not necessarely to backtrace a stack in order to
> > get last executed EIP
> > before the thread was executed. You can access the
> > context information in
> > other ways. In fact walking back the stack is a
> > mistake in such a case, and
> > can lead to catastrophic results.
> >
> > Raising IRQL to stop thread dispatching wont gain
> > you nothing in a SMP
> > machine, because
> > you only guarantee that the current executing thread
> > on CURRENT processor
> > wont be preempted. You must use IPIs to freeze
> > execution of all other
> > processors .
> >
> > >> fixed method to find this out. It goofs up for
> > some of threads.
> >
> > There is at least one, which works preet well,
> > altough is a ugly hack , but
> > memory patching is anyway a ugly hack 
> >
> >
> >
> > ----- Original Message -----
> > From: “Prasad Dabak”
> > To: “NT Developers Interest List”
> >
> > Sent: Tuesday, July 30, 2002 7:44 AM
> > Subject: [ntdev] Re: EIP of last running process in
> > timer interrupt
> >
> >
> > > Hello,
> > >
> > > AFAIK, it is not possible to get the exact EIP. In
> > the
> > > past, I have tried to figure this out for doing
> > SMP
> > > safe code patching. For doing SMP safe code
> > patching,
> > > I stopped thread scheduling by raising IRQL. I was
> > > enumerating all the threads in the system and
> > walking
> > > their stack to figure out if some thread is
> > executing
> > > on the region of code, which I am patching.
> > However, I
> > > found that, there is no fixed method to find this
> > out.
> > > It goofs up for some of threads. Even softice
> > could
> > > not properly walk the stack for these threads
> > > properly. I beleive, that, this happens, because
> > the
> > > low level functions don’t generate valid stack
> > frame
> > > for code optimization/inline assemblies.
> > >
> > > Finally I had to resolve to a dirty way, wherein I
> > > walk the stack of threads treating them as array
> > of
> > > DWORDs and then matching it with the address
> > region,
> > > which I had to patch. Although this method works,
> > this
> > > may prevent me to patch the code, even if it is
> > safe
> > > to patch (as it can find some DWORD on the stack
> > which
> > > is not actually an EIP but some other data).
> > >
> > > Thanks.
> > > -Prasad
> > >
> > >
> > > — Dan Partelly wrote:
> > > > Check intel manuals. The layout of a the
> > hardware
> > > > part of a trap frame
> > > > depends by whatever
> > > > the intererupt was a fault, abort or trap, some
> > > > privilege level rules. etc.
> > > >
> > > > Just read Intel manauls.
> > > >
> > > > ----- Original Message -----
> > > > From:
> > > > To: “NT Developers Interest List”
> > > >
> > > > Sent: Monday, July 29, 2002 11:22 PM
> > > > Subject: [ntdev] Re: EIP of last running process
> > in
> > > > timer interrupt
> > > >
> > > >
> > > > > Is there a fixed stack push order when the ISR
> > is
> > > > vectored…??
> > > > > Would anyone happen to know of this ??
> > > > >
> > > > >
> > > > > >>IIRC , you wont be able to connect to timer
> > IRQ,
> > > > so youll have to hook
> > > > > >>directly the IDT me thinks. timer interrupts
> > are
> > > > asynchronus events,
> > > > > they
> > > > > >>can occur in any thread at any time. To get
> > the
> > > > info you need , its
> > > > > >>enough
> > > > > >>to get the current interrupt thread’s EIP
> > and
> > > > match it against your
> > > > > >>module
> > > > > >>code range, to see if it was the NIC driver
> > code
> > > > which got interrupted
> > > > > >>somewhere. if you hook the IDT directly
> > youll
> > > > have all the info you need
> > > > > >>pushed by CPU on stack , including, but not
> > > > limited to interrupted
> > > > > thread
> > > > > >>EIP.
> > > > >
> > > > > DISCLAIMER: Hooking IDT directly is bad and
> > you
> > > > should not doit for
> > > > > anything
> > > > > than
> > > > > in house tools.
> > > > >
> > > > > Regards, Dan
> > > > >
> > > > > ----- Original Message -----
> > > > > From:
> > > > > To: “NT Developers Interest List”
> > > >
> > > > > Sent: Monday, July 29, 2002 10:12 PM
> > > > > Subject: [ntdev] Re: EIP of last running
> > process
> > > > in timer interrupt
> > > > >
> > > > >
> > > > > > Thanks a lot for the information.
> > > > > > I apologize for the misonomer, what I meant
> > > > > > was a task not a process.
> > > > > >
> > > > > > I am not looking to trap context switches.
> > > > > >
> > > > > > What I am looking for, is the ability to
> > tell if
> > > > my NIC miniport
> > > > > > was last running when a timer interrupt
> > occured.
> > > > > > The last running code of the NIC miniport
> > could
> > > > have been at DISPATCH
> > > > > > level.
> > > > > >
> > > > > > As in Linux, where I could hook into the
> > timer
> > > > ISR and inspect
> > > > > > ‘current’ when the ISR is vectored, which
> > would
> > > > tell me the last running
> > > > > > task and then I could get to the PEB of that
> > > > task and find out
> > > > > > if it was my card driver running.
> > > > > >
> > > > > > I need this to get the CPU utilization of my
> > NIC
> > > > driver.
> > > > > > How do I do this on NT / W2K/ XP ?
> > > > > >
> > > > > > TIA
> > > > > >
> > > > > > >>1. Contrary to the populary beleif,
> > process
> > > > DONT RUN. Threads do.
> > > > > > >>2. Accesibe data for you is current thread
> > and
> > > > next scheduled thread,
> > > > if
> > > > > > >>any
> > > > > > >>3. If you need to trap context switches,
> > then
> >
> === message truncated ===
>
>
> =====
> Prasad S. Dabak
> Chief Software Architect
> Ensim India Private Limited
> http://www.ensim.com
> Co-author of the book “Undocumented Windows NT”
> ISBN 0764545698
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
