Hello All, I think I have narrowed a memory leak down to this code. I
am using OpenNETCF.Net Version 2.1.
As you can see, I am really doing nothing in the following code accept
getting the current adapters preferredAccessPoint collection. I plan
on digging into this code this weekend/next week but wanted to throw
it out on the forum in hopes others have a solution. The pattern
appears to be a 200K drop in available virtual every ~ 15 calls to the
function that runs the code below. A perfmon diff shows no
accumulations of objects in managed code. It will run until the exe
eats up all 32MB.

// Add other preferred access points
foreach (AccessPoint accessPoint in
currentAdapter.PreferredAccessPoints)
{
if (!results.ContainsKey
(accessPoint.Name))
{
try
{
results.Add
(accessPoint.Name,null);
}
catch { }
}
}

I did a quick search on this and only found the following from Chris
T. The difference is this guy was using NetCF ver 1.4 and the 2.1
version I am using does not have a reference to ndisAccess and the
class is only 229 lines. it does have a RefreshList function with no
need to close any Handles.
-----------

There is a leak in AccessPointCollection, near line 329 in RefreshList
().
You need to add the following:

FileEx.CloseHandle( ndisAccess );


before leaving that method.

I'm unable to find anything else actually leaking. All of the managed
arrays, I would think, should be getting freed when the garbage
collector
decides that it's time. There's very little, if any, unmanaged memory
allocated when that series of steps is performed, so there isn't a lot
of
room for things to get lost.
-------------

Have you tried anything newer? We're already at version 2.3, and we made a
lot of changes and did a lot of fixes around WiFi in the 2.3 release.


--

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

".net CF'er" <(E-Mail Removed)> wrote in message
news:13a2a82a-8620-475f-8fd6-(E-Mail Removed)...
> Hello All, I think I have narrowed a memory leak down to this code. I
> am using OpenNETCF.Net Version 2.1.
> As you can see, I am really doing nothing in the following code accept
> getting the current adapters preferredAccessPoint collection. I plan
> on digging into this code this weekend/next week but wanted to throw
> it out on the forum in hopes others have a solution. The pattern
> appears to be a 200K drop in available virtual every ~ 15 calls to the
> function that runs the code below. A perfmon diff shows no
> accumulations of objects in managed code. It will run until the exe
> eats up all 32MB.
>
> // Add other preferred access points
> foreach (AccessPoint accessPoint in
> currentAdapter.PreferredAccessPoints)
> {
> if (!results.ContainsKey
> (accessPoint.Name))
> {
> try
> {
> results.Add
> (accessPoint.Name,null);
> }
> catch { }
> }
> }
>
> I did a quick search on this and only found the following from Chris
> T. The difference is this guy was using NetCF ver 1.4 and the 2.1
> version I am using does not have a reference to ndisAccess and the
> class is only 229 lines. it does have a RefreshList function with no
> need to close any Handles.
> -----------
>
> There is a leak in AccessPointCollection, near line 329 in RefreshList
> ().
> You need to add the following:
>
> FileEx.CloseHandle( ndisAccess );
>
>
> before leaving that method.
>
> I'm unable to find anything else actually leaking. All of the managed
> arrays, I would think, should be getting freed when the garbage
> collector
> decides that it's time. There's very little, if any, unmanaged memory
> allocated when that series of steps is performed, so there isn't a lot
> of
> room for things to get lost.
> -------------
>
>
>
>

On Jul 11, 10:48*pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
wrote:
> Have you tried anything newer? *We're already at version 2.3, and we made a
> lot of changes and did a lot of fixes around WiFi in the 2.3 release.
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded communityhttp://community.OpenNETCF.com
>
> ".net CF'er" <jderu...@gmail.com> wrote in message
>
> news:13a2a82a-8620-475f-8fd6-(E-Mail Removed)...
>
>
>
> > Hello All, I think I have narrowed a memory leak down to this code. I
> > am using OpenNETCF.Net Version 2.1.
> > As you can see, I am really doing nothing in the following code accept
> > getting the current adapters preferredAccessPoint collection. I plan
> > on digging into this code this weekend/next week but wanted to throw
> > it out on the forum in hopes others have a solution. The pattern
> > appears to be a 200K drop in available virtual every ~ 15 calls to the
> > function that runs the code below. A perfmon diff shows no
> > accumulations of objects in managed code. It will run until the exe
> > eats up all 32MB.
>
> > * * * * * * * * * * * * * *// Add other preferred access points
> > * * * * * * * * * * * * * *foreach (AccessPoint accessPoint in
> > currentAdapter.PreferredAccessPoints)
> > * * * * * * * * * * * * * *{
> > * * * * * * * * * * * * * * * *if (!results.ContainsKey
> > (accessPoint.Name))
> > * * * * * * * * * * * * * * * *{
> > * * * * * * * * * * * * * * * * * *try
> > * * * * * * * * * * * * * * * * * *{
> > * * * * * * * * * * * * * * * * * ** *results.Add
> > (accessPoint.Name,null);
> > * * * * * * * * * * * * * * * * * *}
> > * * * * * * * * * * * * * * * * * *catch { }
> > * * * * * * * * * * * * * * * *}
> > * * * * * * * * * * * * * *}
>
> > I did a quick search on this and only found the following from Chris
> > T. The difference is this guy was using NetCF ver 1.4 and the 2.1
> > version I am using does not have a reference to ndisAccess and the
> > class is only 229 lines. it does have a RefreshList function with no
> > need to close any Handles.
> > -----------
>
> > There is a leak in AccessPointCollection, near line 329 in RefreshList
> > ().
> > You need to add the following:
>
> > FileEx.CloseHandle( ndisAccess );
>
> > before leaving that method.
>
> > I'm unable to find anything else actually leaking. All of the managed
> > arrays, I would think, should be getting freed when the garbage
> > collector
> > decides that it's time. There's very little, if any, unmanaged memory
> > allocated when that series of steps is performed, so there isn't a lot
> > of
> > room for things to get lost.
> > -------------- Hide quoted text -
>
> - Show quoted text -

Prelim results is that it acts the same between 2.3 and 2.1, still
seems to be dropping in 200K buckets.

I will know more tomorrow.

Are you, by any chance, not disposing of something, an AccessPoint or an
Adapter, when you're done with it? That sounds like a case where a large
structure that one of those classes allocated to get SSID information might
not get thrown away unless you call Dispose(), Close() or something of that
nature, possibly because you are storing things in an array for later use or
something.

Paul T.

".net CF'er" <(E-Mail Removed)> wrote in message
news:0efca325-ad8b-4a59-ad71-(E-Mail Removed)...
On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
wrote:
> Have you tried anything newer? We're already at version 2.3, and we made a
> lot of changes and did a lot of fixes around WiFi in the 2.3 release.
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded communityhttp://community.OpenNETCF.com
>
> ".net CF'er" <jderu...@gmail.com> wrote in message
>
> news:13a2a82a-8620-475f-8fd6-(E-Mail Removed)...
>
>
>
> > Hello All, I think I have narrowed a memory leak down to this code. I
> > am using OpenNETCF.Net Version 2.1.
> > As you can see, I am really doing nothing in the following code accept
> > getting the current adapters preferredAccessPoint collection. I plan
> > on digging into this code this weekend/next week but wanted to throw
> > it out on the forum in hopes others have a solution. The pattern
> > appears to be a 200K drop in available virtual every ~ 15 calls to the
> > function that runs the code below. A perfmon diff shows no
> > accumulations of objects in managed code. It will run until the exe
> > eats up all 32MB.
>
> > // Add other preferred access points
> > foreach (AccessPoint accessPoint in
> > currentAdapter.PreferredAccessPoints)
> > {
> > if (!results.ContainsKey
> > (accessPoint.Name))
> > {
> > try
> > {
> > results.Add
> > (accessPoint.Name,null);
> > }
> > catch { }
> > }
> > }
>
> > I did a quick search on this and only found the following from Chris
> > T. The difference is this guy was using NetCF ver 1.4 and the 2.1
> > version I am using does not have a reference to ndisAccess and the
> > class is only 229 lines. it does have a RefreshList function with no
> > need to close any Handles.
> > -----------
>
> > There is a leak in AccessPointCollection, near line 329 in RefreshList
> > ().
> > You need to add the following:
>
> > FileEx.CloseHandle( ndisAccess );
>
> > before leaving that method.
>
> > I'm unable to find anything else actually leaking. All of the managed
> > arrays, I would think, should be getting freed when the garbage
> > collector
> > decides that it's time. There's very little, if any, unmanaged memory
> > allocated when that series of steps is performed, so there isn't a lot
> > of
> > room for things to get lost.
> > -------------- Hide quoted text -
>
> - Show quoted text -

Prelim results is that it acts the same between 2.3 and 2.1, still
seems to be dropping in 200K buckets.

I will know more tomorrow.

On Jul 15, 4:13*pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
> Are you, by any chance, not disposing of something, an AccessPoint or an
> Adapter, when you're done with it? *That sounds like a case where a large
> structure that one of those classes allocated to get SSID information might
> not get thrown away unless you call Dispose(), Close() or something of that
> nature, possibly because you are storing things in an array for later useor
> something.
>
> Paul T.
>
> ".net CF'er" <jderu...@gmail.com> wrote in message
>
> news:0efca325-ad8b-4a59-ad71-(E-Mail Removed)...
> On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
> wrote:
>
>
>
>
>
> > Have you tried anything newer? We're already at version 2.3, and we made a
> > lot of changes and did a lot of fixes around WiFi in the 2.3 release.
>
> > --
>
> > Chris Tacke, Embedded MVP
> > OpenNETCF Consulting
> > Giving back to the embedded communityhttp://community.OpenNETCF.com
>
> > ".net CF'er" <jderu...@gmail.com> wrote in message
>
> >news:13a2a82a-8620-475f-8fd6-(E-Mail Removed)....
>
> > > Hello All, I think I have narrowed a memory leak down to this code. I
> > > am using OpenNETCF.Net Version 2.1.
> > > As you can see, I am really doing nothing in the following code accept
> > > getting the current adapters preferredAccessPoint collection. I plan
> > > on digging into this code this weekend/next week but wanted to throw
> > > it out on the forum in hopes others have a solution. The pattern
> > > appears to be a 200K drop in available virtual every ~ 15 calls to the
> > > function that runs the code below. A perfmon diff shows no
> > > accumulations of objects in managed code. It will run until the exe
> > > eats up all 32MB.
>
> > > // Add other preferred access points
> > > foreach (AccessPoint accessPoint in
> > > currentAdapter.PreferredAccessPoints)
> > > {
> > > if (!results.ContainsKey
> > > (accessPoint.Name))
> > > {
> > > try
> > > {
> > > results.Add
> > > (accessPoint.Name,null);
> > > }
> > > catch { }
> > > }
> > > }
>
> > > I did a quick search on this and only found the following from Chris
> > > T. The difference is this guy was using NetCF ver 1.4 and the 2.1
> > > version I am using does not have a reference to ndisAccess and the
> > > class is only 229 lines. it does have a RefreshList function with no
> > > need to close any Handles.
> > > -----------
>
> > > There is a leak in AccessPointCollection, near line 329 in RefreshList
> > > ().
> > > You need to add the following:
>
> > > FileEx.CloseHandle( ndisAccess );
>
> > > before leaving that method.
>
> > > I'm unable to find anything else actually leaking. All of the managed
> > > arrays, I would think, should be getting freed when the garbage
> > > collector
> > > decides that it's time. There's very little, if any, unmanaged memory
> > > allocated when that series of steps is performed, so there isn't a lot
> > > of
> > > room for things to get lost.
> > > -------------- Hide quoted text -
>
> > - Show quoted text -
>
> Prelim results is that it acts the same between 2.3 and 2.1, still
> seems to be dropping in 200K buckets.
>
> I will know more tomorrow.- Hide quoted text -
>
> - Show quoted text -

Hello Paul,
I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
NetworkInformation.AccessPoint and do not see a close or dispose
function on any of them.?

OK, it appears to me that there may a missing deallocation for the raw data
portion of the INTF_ENTRY struct in the AccessPointCollection methods for
the allocation near line 173. I think that Chris would have to identify and
apply a fix.

Paul T.

".net CF'er" <(E-Mail Removed)> wrote in message
news:90f24a41-b8b0-4ee9-8080-(E-Mail Removed)...
On Jul 15, 4:13 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
> Are you, by any chance, not disposing of something, an AccessPoint or an
> Adapter, when you're done with it? That sounds like a case where a large
> structure that one of those classes allocated to get SSID information
> might
> not get thrown away unless you call Dispose(), Close() or something of
> that
> nature, possibly because you are storing things in an array for later use
> or
> something.
>
> Paul T.
>
> ".net CF'er" <jderu...@gmail.com> wrote in message
>
> news:0efca325-ad8b-4a59-ad71-(E-Mail Removed)...
> On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
> wrote:
>
>
>
>
>
> > Have you tried anything newer? We're already at version 2.3, and we made
> > a
> > lot of changes and did a lot of fixes around WiFi in the 2.3 release.
>
> > --
>
> > Chris Tacke, Embedded MVP
> > OpenNETCF Consulting
> > Giving back to the embedded communityhttp://community.OpenNETCF.com
>
> > ".net CF'er" <jderu...@gmail.com> wrote in message
>
> >news:13a2a82a-8620-475f-8fd6-(E-Mail Removed)...
>
> > > Hello All, I think I have narrowed a memory leak down to this code. I
> > > am using OpenNETCF.Net Version 2.1.
> > > As you can see, I am really doing nothing in the following code accept
> > > getting the current adapters preferredAccessPoint collection. I plan
> > > on digging into this code this weekend/next week but wanted to throw
> > > it out on the forum in hopes others have a solution. The pattern
> > > appears to be a 200K drop in available virtual every ~ 15 calls to the
> > > function that runs the code below. A perfmon diff shows no
> > > accumulations of objects in managed code. It will run until the exe
> > > eats up all 32MB.
>
> > > // Add other preferred access points
> > > foreach (AccessPoint accessPoint in
> > > currentAdapter.PreferredAccessPoints)
> > > {
> > > if (!results.ContainsKey
> > > (accessPoint.Name))
> > > {
> > > try
> > > {
> > > results.Add
> > > (accessPoint.Name,null);
> > > }
> > > catch { }
> > > }
> > > }
>
> > > I did a quick search on this and only found the following from Chris
> > > T. The difference is this guy was using NetCF ver 1.4 and the 2.1
> > > version I am using does not have a reference to ndisAccess and the
> > > class is only 229 lines. it does have a RefreshList function with no
> > > need to close any Handles.
> > > -----------
>
> > > There is a leak in AccessPointCollection, near line 329 in RefreshList
> > > ().
> > > You need to add the following:
>
> > > FileEx.CloseHandle( ndisAccess );
>
> > > before leaving that method.
>
> > > I'm unable to find anything else actually leaking. All of the managed
> > > arrays, I would think, should be getting freed when the garbage
> > > collector
> > > decides that it's time. There's very little, if any, unmanaged memory
> > > allocated when that series of steps is performed, so there isn't a lot
> > > of
> > > room for things to get lost.
> > > -------------- Hide quoted text -
>
> > - Show quoted text -
>
> Prelim results is that it acts the same between 2.3 and 2.1, still
> seems to be dropping in 200K buckets.
>
> I will know more tomorrow.- Hide quoted text -
>
> - Show quoted text -

Hello Paul,
I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
NetworkInformation.AccessPoint and do not see a close or dispose
function on any of them.?

And, unfortunately, I'm leaving on vacation in an hour, so the earliest it's
going to happen on my end would be August.


--

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


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%(E-Mail Removed)...
> OK, it appears to me that there may a missing deallocation for the raw
> data portion of the INTF_ENTRY struct in the AccessPointCollection methods
> for the allocation near line 173. I think that Chris would have to
> identify and apply a fix.
>
> Paul T.
>
> ".net CF'er" <(E-Mail Removed)> wrote in message
> news:90f24a41-b8b0-4ee9-8080-(E-Mail Removed)...
> On Jul 15, 4:13 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
> no instrument no spam DOT com> wrote:
>> Are you, by any chance, not disposing of something, an AccessPoint or an
>> Adapter, when you're done with it? That sounds like a case where a large
>> structure that one of those classes allocated to get SSID information
>> might
>> not get thrown away unless you call Dispose(), Close() or something of
>> that
>> nature, possibly because you are storing things in an array for later use
>> or
>> something.
>>
>> Paul T.
>>
>> ".net CF'er" <jderu...@gmail.com> wrote in message
>>
>> news:0efca325-ad8b-4a59-ad71-(E-Mail Removed)...
>> On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
>> wrote:
>>
>>
>>
>>
>>
>> > Have you tried anything newer? We're already at version 2.3, and we
>> > made a
>> > lot of changes and did a lot of fixes around WiFi in the 2.3 release.
>>
>> > --
>>
>> > Chris Tacke, Embedded MVP
>> > OpenNETCF Consulting
>> > Giving back to the embedded communityhttp://community.OpenNETCF.com
>>
>> > ".net CF'er" <jderu...@gmail.com> wrote in message
>>
>> >news:13a2a82a-8620-475f-8fd6-(E-Mail Removed)...
>>
>> > > Hello All, I think I have narrowed a memory leak down to this code. I
>> > > am using OpenNETCF.Net Version 2.1.
>> > > As you can see, I am really doing nothing in the following code
>> > > accept
>> > > getting the current adapters preferredAccessPoint collection. I plan
>> > > on digging into this code this weekend/next week but wanted to throw
>> > > it out on the forum in hopes others have a solution. The pattern
>> > > appears to be a 200K drop in available virtual every ~ 15 calls to
>> > > the
>> > > function that runs the code below. A perfmon diff shows no
>> > > accumulations of objects in managed code. It will run until the exe
>> > > eats up all 32MB.
>>
>> > > // Add other preferred access points
>> > > foreach (AccessPoint accessPoint in
>> > > currentAdapter.PreferredAccessPoints)
>> > > {
>> > > if (!results.ContainsKey
>> > > (accessPoint.Name))
>> > > {
>> > > try
>> > > {
>> > > results.Add
>> > > (accessPoint.Name,null);
>> > > }
>> > > catch { }
>> > > }
>> > > }
>>
>> > > I did a quick search on this and only found the following from Chris
>> > > T. The difference is this guy was using NetCF ver 1.4 and the 2.1
>> > > version I am using does not have a reference to ndisAccess and the
>> > > class is only 229 lines. it does have a RefreshList function with no
>> > > need to close any Handles.
>> > > -----------
>>
>> > > There is a leak in AccessPointCollection, near line 329 in
>> > > RefreshList
>> > > ().
>> > > You need to add the following:
>>
>> > > FileEx.CloseHandle( ndisAccess );
>>
>> > > before leaving that method.
>>
>> > > I'm unable to find anything else actually leaking. All of the managed
>> > > arrays, I would think, should be getting freed when the garbage
>> > > collector
>> > > decides that it's time. There's very little, if any, unmanaged memory
>> > > allocated when that series of steps is performed, so there isn't a
>> > > lot
>> > > of
>> > > room for things to get lost.
>> > > -------------- Hide quoted text -
>>
>> > - Show quoted text -
>>
>> Prelim results is that it acts the same between 2.3 and 2.1, still
>> seems to be dropping in 200K buckets.
>>
>> I will know more tomorrow.- Hide quoted text -
>>
>> - Show quoted text -
>
> Hello Paul,
> I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
> NetworkInformation.AccessPoint and do not see a close or dispose
> function on any of them.?
>

Hmmm. Well, I'll try to take a look at it and at least suggest a fix for
the interim in the field. If .net CFer has the code, that should allow
things to be fixed for now, at least.

Enjoy the vacation!
Paul T.

"Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com> wrote in message
news:AF105300-FBF2-448A-908A-(E-Mail Removed)...
> And, unfortunately, I'm leaving on vacation in an hour, so the earliest
> it's going to happen on my end would be August.
>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded community
> http://community.OpenNETCF.com
>
>
> "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
> com> wrote in message news:%(E-Mail Removed)...
>> OK, it appears to me that there may a missing deallocation for the raw
>> data portion of the INTF_ENTRY struct in the AccessPointCollection
>> methods for the allocation near line 173. I think that Chris would have
>> to identify and apply a fix.
>>
>> Paul T.
>>
>> ".net CF'er" <(E-Mail Removed)> wrote in message
>> news:90f24a41-b8b0-4ee9-8080-(E-Mail Removed)...
>> On Jul 15, 4:13 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
>> no instrument no spam DOT com> wrote:
>>> Are you, by any chance, not disposing of something, an AccessPoint or an
>>> Adapter, when you're done with it? That sounds like a case where a large
>>> structure that one of those classes allocated to get SSID information
>>> might
>>> not get thrown away unless you call Dispose(), Close() or something of
>>> that
>>> nature, possibly because you are storing things in an array for later
>>> use or
>>> something.
>>>
>>> Paul T.
>>>
>>> ".net CF'er" <jderu...@gmail.com> wrote in message
>>>
>>> news:0efca325-ad8b-4a59-ad71-(E-Mail Removed)...
>>> On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> > Have you tried anything newer? We're already at version 2.3, and we
>>> > made a
>>> > lot of changes and did a lot of fixes around WiFi in the 2.3 release.
>>>
>>> > --
>>>
>>> > Chris Tacke, Embedded MVP
>>> > OpenNETCF Consulting
>>> > Giving back to the embedded communityhttp://community.OpenNETCF.com
>>>
>>> > ".net CF'er" <jderu...@gmail.com> wrote in message
>>>
>>> >news:13a2a82a-8620-475f-8fd6-(E-Mail Removed)...
>>>
>>> > > Hello All, I think I have narrowed a memory leak down to this code.
>>> > > I
>>> > > am using OpenNETCF.Net Version 2.1.
>>> > > As you can see, I am really doing nothing in the following code
>>> > > accept
>>> > > getting the current adapters preferredAccessPoint collection. I plan
>>> > > on digging into this code this weekend/next week but wanted to throw
>>> > > it out on the forum in hopes others have a solution. The pattern
>>> > > appears to be a 200K drop in available virtual every ~ 15 calls to
>>> > > the
>>> > > function that runs the code below. A perfmon diff shows no
>>> > > accumulations of objects in managed code. It will run until the exe
>>> > > eats up all 32MB.
>>>
>>> > > // Add other preferred access points
>>> > > foreach (AccessPoint accessPoint in
>>> > > currentAdapter.PreferredAccessPoints)
>>> > > {
>>> > > if (!results.ContainsKey
>>> > > (accessPoint.Name))
>>> > > {
>>> > > try
>>> > > {
>>> > > results.Add
>>> > > (accessPoint.Name,null);
>>> > > }
>>> > > catch { }
>>> > > }
>>> > > }
>>>
>>> > > I did a quick search on this and only found the following from Chris
>>> > > T. The difference is this guy was using NetCF ver 1.4 and the 2.1
>>> > > version I am using does not have a reference to ndisAccess and the
>>> > > class is only 229 lines. it does have a RefreshList function with no
>>> > > need to close any Handles.
>>> > > -----------
>>>
>>> > > There is a leak in AccessPointCollection, near line 329 in
>>> > > RefreshList
>>> > > ().
>>> > > You need to add the following:
>>>
>>> > > FileEx.CloseHandle( ndisAccess );
>>>
>>> > > before leaving that method.
>>>
>>> > > I'm unable to find anything else actually leaking. All of the
>>> > > managed
>>> > > arrays, I would think, should be getting freed when the garbage
>>> > > collector
>>> > > decides that it's time. There's very little, if any, unmanaged
>>> > > memory
>>> > > allocated when that series of steps is performed, so there isn't a
>>> > > lot
>>> > > of
>>> > > room for things to get lost.
>>> > > -------------- Hide quoted text -
>>>
>>> > - Show quoted text -
>>>
>>> Prelim results is that it acts the same between 2.3 and 2.1, still
>>> seems to be dropping in 200K buckets.
>>>
>>> I will know more tomorrow.- Hide quoted text -
>>>
>>> - Show quoted text -
>>
>> Hello Paul,
>> I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
>> NetworkInformation.AccessPoint and do not see a close or dispose
>> function on any of them.?
>>
>

There are actually a few places where INTF_ENTRY structures are allocated
but not Dispose-ed. I'll give a list and you can try to find them and fix
them:

1. NetworkInformation.AccessPointCollection near line 234 there should be a
call to ie.Dispose().

2. NetworkInformation.WirelessZeroConfigNetworkInterface near line 102, in
the if ( retVal > 0 ) case, entry.Dispose() needs to be called, as it is in
the other case.

3. NetworkInformation.WirelessZeroConfigNetworkInterface near line 117, in
the if (WZC.QueryAdapter(this.Name, out entry) == 0) case, there are
actually two bugs. You need to add a line like this:

// PGT: Need to check the state of the flag to determine
// what to return.
bool ret = ((entry.dwCtlFlags & (uint)INTF_FLAGS.INTF_FALLBACK) != 0);

followed by one like this:

// PGT: Need to free it!
entry.Dispose();

That's what I've spotted so far. The rest of the INTF_ENTRY uses, at least,
seem to be handled correctly. I'm leaving a little program running for a
while to see if there are any other obvious leaks.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:%(E-Mail Removed)...
> Hmmm. Well, I'll try to take a look at it and at least suggest a fix for
> the interim in the field. If .net CFer has the code, that should allow
> things to be fixed for now, at least.
>
> Enjoy the vacation!
> Paul T.
>
> "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com> wrote in message
> news:AF105300-FBF2-448A-908A-(E-Mail Removed)...
>> And, unfortunately, I'm leaving on vacation in an hour, so the earliest
>> it's going to happen on my end would be August.
>>
>>
>> --
>>
>> Chris Tacke, Embedded MVP
>> OpenNETCF Consulting
>> Giving back to the embedded community
>> http://community.OpenNETCF.com
>>
>>
>> "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
>> DOT com> wrote in message news:%(E-Mail Removed)...
>>> OK, it appears to me that there may a missing deallocation for the raw
>>> data portion of the INTF_ENTRY struct in the AccessPointCollection
>>> methods for the allocation near line 173. I think that Chris would have
>>> to identify and apply a fix.
>>>
>>> Paul T.
>>>
>>> ".net CF'er" <(E-Mail Removed)> wrote in message
>>> news:90f24a41-b8b0-4ee9-8080-(E-Mail Removed)...
>>> On Jul 15, 4:13 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
>>> no instrument no spam DOT com> wrote:
>>>> Are you, by any chance, not disposing of something, an AccessPoint or
>>>> an
>>>> Adapter, when you're done with it? That sounds like a case where a
>>>> large
>>>> structure that one of those classes allocated to get SSID information
>>>> might
>>>> not get thrown away unless you call Dispose(), Close() or something of
>>>> that
>>>> nature, possibly because you are storing things in an array for later
>>>> use or
>>>> something.
>>>>
>>>> Paul T.
>>>>
>>>> ".net CF'er" <jderu...@gmail.com> wrote in message
>>>>
>>>> news:0efca325-ad8b-4a59-ad71-(E-Mail Removed)...
>>>> On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> > Have you tried anything newer? We're already at version 2.3, and we
>>>> > made a
>>>> > lot of changes and did a lot of fixes around WiFi in the 2.3 release.
>>>>
>>>> > --
>>>>
>>>> > Chris Tacke, Embedded MVP
>>>> > OpenNETCF Consulting
>>>> > Giving back to the embedded communityhttp://community.OpenNETCF.com
>>>>
>>>> > ".net CF'er" <jderu...@gmail.com> wrote in message
>>>>
>>>> >news:13a2a82a-8620-475f-8fd6-(E-Mail Removed)...
>>>>
>>>> > > Hello All, I think I have narrowed a memory leak down to this code.
>>>> > > I
>>>> > > am using OpenNETCF.Net Version 2.1.
>>>> > > As you can see, I am really doing nothing in the following code
>>>> > > accept
>>>> > > getting the current adapters preferredAccessPoint collection. I
>>>> > > plan
>>>> > > on digging into this code this weekend/next week but wanted to
>>>> > > throw
>>>> > > it out on the forum in hopes others have a solution. The pattern
>>>> > > appears to be a 200K drop in available virtual every ~ 15 calls to
>>>> > > the
>>>> > > function that runs the code below. A perfmon diff shows no
>>>> > > accumulations of objects in managed code. It will run until the exe
>>>> > > eats up all 32MB.
>>>>
>>>> > > // Add other preferred access points
>>>> > > foreach (AccessPoint accessPoint in
>>>> > > currentAdapter.PreferredAccessPoints)
>>>> > > {
>>>> > > if (!results.ContainsKey
>>>> > > (accessPoint.Name))
>>>> > > {
>>>> > > try
>>>> > > {
>>>> > > results.Add
>>>> > > (accessPoint.Name,null);
>>>> > > }
>>>> > > catch { }
>>>> > > }
>>>> > > }
>>>>
>>>> > > I did a quick search on this and only found the following from
>>>> > > Chris
>>>> > > T. The difference is this guy was using NetCF ver 1.4 and the 2.1
>>>> > > version I am using does not have a reference to ndisAccess and the
>>>> > > class is only 229 lines. it does have a RefreshList function with
>>>> > > no
>>>> > > need to close any Handles.
>>>> > > -----------
>>>>
>>>> > > There is a leak in AccessPointCollection, near line 329 in
>>>> > > RefreshList
>>>> > > ().
>>>> > > You need to add the following:
>>>>
>>>> > > FileEx.CloseHandle( ndisAccess );
>>>>
>>>> > > before leaving that method.
>>>>
>>>> > > I'm unable to find anything else actually leaking. All of the
>>>> > > managed
>>>> > > arrays, I would think, should be getting freed when the garbage
>>>> > > collector
>>>> > > decides that it's time. There's very little, if any, unmanaged
>>>> > > memory
>>>> > > allocated when that series of steps is performed, so there isn't a
>>>> > > lot
>>>> > > of
>>>> > > room for things to get lost.
>>>> > > -------------- Hide quoted text -
>>>>
>>>> > - Show quoted text -
>>>>
>>>> Prelim results is that it acts the same between 2.3 and 2.1, still
>>>> seems to be dropping in 200K buckets.
>>>>
>>>> I will know more tomorrow.- Hide quoted text -
>>>>
>>>> - Show quoted text -
>>>
>>> Hello Paul,
>>> I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
>>> NetworkInformation.AccessPoint and do not see a close or dispose
>>> function on any of them.?
>>>
>>
>
>

On Jul 16, 11:23*am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
> Hmmm. *Well, I'll try to take a look at it and at least suggest a fix for
> the interim in the field. *If .net CFer has the code, that should allow
> things to be fixed for now, at least.
>
> Enjoy the vacation!
> Paul T.
>
> "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com> wrote in messagenews:AF105300-FBF2-448A-908A-(E-Mail Removed)...
>
>
>
> > And, unfortunately, I'm leaving on vacation in an hour, so the earliest
> > it's going to happen on my end would be August.
>
> > --
>
> > Chris Tacke, Embedded MVP
> > OpenNETCF Consulting
> > Giving back to the embedded community
> >http://community.OpenNETCF.com
>
> > "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
> > com> wrote in messagenews:%(E-Mail Removed)...
> >> OK, it appears to me that there may a missing deallocation for the raw
> >> data portion of the INTF_ENTRY struct in the AccessPointCollection
> >> methods for the allocation near line 173. *I think that Chris would have
> >> to identify and apply a fix.
>
> >> Paul T.
>
> >> ".net CF'er" <jderu...@gmail.com> wrote in message
> >>news:90f24a41-b8b0-4ee9-8080-(E-Mail Removed)....
> >> On Jul 15, 4:13 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
> >> no instrument no spam DOT com> wrote:
> >>> Are you, by any chance, not disposing of something, an AccessPoint oran
> >>> Adapter, when you're done with it? That sounds like a case where a large
> >>> structure that one of those classes allocated to get SSID information
> >>> might
> >>> not get thrown away unless you call Dispose(), Close() or something of
> >>> that
> >>> nature, possibly because you are storing things in an array for later
> >>> use or
> >>> something.
>
> >>> Paul T.
>
> >>> ".net CF'er" <jderu...@gmail.com> wrote in message
>
> >>>news:0efca325-ad8b-4a59-ad71-(E-Mail Removed)....
> >>> On Jul 11, 10:48 pm, "Chris Tacke, MVP" <ctacke.at.opennetcf.dot.com>
> >>> wrote:
>
> >>> > Have you tried anything newer? We're already at version 2.3, and we
> >>> > made a
> >>> > lot of changes and did a lot of fixes around WiFi in the 2.3 release.
>
> >>> > --
>
> >>> > Chris Tacke, Embedded MVP
> >>> > OpenNETCF Consulting
> >>> > Giving back to the embedded communityhttp://community.OpenNETCF.com
>
> >>> > ".net CF'er" <jderu...@gmail.com> wrote in message
>
> >>> >news:13a2a82a-8620-475f-8fd6-(E-Mail Removed)...
>
> >>> > > Hello All, I think I have narrowed a memory leak down to this code.
> >>> > > I
> >>> > > am using OpenNETCF.Net Version 2.1.
> >>> > > As you can see, I am really doing nothing in the following code
> >>> > > accept
> >>> > > getting the current adapters preferredAccessPoint collection. I plan
> >>> > > on digging into this code this weekend/next week but wanted to throw
> >>> > > it out on the forum in hopes others have a solution. The pattern
> >>> > > appears to be a 200K drop in available virtual every ~ 15 calls to
> >>> > > the
> >>> > > function that runs the code below. A perfmon diff shows no
> >>> > > accumulations of objects in managed code. It will run until the exe
> >>> > > eats up all 32MB.
>
> >>> > > // Add other preferred access points
> >>> > > foreach (AccessPoint accessPoint in
> >>> > > currentAdapter.PreferredAccessPoints)
> >>> > > {
> >>> > > if (!results.ContainsKey
> >>> > > (accessPoint.Name))
> >>> > > {
> >>> > > try
> >>> > > {
> >>> > > results.Add
> >>> > > (accessPoint.Name,null);
> >>> > > }
> >>> > > catch { }
> >>> > > }
> >>> > > }
>
> >>> > > I did a quick search on this and only found the following from Chris
> >>> > > T. The difference is this guy was using NetCF ver 1.4 and the 2.1
> >>> > > version I am using does not have a reference to ndisAccess and the
> >>> > > class is only 229 lines. it does have a RefreshList function withno
> >>> > > need to close any Handles.
> >>> > > -----------
>
> >>> > > There is a leak in AccessPointCollection, near line 329 in
> >>> > > RefreshList
> >>> > > ().
> >>> > > You need to add the following:
>
> >>> > > FileEx.CloseHandle( ndisAccess );
>
> >>> > > before leaving that method.
>
> >>> > > I'm unable to find anything else actually leaking. All of the
> >>> > > managed
> >>> > > arrays, I would think, should be getting freed when the garbage
> >>> > > collector
> >>> > > decides that it's time. There's very little, if any, unmanaged
> >>> > > memory
> >>> > > allocated when that series of steps is performed, so there isn't a
> >>> > > lot
> >>> > > of
> >>> > > room for things to get lost.
> >>> > > -------------- Hide quoted text -
>
> >>> > - Show quoted text -
>
> >>> Prelim results is that it acts the same between 2.3 and 2.1, still
> >>> seems to be dropping in 200K buckets.
>
> >>> I will know more tomorrow.- Hide quoted text -
>
> >>> - Show quoted text -
>
> >> Hello Paul,
> >> I am using INetworkInterface, WirelessZeroConfigNetworkInterface, and
> >> NetworkInformation.AccessPoint and do not see a close or dispose
> >> function on any of them.?- Hide quoted text -
>
> - Show quoted text -

It looks like the RAW_DATA struct is not being disposed in all the
places it is being used. Going to look at 2.1.