Re: Excess memory usage growth for a process

Marc Brooks <[email protected]> Thu, 6 Aug 2009 14:46:53 -0500
Newsgroups gmane.comp.windows.devel.dotnet.advanced
Message-ID <[email protected]>
Now that you've got the memory creep happening, take a crash dump and
see what's on the various heaps:

Tess gives the best rundown
http://blogs.msdn.com/tess/archive/2008/02/15/net-debugging-demos-lab-3-mem=
ory.aspx

Also useful:

http://msdn.microsoft.com/en-us/magazine/cc163528.aspx
http://www.eggheadcafe.com/articles/20060114.asp
http://www.dumpanalysis.org/blog/index.php/2007/08/19/crash-dump-analysis-p=
atterns-part-20b/

Things are tons easier with SOSEX v2

http://www.stevestechspot.com/SOSEXV2NowAvailable.aspx


On Thu, Aug 6, 2009 at 14:35, Eddie Lascu<[email protected]> wrote:
> Hi Folks,
>
> So I have been running this Red Gate Memory Profiler for more than 8 days
> now and I can see some very interesting developments. The Profiler is
> monitoring some of the Performance Counters. One in particular has caught=
 my
> interest and that is the size of Private Bytes. Although steady for the
> first two days at 48 MB, after that it started to grow slowly and what wa=
s a
> flat line before, turned into a ascending incline ramp. At the moment I t=
ype
> this message, the size of the Private Bytes is 855 MB. In the task manage=
r,
> my process is indicated as having the Virtual Memory size up to 876 MB wh=
ile
> the Mem Usage is only 64 MB.
> I believe this clearly indicates that there is no memory leak per se, but
> rather is just that the large objects heap is growing w/o control.
> Is my assessment correct?
>
> Regards,
> Eddie
>
>
> -----Original Message-----
> From: Discussion of advanced .NET topics.
> [mailto:[email protected]] On Behalf Of Trey Nash
> Sent: Thursday, July 30, 2009 2:24 PM
> To: [email protected]
> Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a process
>
> Hi,
>
> Yes, ADPlus is really just a complex VB script that drive windb(a)g. =C2=
=A0If you
> feed it the -? option, it should spew out a lot of helpful info on the
> various ways you can use it.
>
> I wrote a blog post on our team blog not too long ago regarding ADPlus th=
at
> may be helpful to become more familiar with it:
>
> http://blogs.msdn.com/ntdebugging/archive/2009/05/18/capturing-adplus-clr=
-cr
> ashes.aspx
>
> I hope this helps,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0-Trey
>
>> -----Original Message-----
>> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
>> [email protected]] On Behalf Of Eddie Lascu
>> Sent: Thursday, July 30, 2009 1:04 PM
>> To: [email protected]
>> Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a process
>>
>> Thank you, Guys. I will look into that as well. Do I need a special
>> start of
>> the process if I am to use ADPlus or I can attach to the process later?
>>
>>
>> -----Original Message-----
>> From: Discussion of advanced .NET topics.
>> [mailto:[email protected]] On Behalf Of Greg Young
>> Sent: Thursday, July 30, 2009 1:52 PM
>> To: [email protected]
>> Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a process
>>
>> Yep exactly what ADPlus is meant for! you can even do this right
>> within ADPlus :)
>>
>> On Thu, Jul 30, 2009 at 1:49 PM, Wilson,
>> Phil<[email protected]>
>> wrote:
>> > Not answering this particular question, but I believe you could hook
>> all
>> this together to automatically get that dump when the memory gets large
>> if
>> it's rare enough that you don't want to sit and look at it all day.
>> Perfmon
>> has triggers that can fire off a script, and you can fire off the
>> debugging
>> script ADPlus to dump your process with the -hang option.
>> >
>> > Phil Wilson
>> >
>> >
>> > -----Original Message-----
>> > From: Discussion of advanced .NET topics.
>> [mailto:[email protected]] On Behalf Of Eddie Lascu
>> > Sent: Wednesday, July 29, 2009 11:40 AM
>> > To: [email protected]
>> > Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a
>> process
>> >
>> > Based on my preliminary reading of what this has to offer, it seems
>> you
>> can
>> > integrate it with your VS IDE (not an option for me as my processes
>> are
>> > already deployed) or use it via WinDbg, but you need to look at the
>> debug
>> > version or the runtime version that has the .pdb file (not an option
>> either
>> > as I only have the sole runtime file deployed, but much easily
>> fixable).
>> Is
>> > this statement accurate?
>> >
>> > Thanks,
>> > Eddie
>> >
>> > -----Original Message-----
>> > From: Discussion of advanced .NET topics.
>> > [mailto:[email protected]] On Behalf Of Adam
>> Tuliper
>> > Sent: Wednesday, July 29, 2009 1:24 PM
>> > To: [email protected]
>> > Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a
>> process
>> >
>> >
>> http://blogs.msdn.com/alejacma/archive/2009/06/30/sos-cheat-sheet-net-
>> 2-0-3-
>> > 0-3-5.aspx
>> >
>> > !DumpHeap -min 85000
>> > !EEHeap -GC; !DumpHeap <LOH begin> <LOH allocated>
>> > =C2=A0 =C2=A0-> Shows all objects in Large Object Heap (LOH/Gen 3).
>> >
>> >
>> >
>> >
>> > On Wed, Jul 29, 2009 at 1:06 PM, Greg Young <[email protected]>
>> wrote:
>> >
>> >> Yes with ants you have to wait for the problem to happen.
>> >>
>> >> if you google SOS you can find some tutorials on it (it is a
>> separate
>> >> download from windbg ... it can also be used in visual studio!).
>> John
>> >> Robbins also has a great book covering the subject that I highly
>> >> recommend.
>> >>
>> >> Cheers,
>> >>
>> >> greg
>> >>
>> >> On Wed, Jul 29, 2009 at 1:01 PM, Eddie Lascu<[email protected]>
>> wrote:
>> >> > Shoot, I didn't know SOS can do that for you. Can you share more
>> about
>> >> this
>> >> > tool (a link to download it)? Is it part of the WinDbg tool that
>> comes
>> >> from
>> >> > Microsoft? It's true that with ANTS I am at the mercy of the
>> system,
>> >> hoping
>> >> > it will go nuts again and will have the memory size shut up crazy
>> high.
>> >> >
>> >> > Cheers,
>> >> > Eddie
>> >> >
>> >> >
>> >> >
>> >> > -----Original Message-----
>> >> > From: Discussion of advanced .NET topics.
>> >> > [mailto:[email protected]] On Behalf Of Greg
>> Young
>> >> > Sent: Wednesday, July 29, 2009 12:46 PM
>> >> > To: [email protected]
>> >> > Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a
>> process
>> >> >
>> >> > The wonderful thing about SOS is you dont need to run a profiler
>> ...
>> >> > when it happens take a memory dump, look whats actually happening
>> in
>> >> > the running app, is your LOH fragmented? Otherwise you are just
>> >> > sticking your thumb up your butt and saying it will rain next
>> >> > thursday.
>> >> >
>> >> > On Wed, Jul 29, 2009 at 12:43 PM, Eddie Lascu<[email protected]>
>> >> wrote:
>> >> >> I am using Reg Gate ANTS to profile the app, but it may take too
>> much
>> > to
>> >> >> happen again. Before the spike I saw last weekend, the processes
>> ran
>> > for
>> >> > 3-4
>> >> >> months with no significant change in the size of memory used.
>> >> >> Will look into Process.WorkingSet.
>> >> >>
>> >> >> Thanks,
>> >> >> Eddie
>> >> >>
>> >> >>
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: Discussion of advanced .NET topics.
>> >> >> [mailto:[email protected]] On Behalf Of Greg
>> Young
>> >> >> Sent: Wednesday, July 29, 2009 12:38 PM
>> >> >> To: [email protected]
>> >> >> Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a
>> process
>> >> >>
>> >> >> Task manager shows you working set not total memory used but yes
>> the
>> >> >> process class can help you with that (Process.WorkingSet as an
>> >> >> example).
>> >> >>
>> >> >> Have you verified the LOH being the problem by using SOS?
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Greg
>> >> >>
>> >> >> On Wed, Jul 29, 2009 at 12:33 PM, Eddie
>> Lascu<[email protected]>
>> >> wrote:
>> >> >>> Hi guys,
>> >> >>>
>> >> >>> In light of this article:
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >
>> http://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-
>> large-ob
>> >> >> ject-heap/
>> >> >>>
>> >> >>> I am no longer sure what I have is a memory leak. I could see
>> how
>> some
>> >> of
>> >> >> the things that happen in my application match the scenarios
>> described
>> >> in
>> >> >> the above article. Hence, I am ready to think about a workaround.
>> My
>> >> >> services are set up to run automatically and restart in case they
>> > crash.
>> >> >> While they never crash, I could leverage that feature and use it
>> to
>> fix
>> >> > this
>> >> >> excess memory usage that I experience every once in a blue moon.
>> What
>> I
>> >> >> thought was to monitor the memory used and terminate the
>> application
>> in
>> >> > case
>> >> >> it exceeds a set threshold. The Windows Service Manager will then
>> >> restart
>> >> >> the service and all the memory will be reclaimed by the OS.
>> >> >>>
>> >> >>> My question at this point is whether the .NET Framework has some
>> > metric
>> >> >> classes that can help monitor the total amount of memory
>> allocated
>> >> within
>> >> > a
>> >> >> process. Surely System.Diagnostics must have something like that.
>> Is
>> >> > anyone
>> >> >> aware of a way to find out what memory is used by a process, just
>> like
>> >> the
>> >> >> Task Manager does?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Eddie
>> >> >>>
>> >> >>>
>> >> >>> -----Original Message-----
>> >> >>> From: Discussion of advanced .NET topics.
>> >> >> [mailto:[email protected]] On Behalf Of Shawn
>> >> > Wildermuth
>> >> >>> Sent: Monday, July 27, 2009 12:49 PM
>> >> >>> To: [email protected]
>> >> >>> Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a
>> > process
>> >> >>>
>> >> >>> Also, your 'using' statement stuff should help, but are you sure
>> that
>> >> all
>> >> >>> your object (XML classes and db connection classes) that support
>> >> >> IDisposable
>> >> >>> are being cleaned up?
>> >> >>>
>> >> >>> Thanks,
>> >> >>>
>> >> >>> Shawn Wildermuth
>> >> >>> http://wildermuth.com
>> >> >>> https://agilitrain.com
>> >> >>> Microsoft MVP (C#), MCSD.NET, Author and Speaker
>> >> >>>
>> >> >>> The Silverlight Tour is coming to a city near you!
>> >> >>>
>> >> >>>
>> >> >>> -----Original Message-----
>> >> >>> From: Discussion of advanced .NET topics.
>> >> >>> [mailto:[email protected]] On Behalf Of John
>> Warner
>> >> >>> Sent: Monday, July 27, 2009 12:28 PM
>> >> >>> To: [email protected]
>> >> >>> Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a
>> > process
>> >> >>>
>> >> >>> I don't disagree with you just note that before 'some change'
>> working
>> >> OK
>> >> >>> no memory leaks, after change, memory leak. We both know your
>> code
>> did
>> >> > not
>> >> >>> recompile itself to include a memory leak ...
>> >> >>> That reminds has the framework/runtimes been updated/patched?
>> >> >>>
>> >> >>> John Warner
>> >> >>>
>> >> >>>
>> >> >>>> -----Original Message-----
>> >> >>>> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
>> >> >>>> [email protected]] On Behalf Of Eddie Lascu
>> >> >>>> Sent: Monday, July 27, 2009 12:00 PM
>> >> >>>> To: [email protected]
>> >> >>>> Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a
>> >> >>>> process
>> >> >>>>
>> >> >>>> Hi John,
>> >> >>>>
>> >> >>>> I could check that with our system administrators. Do you think
>> that
>> >> can
>> >> >>> be
>> >> >>>> a possible explanation?
>> >> >>>> I just talked with one of the DB Admin and she said she made
>> some
>> >> >>> changes
>> >> >>>> on
>> >> >>>> some Stored Produces, but nothing as dramatic as a patch
>> update. She
>> >> >>> also
>> >> >>>> said that the drivers for the network cards were updated last
>> week,
>> >> but
>> >> >>> I
>> >> >>>> can't see how that can affect the memory used by my processes.
>> >> >>>>
>> >> >>>> Thanks,
>> >> >>>> Eddie
>> >> >>>>
>> >> >>>>
>> >> >>>> -----Original Message-----
>> >> >>>> From: Discussion of advanced .NET topics.
>> >> >>>> [mailto:[email protected]] On Behalf Of
>> >> >>>> John Warner
>> >> >>>> Sent: Monday, July 27, 2009 11:49 AM
>> >> >>>> To: [email protected]
>> >> >>>> Subject: Re: [ADVANCED-DOTNET] Excess memory usage growth for a
>> >> >>>> process
>> >> >>>>
>> >> >>>> Not what you are seeking, but has anything on the server
>> changed? An
>> >> >>>> Oracle patch or something of that nature?
>> >> >>>>
>> >> >>>> John Warner
>> >> >>>>
>> >> >>>>
>> >> >>>> > -----Original Message-----
>> >> >>>> > From: Discussion of advanced .NET topics. [mailto:ADVANCED-
>> >> >>>> > [email protected]] On Behalf Of Eddie Lascu
>> >> >>>> > Sent: Monday, July 27, 2009 11:33 AM
>> >> >>>> > To: [email protected]
>> >> >>>> > Subject: [ADVANCED-DOTNET] Excess memory usage growth for a
>> >> >>>> process
>> >> >>>> >
>> >> >>>> > Hi guys,
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > I need your help with an issue I am having right now. I have
>> > several
>> >> >>>> windows
>> >> >>>> > services deployed. These services gather some XML files from
>> the
>> >> >>>> internet
>> >> >>>> > and then parse the content and save the information in the
>> > database.
>> >> >>> The
>> >> >>>> > database is Oracle 11g, so the access is done through
>> ODP.NET. I
>> >> had
>> >> >>>> some
>> >> >>>> > issues before (and some of you with good memory may recall my
>> >> previous
>> >> >>>> > questions) where I noticed the memory used by these services
>> > growing
>> >> >>>> very
>> >> >>>> > high. At the time, I understood that some classes in the
>> ODP.NET
>> >> >>> library
>> >> >>>> use
>> >> >>>> > some JAVA code and they are known for not cleaning properly
>> after
>> >> >>> them.
>> >> >>>> As a
>> >> >>>> > result I rewrote my code in such a way that every dynamic
>> > allocation
>> >> >>> of
>> >> >>>> an
>> >> >>>> > object from the ODP.NET library was encompassed in an "using"
>> >> >>> statement,
>> >> >>>> > like this:
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > using (OracleCommand objDbCommand =3D new
>> >> >>>> > OracleCommand(strSqlSelectStatement,
>> >> >>>> > objConnection))
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > All was fine for a very long time. All my services kept a
>> constant
>> >> >>> size
>> >> >>>> when
>> >> >>>> > it came to the total memory used, a size that hovered around
>> 55-60
>> >> MB.
>> >> >>>> This
>> >> >>>> > was the case for months. At the beginning I checked the size
>> almost
>> >> on
>> >> >>> a
>> >> >>>> > daily basis. After a while, my confidence grew and I only
>> checked
>> > it
>> >> >>>> once a
>> >> >>>> > week or so. Every time I looked at the size of all my
>> processes (I
>> >> had
>> >> >>> 4
>> >> >>>> > that followed pretty much the same approach on dealing with
>> those
>> >> >>> Oracle
>> >> >>>> > objects) the size was around that 55-60 MB mark.
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > Now, all of a sudden, this last weekend, the size for some of
>> the
>> >> >>>> services
>> >> >>>> > shut up to about 690 MB, despite the fact the service was
>> running
>> >> with
>> >> >>>> the
>> >> >>>> > exact same code as it did a month ago. This represents a
>> potential
>> >> >>> fatal
>> >> >>>> > problem for the server that can get to a point where it can
>> no
>> >> longer
>> >> >>>> > allocate memory, so I need to find a way to understand what
>> the
>> > heck
>> >> >>> is
>> >> >>>> > going on. Unfortunately, I do not have any metrics
>> implemented in
>> > my
>> >> >>>> > application to log the total amount of memory used. That
>> would
>> have
>> >> >>> been
>> >> >>>> a
>> >> >>>> > very good indication on when exactly did this surge started
>> to
>> >> happen.
>> >> >>> I
>> >> >>>> > could have checked the Event Viewer to see if the server got
>> hit
>> by
>> >> a
>> >> >>>> > nuclear bomb or something on that precise moment. I really
>> don't
>> > get
>> >> >>>> this. I
>> >> >>>> > mean that's why we moved to .NET in the first place, to be
>> rid of
>> >> such
>> >> >>>> > concerns, like making sure all dynamically allocated objects
>> are
>> >> then
>> >> >>>> > destroyed.
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > Can anyone give me an idea on how to investigate this issue?
>> Are
>> >> there
>> >> >>>> tools
>> >> >>>> > out there that could be used to pick at the memory allocated
>> by a
>> >> >>>> process
>> >> >>>> > and see what are those objects that take up so much =C2=A0memo=
ry?
>> For
>> > the
>> >> >>>> time
>> >> >>>> > being, I have the processes running, but two of them are at
>> or
>> > close
>> >> >>> to
>> >> >>>> 690
>> >> >>>> > MB and I don't know how long will I be able to keep them
>> running.
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > If you had an issue like this, what would you try to do?
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > Any suggestion will be greatly appreciated.
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > TIA,
>> >> >>>> >
>> >> >>>> > Eddie
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >> >>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> >>>> > View archives and manage your subscription(s) at
>> >> >>>> > http://peach.ease.lsoft.com/archives
>> >> >>>>
>> >> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> >>>> View archives and manage your subscription(s) at
>> >> >>>> http://peach.ease.lsoft.com/archives
>> >> >>>>
>> >> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> >>>> View archives and manage your subscription(s) at
>> >> >>>> http://peach.ease.lsoft.com/archives
>> >> >>>
>> >> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> >>> View archives and manage your subscription(s) at
>> >> >>> http://peach.ease.lsoft.com/archives
>> >> >>>
>> >> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> >>> View archives and manage your subscription(s) at
>> >> >> http://peach.ease.lsoft.com/archives
>> >> >>>
>> >> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> >>> View archives and manage your subscription(s) at
>> >> >> http://peach.ease.lsoft.com/archives
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Les erreurs de grammaire et de syntaxe ont =C3=A9t=C3=A9 incluses =
pour
>> m'assurer
>> >> >> de votre attention
>> >> >>
>> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> >> View archives and manage your subscription(s) at
>> >> >> http://peach.ease.lsoft.com/archives
>> >> >>
>> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> >> View archives and manage your subscription(s) at
>> >> > http://peach.ease.lsoft.com/archives
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Les erreurs de grammaire et de syntaxe ont =C3=A9t=C3=A9 incluses p=
our
>> m'assurer
>> >> > de votre attention
>> >> >
>> >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> > View archives and manage your subscription(s) at
>> >> > http://peach.ease.lsoft.com/archives
>> >> >
>> >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> > View archives and manage your subscription(s) at
>> >> http://peach.ease.lsoft.com/archives
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Les erreurs de grammaire et de syntaxe ont =C3=A9t=C3=A9 incluses pou=
r
>> m'assurer
>> >> de votre attention
>> >>
>> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >> View archives and manage your subscription(s) at
>> >> http://peach.ease.lsoft.com/archives
>> >>
>> >
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> > View archives and manage your subscription(s) at
>> > http://peach.ease.lsoft.com/archives
>> >
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> > View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>> >
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> > View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>> >
>>
>>
>>
>> --
>> Les erreurs de grammaire et de syntaxe ont =C3=A9t=C3=A9 incluses pour m=
'assurer
>> de votre attention
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> View archives and manage your subscription(s) at
>> http://peach.ease.lsoft.com/archives
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> View archives and manage your subscription(s) at
> http://peach.ease.lsoft.com/archives
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> View archives and manage your subscription(s) at http://peach.ease.lsoft.=
com/archives
>



--=20
Marc C. Brooks
http://musingmarc.blogspot.com

NOT sent from an iPhone

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives