[wdmaudiodev] Re: pelase help memory issue
- From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Mon, 29 Mar 2004 12:11:26 -0500
Well, this is a surprise removal issue it seems (perhaps in portcls?). When
I disable my bus driver in the device manager, I don't get the leak in
portcls.
Possible moral of the story (unless someone has another take, please post it
if you do): don't use portcls for external bus like USB or 1394. I checked
under the
avstream section in the DDK, and it says "The preferred driver model for
audio-only drivers is the Microsoft-provided audio port-class driver. Audio
vendors write minidrivers under this class driver model.". What this
perhaps (please someone verify what I am concluding) neglects to mention
here is that surprise removal is not supported at all under portcls (to the
point that pool is leaked), and that avstream is the way to go for audio
devices on external busses.
thanks,
Philip Lukidis
----- Original Message -----
From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
To: <wdmaudiodev@xxxxxxxxxxxxx>
Sent: Monday, March 29, 2004 10:06 AM
Subject: Re: [wdmaudiodev] Re: pelase help memory issue
> Well...I just wish I did this earlier. I just compiled the MSVAD pcmex
> example from the latest DDK (.NET 3790), and guess what. I just power on,
> power off my device, and I get the same memory leak in portcls (BugCheck
C4,
> {60, 910, c8, b} Probably caused by : portcls.sys) as I did when I used my
> own wave driver based on MSVAD. My driver verifier settings were pool
> tracking and special pool. I am on Win2k SP4 (all critical updates), on a
> dual CPU machine.
>
> For this test run, I made no source code changes whatsoever in the MSVAD
> pcmex sample. I did not attempt to play audio. I just powered on and
> powered off, and got the bugcheck. As a reminder, this is a 1394 device,
> and my wave driver is enumerated by my own "bus driver".
>
> Any comments or suggestions? Could this be in part due to the way an IRP
is
> handled by my bus driver? For example, IRP_MN_QUERY_CAPABILITIES? In
this
> case my own "bus driver" hands this down to the real 1394 bus driver for
> filling up (as in Walter Oney's example of delegating to the bus driver).
>
> thanks for any help,
>
> Philip Lukidis
>
> PS:
>
> I had to modify makefile in the project so it would even compile in the
> Win2k environment:
>
> IF DEFINED(_NT_TARGET_VERSION)
> ! IF $(_NT_TARGET_VERSION)>=0x501
> <-----------------------------------CHANGED to 0x500
> ! INCLUDE $(NTMAKEENV)\makefile.def
> ! ELSE
> # Only warn once per directory
> ! INCLUDE $(NTMAKEENV)\makefile.plt
> ! IF "$(BUILD_PASS)"=="PASS1"
> ! message BUILDMSG: Warning : The sample "$(MAKEDIR)" is not valid
for
> the current OS target.
> ! ENDIF
> ! ENDIF
> !ELSE
> ! INCLUDE $(NTMAKEENV)\makefile.def
> !ENDIF
>
> ----- Original Message -----
> From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
> To: <wdmaudiodev@xxxxxxxxxxxxx>
> Sent: Friday, March 26, 2004 4:22 PM
> Subject: Re: [wdmaudiodev] Re: pelase help memory issue
>
>
> > 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:
