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/