given
namespace WindowsService1
{
public class Service1 : System.ServiceProcess.ServiceBase.........

private void timer1_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
   ArrayList myAL = new ArrayList();
   CustomClass objCont = new ControllerClass;
   CustomClass objInfo = new InfoClass;

   myAL = objCont.CreateArrayListofObjects()

   for (int i = 0; i <= myAl.Count; i++){
      objInfo  = objCont.HydrateInfo_Object();
      objCont.DoSomething(objInfo)
  }
}
how do I think about this service from a memory allocation/deallocation
perspective?  I would like to know just by looking at code that any
objects,arraylists,strings,integers that are created, are going to be
deallocated at the end of the timer process.

how do i think in the simplest way, about where and when I declare and
instantiate reference types so that I know they will be cleaned up.

If my main processing loop in my timer event which will loop n times every n
seconds is also instantiating other objects, each of which has its own
constructors and object declarations corresponding to typical application
needs, how do I think about the allocation/deallocation of those memory
resources?  I want to make sure there are no memory orphans that I have
created when I simply set

Is there an article that would contain a fairly simple explanation of this?
After attempting to instrument my app into Perfmon, CLRProfiler and then
creating a trace class which logs memory info before and after each
function, I found this to be too complicated and reactive. If I knew exactly
what was going on just by looking at my initialization code, I wouldn't need
the instrumentation tools.

I know the same rules apply here as any application but given here that even
8 bytes that are not deallocated will be stolen from the available memory
people every time the timer fires. Within each firing of the timer is a loop
that could conceivably instantiate obects which themselves may not
deallocate their member variables. I don't want a memory leak, even a
trickle.  ;-)

Thank you,  -Greg