How can I keep a program (any installed program) from running after it
has been called but before it starts execution?

---

Clarification of Question by cddm-ga on 04 Apr 2005 13:16 PDT

I am wanting to write a prgram that would not let any application run
unless my program is able to verify it first; therefore, I need to
detect that an application has been called. Is there an event that
would signal the execution of a program? I want to know if there is
such an event for both C# and C++ .net.

---

Clarification of Question by cddm-ga on 19 Apr 2005 23:11 PDT

OK, I now have a simple service based on the example found on MSDN
that up to this point doesn't do anything, yet. Nevertheless, as far
as I understand, to use PsSetCreateProcessNotifyRoutine(), as in
codeproject's sample, I would need a kernel mode driver. How do I
implement the monitor using a service instead of the driver? Would a
hook also work?

Thanks

---

Clarification of Question by cddm-ga on 19 Apr 2005 23:23 PDT

I would much rather not use a driver, from what I have read they are
more troublesome if something goes wrong and getting rid of them might
mean having to reinstall the OS.

You can write a process monitor to do this.  Here is an explanation
with sample code: [ http://www.codeproject.com/threads/procmon.asp ]

Using the .Net framework will be challenging.  Unless you can find a
way to list a .Net assembly function as an entry point for a callback
from a DLL (and I'm guessing you can't), you'll need to use unmanaged
code to receive the notification from the OS.  This would be a simple
DLL that you write as a bridge between your .Net code and the OS.  I'd
start by compiling the sample code and just call into your .Net
process from there.

Would it be easier to write a process monitor using Visual C++ (not
.net), and if so, would the approach be the same as in the sample
code?

If you are willing to have a program running on the desktop, you can
probably just work from the samples at The Code Project.  You'll need
to incorporate some code to kill the offending processes.  Here is a
way to do that:

http://www.codeproject.com/threads/killprocess.asp

This is a class which you'll incorporate into your project and call
whenever another process is not approved by your process monitor.  I'd
strongly suggest that you modify the process monitor to output a
detailed log file or write to the event log, especially when it
decides to kill a process.

If you need this software to run "in the background" such as:
 1) on a user's computer so the user can't close it
 2) so it can't be accidentally closed by you or 'the janitor'
 3) so it will start running before a user logs into the workstation

then you'll have to write it as a service.  This makes things more
challenging, but still well within the range of mere mortals.  If you
don't already know how, you'll have to teach yourself how to write a
service (it's not terribly difficult):

http://www.codeproject.com/system/serviceskeleton.asp

and then combine all of these projects/libraries into a single piece of software.

It may well be possible to write portions of this (or the entire
thing) in .Net but I strongly doubt it.  I've never heard of drivers
written in .Net and the core of the process monitor has to act as a
driver to interact with the NT kernel.  Anyway, I'd build it in VC++
if it were my project.  Without good, working sample code to start
from you'd be in for some long nights.

Just as an aside, a simpler way to skin this cat might be to get a
list of running processes and then just kill any you don't like. 
There would obviously be some lag time between scans during which
other processes could do whatever, so this might not suffice.  If you
don't really need immediate notification and can live with periodic
scanning, start from one of the many projects here for enumerating the
running processes:

http://www.codeproject.com/threads/

The driver you are using here (ProcObsrv.c) is not the same as a video
driver or mouse driver.  Those get entries in the registry so that
they load every time the operating system starts, get mapped to areas
of physical memory and so forth.  In this project, a driver simply
means a piece of code that can directly access (and be accessed by)
kernel level Windows code.  If your software does something bad, it's
possible the OS will become a bit chunky but a reboot will clear that
right up.  Obviously these issues have to be found and tested out of
your software before you go live.  Your service will need to run under
an account that has sufficient permission on the local machine to
create a driver (i.e. access Windows kernel code).

There isn't any way to create a hook.  That would imply having your
process become the one notified of OS activities, handling the event
and passing notification of the events on to other parts of the OS. 
I'm sure you can see how that's not really going to be possible in any
reliable or secure OS.

I did mention some shortcuts in my last post if you are looking for a
simpler (but more limited) approach.  Polling periodically for a list
of running processes would not require driver-level code and would be
much simpler.  You would not be able to interrupt a process before it
started though, only catch it shortly after it was launched.  This
might be a good place to start and you could always push later for
your ideal approach.

In your current (ideal) approach, you are not implementing a service
instead of a driver, rather both.  In the initialization portion of
the service, you will create the driver and perform all of the work
that the ProcMon application does at startup.  Your driver will
receive a callback when a process starts so you may not need much, if
any code in the portion of the service that runs periodically.  If you
intend to continue with this approach you'll need to build the ProcMon
application and completely familiarize yourself with it so you know
what each part does.  It's entirely possible that you'll end up
keeping only a few small portions of it, or you may end up keeping
most of it intact and just patching your service to it.  I hope
someone is paying you good money for this :)