We extensively hooked the GDI when I was at Number Nine, and we never had
any stability issues.
But for example, I want to collect timing statistics of a live system: I
turn on TrueTime, it hooks the world and a half, yet things go on. I want to
check coverage on a live system, so, I turn on TrueCoverage, it hooks just
about everything under the sun, things go on normally. I want to profile
memory allocation and deallocation patterns, so, I hook the memory
alloc/dealloc functions and collect data for future data reduction. I want
to perform a live measurement of my OpenGL or Direct3D frame rate, so I hook
SwapBuffers and I compute the frame rate inside that hook, and I then access
physical video memory to optionally superimpose a frame rate gauge to the
current screen. I want to measure how many times I call glBegin/glEnd, and I
want to split the number of calls according to which polygon I’m drawing. I
want to time a bitblt according to which ROP it invokes. I want to trap that
elusive problem that happens every night around 3 in the morning, so, I turn
on BoundsChecker on the live system, and bingo, I get my event recorded and
data I can analyze, and, if that hook generates an Int 3, I can write my own
Int 3 driver - hook Int 3, that is - and grab information on the fly.
And so on, there’s more to hooking than single-stepping through a debugger.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@3Dlabs.com
Sent: Tuesday, January 27, 2004 11:17 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NtCreateSection() - relation between parent and
child process
Ok, so I understand fully that a debugger must do these things (or at least,
if you want a complete debugging tool, e.g., SoftICE, you must do this,
unless you can convince MS to have an undocumented (or documented) way of
officially “hooking” system calls).
I just wonder how you deal with competing “hookers” (no pun intended) that
may have got there before you, and potentially gets the unloaded at a later
stage, which means that your “old hook” pointer is no pointing into dead
space in memory? Obviously, I can understand that the answer is a “company
secret”, and if it is, can you just explain as much as possible about it,
without revealing the “secret” bits?
I’m just curious, rather than having any specific use for this. In fact, I
haven’t “hooked” anything since I left off the Atari ST that used to be my
home-computer many years ago. At that time, hooking into the OS was just
about the only way to do things if you didn’t have a “public” support for
it.
–
Mats
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, January 27, 2004 4:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NtCreateSection() - relation between parent and
child process
We hook all sorts of things all the time, and we don’t have
any problems.
And our software is very much commercial grade, and no, it
isn’t a piece of
shit !
Point being: do the job right, and hooking is invisible.
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Don Burn
Sent: Monday, January 26, 2004 9:49 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] NtCreateSection() - relation between parent and
child process
The whole concept of hooking is a BAD IDEA. Hopefully this
is for a driver
for you testing only, commercial software with this is a
PIECE OF SHIT.
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
----- Original Message -----
From:
> To: “Windows System Software Devs Interest List”
> Sent: Monday, January 26, 2004 9:46 AM
> Subject: [ntdev] NtCreateSection() - relation between parent and child
> process
>
>
> > Hi again,
> >
> > Another question came to my mind.
> >
> > I hooked NtCreateSection() (as was suggested by the guys from
> > www.sysinternals.com back in 1997) right below the frontier
> from user mode
> to kernel mode
> > (changed the SDT entry). Since currently my driver produces
> some debug
> output,
> > I see a query of the section for the child process each
> second or so and
> > obviously coming from the parent process. How is that? What
> does it mean?
> >
> > Could it be that this is how the parent determines wether the child
> process
> > is still active (one of the infamous Wait* functions maybe?!).
> >
> > Does anyone have some details on that?
> >
> > Oliver
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@acm.org
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named
> addressee only. It
> contains information that may be confidential. Unless you are
> the named
> addressee or an authorized designee, you may not copy or use
> it, or disclose
> it to anyone else. If you received it in error please notify
> us immediately
> and then destroy it.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.