[wdmaudiodev] Re: pelase help memory issue
- From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Fri, 26 Mar 2004 16:22:47 -0500
I have very little to add so far. Definitely the topology port has an extra
reference to it, which causes a leak when portcls unloads. I'd like to
start by saying that I based my wave and topology (and adapter) on the MSVAD
example in the DDK. So StartDevice, which deals with the obvious points
where I would add or remove references from the topology port is fine (yes I
updated StartDevice and its dependencies from the .NET DDK).
When the destructor to my miniport topology is called in Win2k SP4, there is
a reference of 3 to the port topology. This is 1 more than is logical. My
miniport topology has a reference to the port topology (unlike the MSVAD
example), and portcls has the other reference (verified). However, I cannot
so far account for the third reference. In WinXP SP1, when my miniport
topology destructor is called, there is a reference count of *2* for the
port topology, 1 less than in Win2k SP4. No wonder there is no problem in
WinXP SP1.
Does anyone have a clue why there could be such an extra reference? Could
there be something wrong with my exposed topology which could cause this?
Or could portcls just not be suited for external busses to such a degree
(recall I am enumerated by my "bus driver", which is on the 1394 bus).
Previously, I did not have a MUX. Now I put one in, just as in the MSVAD
example. I make 2 physical connections between the port topology and the
waveport topology, just as in the MSVAD example. It still did not help.
Any other suggestions?
thanks in advance,
Philip Lukidis
----- Original Message -----
From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
To: <wdmaudiodev@xxxxxxxxxxxxx>
Sent: Friday, March 26, 2004 8:52 AM
Subject: Re: [wdmaudiodev] Re: pelase help memory issue
> OK Frank, I now follow what you meant. Further investigation reveals that
> you are correct, it is a reference count problem. The topology port has
an
> extra reference count to it, and when I step through the release member it
> is not being deleted due to this extra reference (hence all the leaks).
>
> I will post more details shortly. I'm still baffled why this should occur
> on Win2k SP4 and not on WinXP SP1, but maybe it will become clearer
shortly.
>
> Thanks for pointing me in the right direction,
>
> Philip Lukidis
>
> ----- Original Message -----
> From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
> To: <wdmaudiodev@xxxxxxxxxxxxx>
> Sent: Wednesday, March 24, 2004 3:10 PM
> Subject: Re: [wdmaudiodev] Re: pelase help memory issue
>
>
> > Hi Frank, thanks for answering. Right now I'm working on something even
> > more urgent (hard to believe), but when I have some time I will follow
you
> > advice, and post the results.
> >
> > But, off the top of my head, why would portcls unload at all if there
was
> a
> > reference problem in one of my filters (the device object is shared)?
> > Wouldn't it stay loaded? I'm sure I'm missing something somewhere in
what
> > you said. In any case, when I get back on this I'll keep it in mind.
Any
> > thoughts on why one of my filters may stay loaded? Could it be because
I
> am
> > using portcls for an external bus (1394)? And why only on Win2k and not
> > WinXP?
> >
> > thanks for your answer,
> >
> > Philip Lukidis
> >
> > ----- Original Message -----
> > From: "Frank Berreth" <fberreth@xxxxxxxxxxxxx>
> > To: <wdmaudiodev@xxxxxxxxxxxxx>
> > Sent: Tuesday, March 23, 2004 2:33 PM
> > Subject: [wdmaudiodev] Re: pelase help memory issue
> >
> >
> > > You probably have a reference count problem. For example, assume your
> > > topology filter doesn't go away because it was not properly cleaned
up.
> > > A lot of the objects listed below might all belong to this port. The
> > > best thing is to dds some of the leaking objects to find WHAT is
> > > leaking. The tag doesn't help you that much here.
> > >
> > > -----Original Message-----
> > > From: wdmaudiodev-bounce@xxxxxxxxxxxxx
> > > [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Philip Lukidis
> > > Sent: Monday, March 15, 2004 8:34 AM
> > > To: wdmaudiodev@xxxxxxxxxxxxx
> > > Subject: [wdmaudiodev] Re: pelase help memory issue
> > >
> > > OK, I finally narrowed it down somewhat. This only happens if I call
> > > PcRegisterPhysicalConnection between my waveout pin and my topology in
> > > pin.
> > > Note that for now I don't expose a MUX or record controls in my
> > > topology,
> > > even though I have record capability (through ASIO). So I only call
> > > PcRegisterPhysicalConnection once for now. Note also that I have no
> > > problems under WinXP SP1.
> > >
> > > If anyone has any further thoughts on this, I'd be interested. Thanks
> > > in
> > > advance,
> > >
> > > Philip Lukidis
> > >
> > > ----- Original Message -----
> > > From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
> > > To: <wdmaudiodev@xxxxxxxxxxxxx>
> > > Sent: Friday, March 12, 2004 5:38 PM
> > > Subject: Re: pelase help memory issue
> > >
> > >
> > > > Has anyone seen a faulty topology causing this before? I'm
reviewing
> > > my
> > > > topology but so far I don't see anything wrong. Thanks in advance,
> > > >
> > > > Philip Lukidis
> > > >
> > > > ----- Original Message -----
> > > > From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
> > > > To: <wdmaudiodev@xxxxxxxxxxxxx>
> > > > Sent: Friday, March 12, 2004 3:43 PM
> > > > Subject: pelase help memory issue
> > > >
> > > >
> > > > > Hello. On Win2k SP4, I have several memory leaks in portcls.sys
> > > when
> > > > > verified with driver verifier (it seems to be mny fault, see
below).
> > > I
> > > > have
> > > > > a portcls based audio and MIDI drivers which reside above a 1394
> > > "bus
> > > > > driver".
> > > > > I have both wave and MIDI drivers, but it seems related to wave as
> > > it
> > > also
> > > > > occurs when I disable the MIDI drivers. I'm pretty sure it's my
> > > fault,
> > > as
> > > > I
> > > > > have tested with other audio products and I have not seen this.
> > > Althought
> > > > I
> > > > > am not 100% sure, it seems that I *don't* need to stream audio for
> > > these
> > > > > leaks to happen. Any thoughts on what this may be related to?
For
> > > > example,
> > > > > it seems that KsoO is allocated in portcls!xDispatchCreate. Yet
> > > what
> > > > > control over this do I have? I do NOT override any PnP IRPs of
> > > portcls.
> > > > > Any ideas? Thanks in advance.
> > > > >
> > > > > Here is a dump from "!verifier 3 portcls.sys":
> > > > >
> > > > > Driver Verification List
> > > > >
> > > > > portcls.sys (820daf88) NonPagedPool=234, PagedPool=b10: loaded
> > > > > Paged Pool Usage Peak : 0x00000069 allocations 0x00003db8
bytes
> > > > > Paged Pool Usage Current : 0x00000015 allocations 0x00000b10
bytes
> > > > > NonPaged Pool Usage Peak : 0x000000b0 allocations 0x0000948c
bytes
> > > > > NonPaged Pool Usage Current: 0x0000000c allocations 0x00000234
bytes
> > > > > PoolAddress SizeInBytes Tag CallersAddress
> > > > > A5FC3F88 0x00000074 PcCr F769908B
> > > > > A5FC7DE8 0x00000218 PcFp F7697DE9
> > > > > A5FDFF60 0x000000a0 PcSi F76981AA
> > > > > A5FDBFC0 0x0000003c PcSt F7697F02
> > > > > A5FF3FE8 0x00000014 PcSt F7697F02
> > > > > A5FDDFF8 0x00000004 PcSb F7697F19
> > > > > A5FF7F60 0x000000a0 PcSi F76981AA
> > > > > A5FF5FF8 0x00000004 PcSb F7697F19
> > > > > A602BF88 0x00000074 PcCr F769908B
> > > > > A602FDE8 0x00000218 PcFp F7697DE9
> > > > > A6047F60 0x000000a0 PcSi F76981AA
> > > > > A6043FC0 0x0000003c PcSt F7697F02
> > > > > A605BFE8 0x00000014 PcSt F7697F02
> > > > > A6045FF8 0x00000004 PcSb F7697F19
> > > > > A605FF60 0x000000a0 PcSi F76981AA
> > > > > A605DFF8 0x00000004 PcSb F7697F19
> > > > > A6087F88 0x00000074 PcCr F769908B
> > > > > A608BDE8 0x00000218 PcFp F7697DE9
> > > > > A60A3F60 0x000000a0 PcSi F76981AA
> > > > > A609FFC0 0x0000003c PcSt F7697F02
> > > > > A60B7FE8 0x00000014 PcSt F7697F02
> > > > > A60A1FF8 0x00000004 PcSb F7697F19
> > > > > A60BBF60 0x000000a0 PcSi F76981AA
> > > > > A60B9FF8 0x00000004 PcSb F7697F19
> > > > > AD0F1FF0 0x0000000c KsoO F7699D73
> > > > > AD0F3FD0 0x00000030 PcCr F7697014
> > > > > AD0F5FF0 0x0000000c PcIc F76970BB
> > > > > AD38BFF0 0x0000000c KsoO F7699D73
> > > > > AD38DFD0 0x00000030 PcCr F7697014
> > > > > AD38FFF0 0x0000000c PcIc F76970BB
> > > > > AD625FF0 0x0000000c KsoO F7699D73
> > > > > AD627FD0 0x00000030 PcCr F7697014
> > > > > AD629FF0 0x0000000c PcIc F76970BB
> > > > >
> > > > >
> > > > >
> > > >
> > > ******************
> > >
> > > WDMAUDIODEV addresses:
> > > Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
> > > Subscribe:
mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
> > > Unsubscribe:
> > > mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
> > > Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
> > >
> > > URL to WDMAUDIODEV page:
> > > http://www.wdmaudiodev.de/
> > >
> > > ******************
> > >
> > > WDMAUDIODEV addresses:
> > > Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
> > > Subscribe:
mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
> > > Unsubscribe:
> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
> > > Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
> > >
> > > URL to WDMAUDIODEV page:
> > > http://www.wdmaudiodev.de/
> > >
> > >
> >
>
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.de/
Other related posts:
