## [wdmaudiodev] Re: pelase help memory issue

• From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
• To: <wdmaudiodev@xxxxxxxxxxxxx>
• Date: Mon, 29 Mar 2004 10:06:39 -0500

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
> 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?
>
>
> 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?
> > >
> > >
> > > 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
> > > >
> > > > 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
> > > > >
> > > > > 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
> > > > > > 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/
> > > >
> > > >
> > >
> >
>
******************