Memoryleak - garbage collector / WinCe 5.0 / CF 2.0

Hello,

I´m programming a C# application on Windows CE 5.0 and CF 2.0.
This application should run permanently (24h/7days). I realized that the
garbage collector (gc) does not free all the allocated memory. Thus after a
while (a few days) an OutOfMemory-exception occurs.

I wrote a small test application:
In a function I created a form (Form frm = new Form() which is shown by
ShowDialog(). I figured out that after closing this form and leaving the
function, some memory fragments won´t be freed by the gc (>= 4KB).
This behavior occurs when member variables (lists, bitmaps,...) are declared
in this created form. If I declare this member variables within a function
(stack) the memory will be totally freed.

As I can see there is a bug in Visual Studio 2005. The object ‘components‘
is created, but never used by the designer. The overridden dispose-function
in the designer.cs frees all the objects in the componets-object but – as I
said – this object is never beeing used.

I customized all overrides of dispose() in the designer.cs:

/// <summary>
/// Clean up any resources being used.
/// </summary>
/// <param name="disposing">true if managed resources should be disposed;
otherwise, false.</param>
protected override void Dispose(bool disposing)
{
if (disposing && this.Controls != null)
{
this.components = new System.ComponentModel.Container();
foreach (Control o in this.Controls)
components.Add(o);
components.Dispose();
}
base.Dispose(disposing);
}

Now, most of the memory is freed but periodically there still remain some
fragments in the memory (>=4KB up to 64KB (?)).

I also noticed that running this application on a desktop pc with the “big“
:NET framework – no memoryloak persists!


Has anyone noticed the same behaviour and/or found a solution for it?

Does anyone have experience with applications running round the clock on
Windows CE / CF 2.0?

Are there bugs in the gc on compact framework?


Thanks for your help, best regards Chris

Yes, we have applications that run 24/7 with CF 2.0 (written in Studio 05,
but I don't think that matters) and have not seen any leak. I doubt there
is a problem with the GC, my bet is that there's a problem in your code with
some object not having all of its resources freed. Keep in mind that
calling GC.Collect does *not* implicitly release memory back to the OS.
That happens only during compaction.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


"Chriz" <Chriz@discussions.microsoft.com> wrote in message
news:426B455D-5FB9-42CF-B754-06B26E722693@microsoft.com...
> Hello,
>
> I´m programming a C# application on Windows CE 5.0 and CF 2.0.
> This application should run permanently (24h/7days). I realized that the
> garbage collector (gc) does not free all the allocated memory. Thus after
> a
> while (a few days) an OutOfMemory-exception occurs.
>
> I wrote a small test application:
> In a function I created a form (Form frm = new Form() which is shown by
> ShowDialog(). I figured out that after closing this form and leaving the
> function, some memory fragments won´t be freed by the gc (>= 4KB).
> This behavior occurs when member variables (lists, bitmaps,...) are
> declared
> in this created form. If I declare this member variables within a function
> (stack) the memory will be totally freed.
>
> As I can see there is a bug in Visual Studio 2005. The object 'components'
> is created, but never used by the designer. The overridden
> dispose-function
> in the designer.cs frees all the objects in the componets-object but - as
> I
> said - this object is never beeing used.
>
> I customized all overrides of dispose() in the designer.cs:
>
> /// <summary>
> /// Clean up any resources being used.
> /// </summary>
> /// <param name="disposing">true if managed resources should be disposed;
> otherwise, false.</param>
> protected override void Dispose(bool disposing)
> {
> if (disposing && this.Controls != null)
> {
> this.components = new System.ComponentModel.Container();
> foreach (Control o in this.Controls)
> components.Add(o);
> components.Dispose();
> }
> base.Dispose(disposing);
> }
>
> Now, most of the memory is freed but periodically there still remain some
> fragments in the memory (>=4KB up to 64KB (?)).
>
> I also noticed that running this application on a desktop pc with the "big"
> :NET framework - no memoryloak persists!
>
>
> Has anyone noticed the same behaviour and/or found a solution for it?
>
> Does anyone have experience with applications running round the clock on
> Windows CE / CF 2.0?
>
> Are there bugs in the gc on compact framework?
>
>
> Thanks for your help, best regards Chris
>

Hi.
I have an app that leaks managed bytes over time similar to what is
described on a CE 5.0, .NET CF 2.0 SP1 system. It will leak to exhaustion
in about 9 hours in a certain configuration.

With no code changes except to target .NET CF 3.5 in my application, the
leak goes away.

It also does not leak on .NET FF on XP.

I wish I had a simple reproduction, but I do not (3rd party code is involved
with the reproduction). However, I'd be interested to hear:

1) Is there a known fix to a GC mem leak issue in .NETCF 3.5 over .NETCF
2.0?
2) If there is, can someone provide a link to where to read about it?
3) If not, is there an explanation for seeing the same code leak and not
leak on the 3 platforms I describe above?

My method for seeing the leak is looking at the 'Managed Bytes In Use After
GC' counter in RPM (on CE). On XP I can use the System.GC.GetTotalMemory
call.

In all cases, the memory number bounces up and down maybe +/- 20K and up to
+/- 1MB. But in the leak case, the average number climbs from about 2.7MB
to ~19MB when I finally see an OutOfMemory exception and sometimes
MissingMethodException (presumably becuase there's no memory to place JITted
code that has been pitched!).

Thanks for any help that anyone can provide!

Regards,
Wil

"Chriz" <Chriz@discussions.microsoft.com> wrote in message
news:426B455D-5FB9-42CF-B754-06B26E722693@microsoft.com...
> Hello,
>
> I´m programming a C# application on Windows CE 5.0 and CF 2.0.
> This application should run permanently (24h/7days). I realized that the
> garbage collector (gc) does not free all the allocated memory. Thus after
> a
> while (a few days) an OutOfMemory-exception occurs.
>
> I wrote a small test application:
> In a function I created a form (Form frm = new Form() which is shown by
> ShowDialog(). I figured out that after closing this form and leaving the
> function, some memory fragments won´t be freed by the gc (>= 4KB).
> This behavior occurs when member variables (lists, bitmaps,...) are
> declared
> in this created form. If I declare this member variables within a function
> (stack) the memory will be totally freed.
>
> As I can see there is a bug in Visual Studio 2005. The object 'components'
> is created, but never used by the designer. The overridden
> dispose-function
> in the designer.cs frees all the objects in the componets-object but - as
> I
> said - this object is never beeing used.
>
> I customized all overrides of dispose() in the designer.cs:
>
> /// <summary>
> /// Clean up any resources being used.
> /// </summary>
> /// <param name="disposing">true if managed resources should be disposed;
> otherwise, false.</param>
> protected override void Dispose(bool disposing)
> {
> if (disposing && this.Controls != null)
> {
> this.components = new System.ComponentModel.Container();
> foreach (Control o in this.Controls)
> components.Add(o);
> components.Dispose();
> }
> base.Dispose(disposing);
> }
>
> Now, most of the memory is freed but periodically there still remain some
> fragments in the memory (>=4KB up to 64KB (?)).
>
> I also noticed that running this application on a desktop pc with the "big"
> :NET framework - no memoryloak persists!
>
>
> Has anyone noticed the same behaviour and/or found a solution for it?
>
> Does anyone have experience with applications running round the clock on
> Windows CE / CF 2.0?
>
> Are there bugs in the gc on compact framework?
>
>
> Thanks for your help, best regards Chris
>

If you use the CF 3.5 runtimes, but target 2.0 compatability do you also see
it?


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

"WilS" <wstarknospam04@pobox.com> wrote in message
news:%23UgbU3SvIHA.420@TK2MSFTNGP02.phx.gbl...
> Hi.
> I have an app that leaks managed bytes over time similar to what is
> described on a CE 5.0, .NET CF 2.0 SP1 system. It will leak to exhaustion
> in about 9 hours in a certain configuration.
>
> With no code changes except to target .NET CF 3.5 in my application, the
> leak goes away.
>
> It also does not leak on .NET FF on XP.
>
> I wish I had a simple reproduction, but I do not (3rd party code is
> involved with the reproduction). However, I'd be interested to hear:
>
> 1) Is there a known fix to a GC mem leak issue in .NETCF 3.5 over .NETCF
> 2.0?
> 2) If there is, can someone provide a link to where to read about it?
> 3) If not, is there an explanation for seeing the same code leak and not
> leak on the 3 platforms I describe above?
>
> My method for seeing the leak is looking at the 'Managed Bytes In Use
> After GC' counter in RPM (on CE). On XP I can use the
> System.GC.GetTotalMemory call.
>
> In all cases, the memory number bounces up and down maybe +/- 20K and up
> to +/- 1MB. But in the leak case, the average number climbs from about
> 2.7MB to ~19MB when I finally see an OutOfMemory exception and sometimes
> MissingMethodException (presumably becuase there's no memory to place
> JITted code that has been pitched!).
>
> Thanks for any help that anyone can provide!
>
> Regards,
> Wil
>
> "Chriz" <Chriz@discussions.microsoft.com> wrote in message
> news:426B455D-5FB9-42CF-B754-06B26E722693@microsoft.com...
>> Hello,
>>
>> I´m programming a C# application on Windows CE 5.0 and CF 2.0.
>> This application should run permanently (24h/7days). I realized that the
>> garbage collector (gc) does not free all the allocated memory. Thus after
>> a
>> while (a few days) an OutOfMemory-exception occurs.
>>
>> I wrote a small test application:
>> In a function I created a form (Form frm = new Form() which is shown by
>> ShowDialog(). I figured out that after closing this form and leaving the
>> function, some memory fragments won´t be freed by the gc (>= 4KB).
>> This behavior occurs when member variables (lists, bitmaps,...) are
>> declared
>> in this created form. If I declare this member variables within a
>> function
>> (stack) the memory will be totally freed.
>>
>> As I can see there is a bug in Visual Studio 2005. The object
>> 'components'
>> is created, but never used by the designer. The overridden
>> dispose-function
>> in the designer.cs frees all the objects in the componets-object but - as
>> I
>> said - this object is never beeing used.
>>
>> I customized all overrides of dispose() in the designer.cs:
>>
>> /// <summary>
>> /// Clean up any resources being used.
>> /// </summary>
>> /// <param name="disposing">true if managed resources should be disposed;
>> otherwise, false.</param>
>> protected override void Dispose(bool disposing)
>> {
>> if (disposing && this.Controls != null)
>> {
>> this.components = new System.ComponentModel.Container();
>> foreach (Control o in this.Controls)
>> components.Add(o);
>> components.Dispose();
>> }
>> base.Dispose(disposing);
>> }
>>
>> Now, most of the memory is freed but periodically there still remain some
>> fragments in the memory (>=4KB up to 64KB (?)).
>>
>> I also noticed that running this application on a desktop pc with the
>> "big"
>> :NET framework - no memoryloak persists!
>>
>>
>> Has anyone noticed the same behaviour and/or found a solution for it?
>>
>> Does anyone have experience with applications running round the clock on
>> Windows CE / CF 2.0?
>>
>> Are there bugs in the gc on compact framework?
>>
>>
>> Thanks for your help, best regards Chris
>>
>
>

I'm not sure.

I assume this means building with a .NETCF 2.0 target, then running on a CE
platform that only has .NET CF 3.5?

If so, this will take me a while to answer, as part of my problem is getting
a good nk.bin build with .NETCF 3.5. (The nk.bin that I do build with the
..NETCF 3.5 component complains when I run a program that targets .NETCF 3.5
that not all of the pieces for .NET are present.)

Right now, I'm relying on VS2008 deploying .NETCF 3.5 to even test that the
memory leak is gone.

So, I guess I need to build an nk.bin that omits .NETCF 2.0 (and 3.5), then
deploy 3.5 with VS. Then run my program that was built targeting 2.0 to try
out what you're suggesting?

Does that all sound right?

Or can this be done with a manifest file?

Thanks,
Wil

"Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
news:u4kxEmbvIHA.2360@TK2MSFTNGP05.phx.gbl...
> If you use the CF 3.5 runtimes, but target 2.0 compatability do you also
> see it?
>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded community
> http://community.OpenNETCF.com
>
> "WilS" <wstarknospam04@pobox.com> wrote in message
> news:%23UgbU3SvIHA.420@TK2MSFTNGP02.phx.gbl...
>> Hi.
>> I have an app that leaks managed bytes over time similar to what is
>> described on a CE 5.0, .NET CF 2.0 SP1 system. It will leak to
>> exhaustion in about 9 hours in a certain configuration.
>>
>> With no code changes except to target .NET CF 3.5 in my application, the
>> leak goes away.
>>
>> It also does not leak on .NET FF on XP.
>>
>> I wish I had a simple reproduction, but I do not (3rd party code is
>> involved with the reproduction). However, I'd be interested to hear:
>>
>> 1) Is there a known fix to a GC mem leak issue in .NETCF 3.5 over .NETCF
>> 2.0?
>> 2) If there is, can someone provide a link to where to read about it?
>> 3) If not, is there an explanation for seeing the same code leak and not
>> leak on the 3 platforms I describe above?
>>
>> My method for seeing the leak is looking at the 'Managed Bytes In Use
>> After GC' counter in RPM (on CE). On XP I can use the
>> System.GC.GetTotalMemory call.
>>
>> In all cases, the memory number bounces up and down maybe +/- 20K and up
>> to +/- 1MB. But in the leak case, the average number climbs from about
>> 2.7MB to ~19MB when I finally see an OutOfMemory exception and sometimes
>> MissingMethodException (presumably becuase there's no memory to place
>> JITted code that has been pitched!).
>>
>> Thanks for any help that anyone can provide!
>>
>> Regards,
>> Wil
>>
>> "Chriz" <Chriz@discussions.microsoft.com> wrote in message
>> news:426B455D-5FB9-42CF-B754-06B26E722693@microsoft.com...
>>> Hello,
>>>
>>> I´m programming a C# application on Windows CE 5.0 and CF 2.0.
>>> This application should run permanently (24h/7days). I realized that the
>>> garbage collector (gc) does not free all the allocated memory. Thus
>>> after a
>>> while (a few days) an OutOfMemory-exception occurs.
>>>
>>> I wrote a small test application:
>>> In a function I created a form (Form frm = new Form() which is shown
>>> by
>>> ShowDialog(). I figured out that after closing this form and leaving the
>>> function, some memory fragments won´t be freed by the gc (>= 4KB).
>>> This behavior occurs when member variables (lists, bitmaps,...) are
>>> declared
>>> in this created form. If I declare this member variables within a
>>> function
>>> (stack) the memory will be totally freed.
>>>
>>> As I can see there is a bug in Visual Studio 2005. The object
>>> 'components'
>>> is created, but never used by the designer. The overridden
>>> dispose-function
>>> in the designer.cs frees all the objects in the componets-object but -
>>> as I
>>> said - this object is never beeing used.
>>>
>>> I customized all overrides of dispose() in the designer.cs:
>>>
>>> /// <summary>
>>> /// Clean up any resources being used.
>>> /// </summary>
>>> /// <param name="disposing">true if managed resources should be
>>> disposed;
>>> otherwise, false.</param>
>>> protected override void Dispose(bool disposing)
>>> {
>>> if (disposing && this.Controls != null)
>>> {
>>> this.components = new System.ComponentModel.Container();
>>> foreach (Control o in this.Controls)
>>> components.Add(o);
>>> components.Dispose();
>>> }
>>> base.Dispose(disposing);
>>> }
>>>
>>> Now, most of the memory is freed but periodically there still remain
>>> some
>>> fragments in the memory (>=4KB up to 64KB (?)).
>>>
>>> I also noticed that running this application on a desktop pc with the
>>> "big"
>>> :NET framework - no memoryloak persists!
>>>
>>>
>>> Has anyone noticed the same behaviour and/or found a solution for it?
>>>
>>> Does anyone have experience with applications running round the clock on
>>> Windows CE / CF 2.0?
>>>
>>> Are there bugs in the gc on compact framework?
>>>
>>>
>>> Thanks for your help, best regards Chris
>>>
>>
>>
>
>

I think you can do a 2.0/3.5 side by side install and then just use a
manifest file to force it to use 3.5 in 2.0 compatibility mode.

http://blogs.msdn.com/davidklinems/.../19/409541.aspx
http://msdn.microsoft.com/en-us/library/bb629366.aspx


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com



"WilS" <wstarknospam04@pobox.com> wrote in message
news:esxcFXCwIHA.4492@TK2MSFTNGP02.phx.gbl...
> I'm not sure.
>
> I assume this means building with a .NETCF 2.0 target, then running on a
> CE platform that only has .NET CF 3.5?
>
> If so, this will take me a while to answer, as part of my problem is
> getting a good nk.bin build with .NETCF 3.5. (The nk.bin that I do build
> with the .NETCF 3.5 component complains when I run a program that targets
> .NETCF 3.5 that not all of the pieces for .NET are present.)
>
> Right now, I'm relying on VS2008 deploying .NETCF 3.5 to even test that
> the memory leak is gone.
>
> So, I guess I need to build an nk.bin that omits .NETCF 2.0 (and 3.5),
> then deploy 3.5 with VS. Then run my program that was built targeting 2.0
> to try out what you're suggesting?
>
> Does that all sound right?
>
> Or can this be done with a manifest file?
>
> Thanks,
> Wil
>
> "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
> news:u4kxEmbvIHA.2360@TK2MSFTNGP05.phx.gbl...
>> If you use the CF 3.5 runtimes, but target 2.0 compatability do you also
>> see it?
>>
>>
>> --
>>
>> Chris Tacke, Embedded MVP
>> OpenNETCF Consulting
>> Giving back to the embedded community
>> http://community.OpenNETCF.com
>>
>> "WilS" <wstarknospam04@pobox.com> wrote in message
>> news:%23UgbU3SvIHA.420@TK2MSFTNGP02.phx.gbl...
>>> Hi.
>>> I have an app that leaks managed bytes over time similar to what is
>>> described on a CE 5.0, .NET CF 2.0 SP1 system. It will leak to
>>> exhaustion in about 9 hours in a certain configuration.
>>>
>>> With no code changes except to target .NET CF 3.5 in my application, the
>>> leak goes away.
>>>
>>> It also does not leak on .NET FF on XP.
>>>
>>> I wish I had a simple reproduction, but I do not (3rd party code is
>>> involved with the reproduction). However, I'd be interested to hear:
>>>
>>> 1) Is there a known fix to a GC mem leak issue in .NETCF 3.5 over .NETCF
>>> 2.0?
>>> 2) If there is, can someone provide a link to where to read about it?
>>> 3) If not, is there an explanation for seeing the same code leak and not
>>> leak on the 3 platforms I describe above?
>>>
>>> My method for seeing the leak is looking at the 'Managed Bytes In Use
>>> After GC' counter in RPM (on CE). On XP I can use the
>>> System.GC.GetTotalMemory call.
>>>
>>> In all cases, the memory number bounces up and down maybe +/- 20K and up
>>> to +/- 1MB. But in the leak case, the average number climbs from about
>>> 2.7MB to ~19MB when I finally see an OutOfMemory exception and sometimes
>>> MissingMethodException (presumably becuase there's no memory to place
>>> JITted code that has been pitched!).
>>>
>>> Thanks for any help that anyone can provide!
>>>
>>> Regards,
>>> Wil
>>>
>>> "Chriz" <Chriz@discussions.microsoft.com> wrote in message
>>> news:426B455D-5FB9-42CF-B754-06B26E722693@microsoft.com...
>>>> Hello,
>>>>
>>>> I´m programming a C# application on Windows CE 5.0 and CF 2.0.
>>>> This application should run permanently (24h/7days). I realized that
>>>> the
>>>> garbage collector (gc) does not free all the allocated memory. Thus
>>>> after a
>>>> while (a few days) an OutOfMemory-exception occurs.
>>>>
>>>> I wrote a small test application:
>>>> In a function I created a form (Form frm = new Form() which is shown
>>>> by
>>>> ShowDialog(). I figured out that after closing this form and leaving
>>>> the
>>>> function, some memory fragments won´t be freed by the gc (>= 4KB).
>>>> This behavior occurs when member variables (lists, bitmaps,...) are
>>>> declared
>>>> in this created form. If I declare this member variables within a
>>>> function
>>>> (stack) the memory will be totally freed.
>>>>
>>>> As I can see there is a bug in Visual Studio 2005. The object
>>>> 'components'
>>>> is created, but never used by the designer. The overridden
>>>> dispose-function
>>>> in the designer.cs frees all the objects in the componets-object but -
>>>> as I
>>>> said - this object is never beeing used.
>>>>
>>>> I customized all overrides of dispose() in the designer.cs:
>>>>
>>>> /// <summary>
>>>> /// Clean up any resources being used.
>>>> /// </summary>
>>>> /// <param name="disposing">true if managed resources should be
>>>> disposed;
>>>> otherwise, false.</param>
>>>> protected override void Dispose(bool disposing)
>>>> {
>>>> if (disposing && this.Controls != null)
>>>> {
>>>> this.components = new System.ComponentModel.Container();
>>>> foreach (Control o in this.Controls)
>>>> components.Add(o);
>>>> components.Dispose();
>>>> }
>>>> base.Dispose(disposing);
>>>> }
>>>>
>>>> Now, most of the memory is freed but periodically there still remain
>>>> some
>>>> fragments in the memory (>=4KB up to 64KB (?)).
>>>>
>>>> I also noticed that running this application on a desktop pc with the
>>>> "big"
>>>> :NET framework - no memoryloak persists!
>>>>
>>>>
>>>> Has anyone noticed the same behaviour and/or found a solution for it?
>>>>
>>>> Does anyone have experience with applications running round the clock
>>>> on
>>>> Windows CE / CF 2.0?
>>>>
>>>> Are there bugs in the gc on compact framework?
>>>>
>>>>
>>>> Thanks for your help, best regards Chris
>>>>
>>>
>>>
>>
>>
>
>

Chris,
Using the following config file seems to do the trick for getting 3.5
loaded with code built targeting 2.0:

<configuration>
<startup>
<supportedRuntime version="v3.5.0"/>
</startup>
</configuration>

I can verify this by looking at CE Remote Process viewer, and seeing
mscoree3_5.dll loaded as opposed to mscoree2_0.dll with the presence of the
..config file.

Watching the 'Managed Bytes In Use After GC' counter, it appears the memory
usage stays relatively constant over time in what was problem case.

So, the answer to your question is: No - I don't see the memory issue when
running with 3.5 after targeting 2.0 at build time.
If I go back to 2.0 on the same bits (remove the .config file) and run
again, I see the memory issue return.

Does this answer indicate something about where the problem lies?

Thanks for your help.

- Wil

"Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
news:%23XLvYcCwIHA.2068@TK2MSFTNGP05.phx.gbl...
>I think you can do a 2.0/3.5 side by side install and then just use a
>manifest file to force it to use 3.5 in 2.0 compatibility mode.
>
> http://blogs.msdn.com/davidklinems/.../19/409541.aspx
> http://msdn.microsoft.com/en-us/library/bb629366.aspx
>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded community
> http://community.OpenNETCF.com
>
>
>
> "WilS" <wstarknospam04@pobox.com> wrote in message
> news:esxcFXCwIHA.4492@TK2MSFTNGP02.phx.gbl...
>> I'm not sure.
>>
>> I assume this means building with a .NETCF 2.0 target, then running on a
>> CE platform that only has .NET CF 3.5?
>>
>> If so, this will take me a while to answer, as part of my problem is
>> getting a good nk.bin build with .NETCF 3.5. (The nk.bin that I do build
>> with the .NETCF 3.5 component complains when I run a program that targets
>> .NETCF 3.5 that not all of the pieces for .NET are present.)
>>
>> Right now, I'm relying on VS2008 deploying .NETCF 3.5 to even test that
>> the memory leak is gone.
>>
>> So, I guess I need to build an nk.bin that omits .NETCF 2.0 (and 3.5),
>> then deploy 3.5 with VS. Then run my program that was built targeting
>> 2.0 to try out what you're suggesting?
>>
>> Does that all sound right?
>>
>> Or can this be done with a manifest file?
>>
>> Thanks,
>> Wil
>>
>> "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
>> news:u4kxEmbvIHA.2360@TK2MSFTNGP05.phx.gbl...
>>> If you use the CF 3.5 runtimes, but target 2.0 compatability do you also
>>> see it?
>>>
>>>
>>> --
>>>
>>> Chris Tacke, Embedded MVP
>>> OpenNETCF Consulting
>>> Giving back to the embedded community
>>> http://community.OpenNETCF.com
>>>
>>> "WilS" <wstarknospam04@pobox.com> wrote in message
>>> news:%23UgbU3SvIHA.420@TK2MSFTNGP02.phx.gbl...
>>>> Hi.
>>>> I have an app that leaks managed bytes over time similar to what is
>>>> described on a CE 5.0, .NET CF 2.0 SP1 system. It will leak to
>>>> exhaustion in about 9 hours in a certain configuration.
>>>>
>>>> With no code changes except to target .NET CF 3.5 in my application,
>>>> the leak goes away.
>>>>
>>>> It also does not leak on .NET FF on XP.
>>>>
>>>> I wish I had a simple reproduction, but I do not (3rd party code is
>>>> involved with the reproduction). However, I'd be interested to hear:
>>>>
>>>> 1) Is there a known fix to a GC mem leak issue in .NETCF 3.5 over
>>>> .NETCF 2.0?
>>>> 2) If there is, can someone provide a link to where to read about it?
>>>> 3) If not, is there an explanation for seeing the same code leak and
>>>> not leak on the 3 platforms I describe above?
>>>>
>>>> My method for seeing the leak is looking at the 'Managed Bytes In Use
>>>> After GC' counter in RPM (on CE). On XP I can use the
>>>> System.GC.GetTotalMemory call.
>>>>
>>>> In all cases, the memory number bounces up and down maybe +/- 20K and
>>>> up to +/- 1MB. But in the leak case, the average number climbs from
>>>> about 2.7MB to ~19MB when I finally see an OutOfMemory exception and
>>>> sometimes MissingMethodException (presumably becuase there's no memory
>>>> to place JITted code that has been pitched!).
>>>>
>>>> Thanks for any help that anyone can provide!
>>>>
>>>> Regards,
>>>> Wil
>>>>
>>>> "Chriz" <Chriz@discussions.microsoft.com> wrote in message
>>>> news:426B455D-5FB9-42CF-B754-06B26E722693@microsoft.com...
>>>>> Hello,
>>>>>
>>>>> I´m programming a C# application on Windows CE 5.0 and CF 2.0.
>>>>> This application should run permanently (24h/7days). I realized that
>>>>> the
>>>>> garbage collector (gc) does not free all the allocated memory. Thus
>>>>> after a
>>>>> while (a few days) an OutOfMemory-exception occurs.
>>>>>
>>>>> I wrote a small test application:
>>>>> In a function I created a form (Form frm = new Form() which is shown
>>>>> by
>>>>> ShowDialog(). I figured out that after closing this form and leaving
>>>>> the
>>>>> function, some memory fragments won´t be freed by the gc (>= 4KB).
>>>>> This behavior occurs when member variables (lists, bitmaps,...) are
>>>>> declared
>>>>> in this created form. If I declare this member variables within a
>>>>> function
>>>>> (stack) the memory will be totally freed.
>>>>>
>>>>> As I can see there is a bug in Visual Studio 2005. The object
>>>>> 'components'
>>>>> is created, but never used by the designer. The overridden
>>>>> dispose-function
>>>>> in the designer.cs frees all the objects in the componets-object but -
>>>>> as I
>>>>> said - this object is never beeing used.
>>>>>
>>>>> I customized all overrides of dispose() in the designer.cs:
>>>>>
>>>>> /// <summary>
>>>>> /// Clean up any resources being used.
>>>>> /// </summary>
>>>>> /// <param name="disposing">true if managed resources should be
>>>>> disposed;
>>>>> otherwise, false.</param>
>>>>> protected override void Dispose(bool disposing)
>>>>> {
>>>>> if (disposing && this.Controls != null)
>>>>> {
>>>>> this.components = new System.ComponentModel.Container();
>>>>> foreach (Control o in this.Controls)
>>>>> components.Add(o);
>>>>> components.Dispose();
>>>>> }
>>>>> base.Dispose(disposing);
>>>>> }
>>>>>
>>>>> Now, most of the memory is freed but periodically there still remain
>>>>> some
>>>>> fragments in the memory (>=4KB up to 64KB (?)).
>>>>>
>>>>> I also noticed that running this application on a desktop pc with the
>>>>> "big"
>>>>> :NET framework - no memoryloak persists!
>>>>>
>>>>>
>>>>> Has anyone noticed the same behaviour and/or found a solution for it?
>>>>>
>>>>> Does anyone have experience with applications running round the clock
>>>>> on
>>>>> Windows CE / CF 2.0?
>>>>>
>>>>> Are there bugs in the gc on compact framework?
>>>>>
>>>>>
>>>>> Thanks for your help, best regards Chris
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

I'd say it sounds certainly a bug in the CF 2.0 CLR - I'd open a support
case with Microsoft on it.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

"WilS" <wstarknospam04@pobox.com> wrote in message
news:uUcmN3CwIHA.4916@TK2MSFTNGP03.phx.gbl...
> Chris,
> Using the following config file seems to do the trick for getting 3.5
> loaded with code built targeting 2.0:
>
> <configuration>
> <startup>
> <supportedRuntime version="v3.5.0"/>
> </startup>
> </configuration>
>
> I can verify this by looking at CE Remote Process viewer, and seeing
> mscoree3_5.dll loaded as opposed to mscoree2_0.dll with the presence of
> the .config file.
>
> Watching the 'Managed Bytes In Use After GC' counter, it appears the
> memory usage stays relatively constant over time in what was problem case.
>
> So, the answer to your question is: No - I don't see the memory issue when
> running with 3.5 after targeting 2.0 at build time.
> If I go back to 2.0 on the same bits (remove the .config file) and run
> again, I see the memory issue return.
>
> Does this answer indicate something about where the problem lies?
>
> Thanks for your help.
>
> - Wil
>
> "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
> news:%23XLvYcCwIHA.2068@TK2MSFTNGP05.phx.gbl...
>>I think you can do a 2.0/3.5 side by side install and then just use a
>>manifest file to force it to use 3.5 in 2.0 compatibility mode.
>>
>> http://blogs.msdn.com/davidklinems/.../19/409541.aspx
>> http://msdn.microsoft.com/en-us/library/bb629366.aspx
>>
>>
>> --
>>
>> Chris Tacke, Embedded MVP
>> OpenNETCF Consulting
>> Giving back to the embedded community
>> http://community.OpenNETCF.com
>>
>>
>>
>> "WilS" <wstarknospam04@pobox.com> wrote in message
>> news:esxcFXCwIHA.4492@TK2MSFTNGP02.phx.gbl...
>>> I'm not sure.
>>>
>>> I assume this means building with a .NETCF 2.0 target, then running on a
>>> CE platform that only has .NET CF 3.5?
>>>
>>> If so, this will take me a while to answer, as part of my problem is
>>> getting a good nk.bin build with .NETCF 3.5. (The nk.bin that I do
>>> build with the .NETCF 3.5 component complains when I run a program that
>>> targets .NETCF 3.5 that not all of the pieces for .NET are present.)
>>>
>>> Right now, I'm relying on VS2008 deploying .NETCF 3.5 to even test that
>>> the memory leak is gone.
>>>
>>> So, I guess I need to build an nk.bin that omits .NETCF 2.0 (and 3.5),
>>> then deploy 3.5 with VS. Then run my program that was built targeting
>>> 2.0 to try out what you're suggesting?
>>>
>>> Does that all sound right?
>>>
>>> Or can this be done with a manifest file?
>>>
>>> Thanks,
>>> Wil
>>>
>>> "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
>>> news:u4kxEmbvIHA.2360@TK2MSFTNGP05.phx.gbl...
>>>> If you use the CF 3.5 runtimes, but target 2.0 compatability do you
>>>> also see it?
>>>>
>>>>
>>>> --
>>>>
>>>> Chris Tacke, Embedded MVP
>>>> OpenNETCF Consulting
>>>> Giving back to the embedded community
>>>> http://community.OpenNETCF.com
>>>>
>>>> "WilS" <wstarknospam04@pobox.com> wrote in message
>>>> news:%23UgbU3SvIHA.420@TK2MSFTNGP02.phx.gbl...
>>>>> Hi.
>>>>> I have an app that leaks managed bytes over time similar to what is
>>>>> described on a CE 5.0, .NET CF 2.0 SP1 system. It will leak to
>>>>> exhaustion in about 9 hours in a certain configuration.
>>>>>
>>>>> With no code changes except to target .NET CF 3.5 in my application,
>>>>> the leak goes away.
>>>>>
>>>>> It also does not leak on .NET FF on XP.
>>>>>
>>>>> I wish I had a simple reproduction, but I do not (3rd party code is
>>>>> involved with the reproduction). However, I'd be interested to hear:
>>>>>
>>>>> 1) Is there a known fix to a GC mem leak issue in .NETCF 3.5 over
>>>>> .NETCF 2.0?
>>>>> 2) If there is, can someone provide a link to where to read about it?
>>>>> 3) If not, is there an explanation for seeing the same code leak and
>>>>> not leak on the 3 platforms I describe above?
>>>>>
>>>>> My method for seeing the leak is looking at the 'Managed Bytes In Use
>>>>> After GC' counter in RPM (on CE). On XP I can use the
>>>>> System.GC.GetTotalMemory call.
>>>>>
>>>>> In all cases, the memory number bounces up and down maybe +/- 20K and
>>>>> up to +/- 1MB. But in the leak case, the average number climbs from
>>>>> about 2.7MB to ~19MB when I finally see an OutOfMemory exception and
>>>>> sometimes MissingMethodException (presumably becuase there's no memory
>>>>> to place JITted code that has been pitched!).
>>>>>
>>>>> Thanks for any help that anyone can provide!
>>>>>
>>>>> Regards,
>>>>> Wil
>>>>>
>>>>> "Chriz" <Chriz@discussions.microsoft.com> wrote in message
>>>>> news:426B455D-5FB9-42CF-B754-06B26E722693@microsoft.com...
>>>>>> Hello,
>>>>>>
>>>>>> I´m programming a C# application on Windows CE 5.0 and CF 2.0.
>>>>>> This application should run permanently (24h/7days). I realized that
>>>>>> the
>>>>>> garbage collector (gc) does not free all the allocated memory. Thus
>>>>>> after a
>>>>>> while (a few days) an OutOfMemory-exception occurs.
>>>>>>
>>>>>> I wrote a small test application:
>>>>>> In a function I created a form (Form frm = new Form() which is
>>>>>> shown by
>>>>>> ShowDialog(). I figured out that after closing this form and leaving
>>>>>> the
>>>>>> function, some memory fragments won´t be freed by the gc (>= 4KB).
>>>>>> This behavior occurs when member variables (lists, bitmaps,...) are
>>>>>> declared
>>>>>> in this created form. If I declare this member variables within a
>>>>>> function
>>>>>> (stack) the memory will be totally freed.
>>>>>>
>>>>>> As I can see there is a bug in Visual Studio 2005. The object
>>>>>> 'components'
>>>>>> is created, but never used by the designer. The overridden
>>>>>> dispose-function
>>>>>> in the designer.cs frees all the objects in the componets-object
>>>>>> but - as I
>>>>>> said - this object is never beeing used.
>>>>>>
>>>>>> I customized all overrides of dispose() in the designer.cs:
>>>>>>
>>>>>> /// <summary>
>>>>>> /// Clean up any resources being used.
>>>>>> /// </summary>
>>>>>> /// <param name="disposing">true if managed resources should be
>>>>>> disposed;
>>>>>> otherwise, false.</param>
>>>>>> protected override void Dispose(bool disposing)
>>>>>> {
>>>>>> if (disposing && this.Controls != null)
>>>>>> {
>>>>>> this.components = new System.ComponentModel.Container();
>>>>>> foreach (Control o in this.Controls)
>>>>>> components.Add(o);
>>>>>> components.Dispose();
>>>>>> }
>>>>>> base.Dispose(disposing);
>>>>>> }
>>>>>>
>>>>>> Now, most of the memory is freed but periodically there still remain
>>>>>> some
>>>>>> fragments in the memory (>=4KB up to 64KB (?)).
>>>>>>
>>>>>> I also noticed that running this application on a desktop pc with the
>>>>>> "big"
>>>>>> :NET framework - no memoryloak persists!
>>>>>>
>>>>>>
>>>>>> Has anyone noticed the same behaviour and/or found a solution for it?
>>>>>>
>>>>>> Does anyone have experience with applications running round the clock
>>>>>> on
>>>>>> Windows CE / CF 2.0?
>>>>>>
>>>>>> Are there bugs in the gc on compact framework?
>>>>>>
>>>>>>
>>>>>> Thanks for your help, best regards Chris
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Seeing as whatever the issue is, it appears to be fixed in 3.5, the support
case I should open is on my issue around not being able to get a good nk.bin
with .NETCF 3.5 in it. :-) (Correct me if I'm wrong, but I'm guessing MS
won't bother to fix a bug in 2.0 when it is already fixed in 3.5.)

Thanks again for you suggestions.

- Wil

"Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
news:eCK975CwIHA.3792@TK2MSFTNGP02.phx.gbl...
> I'd say it sounds certainly a bug in the CF 2.0 CLR - I'd open a support
> case with Microsoft on it.
>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded community
> http://community.OpenNETCF.com
>
> "WilS" <wstarknospam04@pobox.com> wrote in message
> news:uUcmN3CwIHA.4916@TK2MSFTNGP03.phx.gbl...
>> Chris,
>> Using the following config file seems to do the trick for getting 3.5
>> loaded with code built targeting 2.0:
>>
>> <configuration>
>> <startup>
>> <supportedRuntime version="v3.5.0"/>
>> </startup>
>> </configuration>
>>
>> I can verify this by looking at CE Remote Process viewer, and seeing
>> mscoree3_5.dll loaded as opposed to mscoree2_0.dll with the presence of
>> the .config file.
>>
>> Watching the 'Managed Bytes In Use After GC' counter, it appears the
>> memory usage stays relatively constant over time in what was problem
>> case.
>>
>> So, the answer to your question is: No - I don't see the memory issue
>> when running with 3.5 after targeting 2.0 at build time.
>> If I go back to 2.0 on the same bits (remove the .config file) and run
>> again, I see the memory issue return.
>>
>> Does this answer indicate something about where the problem lies?
>>
>> Thanks for your help.
>>
>> - Wil
>>
>> "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
>> news:%23XLvYcCwIHA.2068@TK2MSFTNGP05.phx.gbl...
>>>I think you can do a 2.0/3.5 side by side install and then just use a
>>>manifest file to force it to use 3.5 in 2.0 compatibility mode.
>>>
>>> http://blogs.msdn.com/davidklinems/.../19/409541.aspx
>>> http://msdn.microsoft.com/en-us/library/bb629366.aspx
>>>
>>>
>>> --
>>>
>>> Chris Tacke, Embedded MVP
>>> OpenNETCF Consulting
>>> Giving back to the embedded community
>>> http://community.OpenNETCF.com
>>>
>>>
>>>
>>> "WilS" <wstarknospam04@pobox.com> wrote in message
>>> news:esxcFXCwIHA.4492@TK2MSFTNGP02.phx.gbl...
>>>> I'm not sure.
>>>>
>>>> I assume this means building with a .NETCF 2.0 target, then running on
>>>> a CE platform that only has .NET CF 3.5?
>>>>
>>>> If so, this will take me a while to answer, as part of my problem is
>>>> getting a good nk.bin build with .NETCF 3.5. (The nk.bin that I do
>>>> build with the .NETCF 3.5 component complains when I run a program that
>>>> targets .NETCF 3.5 that not all of the pieces for .NET are present.)
>>>>
>>>> Right now, I'm relying on VS2008 deploying .NETCF 3.5 to even test that
>>>> the memory leak is gone.
>>>>
>>>> So, I guess I need to build an nk.bin that omits .NETCF 2.0 (and 3.5),
>>>> then deploy 3.5 with VS. Then run my program that was built targeting
>>>> 2.0 to try out what you're suggesting?
>>>>
>>>> Does that all sound right?
>>>>
>>>> Or can this be done with a manifest file?
>>>>
>>>> Thanks,
>>>> Wil
>>>>
>>>> "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
>>>> news:u4kxEmbvIHA.2360@TK2MSFTNGP05.phx.gbl...
>>>>> If you use the CF 3.5 runtimes, but target 2.0 compatability do you
>>>>> also see it?
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Chris Tacke, Embedded MVP
>>>>> OpenNETCF Consulting
>>>>> Giving back to the embedded community
>>>>> http://community.OpenNETCF.com
>>>>>
>>>>> "WilS" <wstarknospam04@pobox.com> wrote in message
>>>>> news:%23UgbU3SvIHA.420@TK2MSFTNGP02.phx.gbl...
>>>>>> Hi.
>>>>>> I have an app that leaks managed bytes over time similar to what is
>>>>>> described on a CE 5.0, .NET CF 2.0 SP1 system. It will leak to
>>>>>> exhaustion in about 9 hours in a certain configuration.
>>>>>>
>>>>>> With no code changes except to target .NET CF 3.5 in my application,
>>>>>> the leak goes away.
>>>>>>
>>>>>> It also does not leak on .NET FF on XP.
>>>>>>
>>>>>> I wish I had a simple reproduction, but I do not (3rd party code is
>>>>>> involved with the reproduction). However, I'd be interested to hear:
>>>>>>
>>>>>> 1) Is there a known fix to a GC mem leak issue in .NETCF 3.5 over
>>>>>> .NETCF 2.0?
>>>>>> 2) If there is, can someone provide a link to where to read about it?
>>>>>> 3) If not, is there an explanation for seeing the same code leak and
>>>>>> not leak on the 3 platforms I describe above?
>>>>>>
>>>>>> My method for seeing the leak is looking at the 'Managed Bytes In Use
>>>>>> After GC' counter in RPM (on CE). On XP I can use the
>>>>>> System.GC.GetTotalMemory call.
>>>>>>
>>>>>> In all cases, the memory number bounces up and down maybe +/- 20K and
>>>>>> up to +/- 1MB. But in the leak case, the average number climbs from
>>>>>> about 2.7MB to ~19MB when I finally see an OutOfMemory exception and
>>>>>> sometimes MissingMethodException (presumably becuase there's no
>>>>>> memory to place JITted code that has been pitched!).
>>>>>>
>>>>>> Thanks for any help that anyone can provide!
>>>>>>
>>>>>> Regards,
>>>>>> Wil
>>>>>>
>>>>>> "Chriz" <Chriz@discussions.microsoft.com> wrote in message
>>>>>> news:426B455D-5FB9-42CF-B754-06B26E722693@microsoft.com...
>>>>>>> Hello,
>>>>>>>
>>>>>>> I´m programming a C# application on Windows CE 5.0 and CF 2.0.
>>>>>>> This application should run permanently (24h/7days). I realized that
>>>>>>> the
>>>>>>> garbage collector (gc) does not free all the allocated memory. Thus
>>>>>>> after a
>>>>>>> while (a few days) an OutOfMemory-exception occurs.
>>>>>>>
>>>>>>> I wrote a small test application:
>>>>>>> In a function I created a form (Form frm = new Form() which is
>>>>>>> shown by
>>>>>>> ShowDialog(). I figured out that after closing this form and leaving
>>>>>>> the
>>>>>>> function, some memory fragments won´t be freed by the gc (>= 4KB).
>>>>>>> This behavior occurs when member variables (lists, bitmaps,...) are
>>>>>>> declared
>>>>>>> in this created form. If I declare this member variables within a
>>>>>>> function
>>>>>>> (stack) the memory will be totally freed.
>>>>>>>
>>>>>>> As I can see there is a bug in Visual Studio 2005. The object
>>>>>>> 'components'
>>>>>>> is created, but never used by the designer. The overridden
>>>>>>> dispose-function
>>>>>>> in the designer.cs frees all the objects in the componets-object
>>>>>>> but - as I
>>>>>>> said - this object is never beeing used.
>>>>>>>
>>>>>>> I customized all overrides of dispose() in the designer.cs:
>>>>>>>
>>>>>>> /// <summary>
>>>>>>> /// Clean up any resources being used.
>>>>>>> /// </summary>
>>>>>>> /// <param name="disposing">true if managed resources should be
>>>>>>> disposed;
>>>>>>> otherwise, false.</param>
>>>>>>> protected override void Dispose(bool disposing)
>>>>>>> {
>>>>>>> if (disposing && this.Controls != null)
>>>>>>> {
>>>>>>> this.components = new System.ComponentModel.Container();
>>>>>>> foreach (Control o in this.Controls)
>>>>>>> components.Add(o);
>>>>>>> components.Dispose();
>>>>>>> }
>>>>>>> base.Dispose(disposing);
>>>>>>> }
>>>>>>>
>>>>>>> Now, most of the memory is freed but periodically there still remain
>>>>>>> some
>>>>>>> fragments in the memory (>=4KB up to 64KB (?)).
>>>>>>>
>>>>>>> I also noticed that running this application on a desktop pc with
>>>>>>> the "big"
>>>>>>> :NET framework - no memoryloak persists!
>>>>>>>
>>>>>>>
>>>>>>> Has anyone noticed the same behaviour and/or found a solution for
>>>>>>> it?
>>>>>>>
>>>>>>> Does anyone have experience with applications running round the
>>>>>>> clock on
>>>>>>> Windows CE / CF 2.0?
>>>>>>>
>>>>>>> Are there bugs in the gc on compact framework?
>>>>>>>
>>>>>>>
>>>>>>> Thanks for your help, best regards Chris
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>