"Vepp" tag hunt - assistance requested

In a test scenario I’m running on an amd64 box I observe a leak of
around 220MB/day of non-paged pool for the tag Vepp (so it would show up
in code as ‘ppeV’.) If there is some kind reader out there who might
have knowledge of this tag, please let me know (privately or in the
forum). If I don’t hear from anyone, rest assured that when I do find
it, I’ll publish my findings.

Indeed, this might make a good article for The NT Insider - “how to find
a pool leak”. Fortunately (for me) my own tags are now all down in the
noise. I need to find this leak because it limits the amount of time I
can run my tests (I hit around 24 hours and then get some nice “low
memory usage” simulations. Last time I crashed it was after 600+
non-paged pool allocations had failed… :wink: )

Here is the machine’s loaded module list:

start end module name

fffff80000800000 fffff8000085e000 hal (deferred)

fffff80001000000 fffff8000146e000 nt (pdb symbols)

fffff97fff000000 fffff97fff45d000 win32k (deferred)

fffff97fff45d000 fffff97fff484000 dxg (deferred)

fffff97fff484000 fffff97fffa0a400 nv4_disp (deferred)

fffffadfc46b6000 fffffadfc4780000 srv (deferred)

fffffadfc4852000 fffffadfc48e2000 HTTP (deferred)

fffffadfc4928000 fffffadfc4950000 vmx86 (deferred)

fffffadfc4950000 fffffadfc4999000 mrxdav (deferred)

fffffadfc4c73000 fffffadfc4cab000 kmixer (deferred)

fffffadfc4cab000 fffffadfc4cc5000 swmidi (deferred)

fffffadfc4cc5000 fffffadfc4cfa000 aec (deferred)

fffffadfc4cfa000 fffffadfc4d25000 sysaudio (deferred)

fffffadfc4d25000 fffffadfc4d59000 wdmaud (deferred)

fffffadfc61a1000 fffffadfc61ad000 hcmon (deferred)

fffffadfc6cd8000 fffffadfc6d02000 dump_nvata64 (deferred)

fffffadfc6d02000 fffffadfc6d23000 Cdfs (deferred)

fffffadfc6d69000 fffffadfc6e35000 mrxsmb (deferred)

fffffadfc6e35000 fffffadfc6e86000 rdbss (deferred)

fffffadfc6e86000 fffffadfc6ed4000 afd (deferred)

fffffadfc6ed4000 fffffadfc6f37000 netbt (deferred)

fffffadfc6f37000 fffffadfc6f6f000 ipnat (deferred)

fffffadfc6f6f000 fffffadfc7030000 tcpip (deferred)

fffffadfc7030000 fffffadfc705b000 ipsec (deferred)

fffffadfc705b000 fffffadfc706f000 Npfs (deferred)

fffffadfc708f000 fffffadfc7098000 dump_WMILIB (deferred)

fffffadfc728d000 fffffadfc72a3a00 nvarm64 (deferred)

fffffadfc72a4000 fffffadfc73b8500 nvmcp64 (deferred)

fffffadfc73b9000 fffffadfc73f9000 portcls (deferred)

fffffadfc73f9000 fffffadfc748c400 nvapu64 (deferred)

fffffadfc748d000 fffffadfc74ad000 usbhub (deferred)

fffffadfc74f3000 fffffadfc7507000 NDProxy (deferred)

fffffadfc7507000 fffffadfc751d000 termdd (deferred)

fffffadfc751d000 fffffadfc7573000 rdpdr (deferred)

fffffadfc7573000 fffffadfc7589000 msgpc (deferred)

fffffadfc7589000 fffffadfc75a9000 psched (deferred)

fffffadfc7619000 fffffadfc7624000 ndisuio (deferred)

fffffadfc7629000 fffffadfc7637000 vmnetbridge (deferred)

fffffadfc7649000 fffffadfc766c000 raspptp (deferred)

fffffadfc766c000 fffffadfc7680000 raspppoe (deferred)

fffffadfc7680000 fffffadfc76ac000 ndiswan (deferred)

fffffadfc76ac000 fffffadfc76d2000 rasl2tp (deferred)

fffffadfc76d2000 fffffadfc76ef000 i8042prt (deferred)

fffffadfc76ef000 fffffadfc7712000 serial (deferred)

fffffadfc7712000 fffffadfc7735000 VIDEOPRT (deferred)

fffffadfc7735000 fffffadfc7ba1f00 nv4_mini (deferred)

fffffadfc7ba2000 fffffadfc7bec000 NVSNPU (deferred)

fffffadfc7bec000 fffffadfc7c48b80 NVNRM (deferred)

fffffadfc7c49000 fffffadfc7c8f000 yk51x64 (deferred)

fffffadfc7cd5000 fffffadfc7ceb000 redbook (deferred)

fffffadfc7ceb000 fffffadfc7d06000 cdrom (deferred)

fffffadfc7d06000 fffffadfc7d1d000 imapi (deferred)

fffffadfc7d1d000 fffffadfc7d66000 ks (deferred)

fffffadfc7d66000 fffffadfc7d7c180 nvax64 (deferred)

fffffadfc7d7d000 fffffadfc7db7000 USBPORT (deferred)

fffffadfc7e97000 fffffadfc7e9d000 AsIO (deferred)

fffffadfc8108000 fffffadfc813e000 Mup (deferred)

fffffadfc813e000 fffffadfc8199000 NDIS (deferred)

fffffadfc8199000 fffffadfc82b1000 Ntfs (deferred)

fffffadfc82b1000 fffffadfc82e4000 KSecDD (deferred)

fffffadfc82e4000 fffffadfc8307000 sr (deferred)

fffffadfc8307000 fffffadfc8344000 fltMgr (deferred)

fffffadfc8344000 fffffadfc8363000 CLASSPNP (deferred)

fffffadfc8363000 fffffadfc8378000 disk (deferred)

fffffadfc8378000 fffffadfc8393000 SI3114 (deferred)

fffffadfc8393000 fffffadfc83c4000 SCSIPORT (deferred)

fffffadfc83c4000 fffffadfc8414000 SI3114R5 (deferred)

fffffadfc8414000 fffffadfc843e000 nvata64 (deferred)

fffffadfc843e000 fffffadfc846b000 atapi (deferred)

fffffadfc846b000 fffffadfc84b6000 volsnap (deferred)

fffffadfc84b6000 fffffadfc84fc000 dmio (deferred)

fffffadfc84fc000 fffffadfc853c000 ftdisk (deferred)

fffffadfc853c000 fffffadfc8552000 MountMgr (deferred)

fffffadfc8552000 fffffadfc8565a00 1394BUS (deferred)

fffffadfc8566000 fffffadfc857cc80 ohci1394 (deferred)

fffffadfc857d000 fffffadfc859e000 pci (deferred)

fffffadfc859e000 fffffadfc85f2000 ACPI (deferred)

fffffadfc86f3000 fffffadfc8704000 processr (deferred)

fffffadfc8706000 fffffadfc8718000 wanarp (deferred)

fffffadfc8719000 fffffadfc872b000 netbios (deferred)

fffffadfc872c000 fffffadfc873e000 Fips (deferred)

fffffadfc89fb000 fffffadfc8a04000 kdcom (deferred)

fffffadfc8a0b000 fffffadfc8a14000 BOOTVID (deferred)

fffffadfc8a1b000 fffffadfc8a24000 WMILIB (deferred)

fffffadfc8a2b000 fffffadfc8a34000 isapnp (deferred)

fffffadfc8a3b000 fffffadfc8a4b000 PCIIDEX (deferred)

fffffadfc8a4b000 fffffadfc8a5b000 PartMgr (deferred)

fffffadfc8a5b000 fffffadfc8a65000 SiWinAcc (deferred)

fffffadfc8a6b000 fffffadfc8a76000 crcdisk (deferred)

fffffadfc8a8b000 fffffadfc8a98000 mouclass (deferred)

fffffadfc8abb000 fffffadfc8ac9000 kbdclass (deferred)

fffffadfc8acb000 fffffadfc8ad5000 ndistapi (deferred)

fffffadfc8adb000 fffffadfc8aea000 TDI (deferred)

fffffadfc8afb000 fffffadfc8b08000 ptilink (deferred)

fffffadfc8b0b000 fffffadfc8b16000 raspti (deferred)

fffffadfc8b1b000 fffffadfc8b2b000 update (deferred)

fffffadfc8b2b000 fffffadfc8b35000 rasacd (deferred)

fffffadfc8b3b000 fffffadfc8b45000 VMNET (deferred)

fffffadfc8b4b000 fffffadfc8b57000 Dxapi (deferred)

fffffadfc8b5b000 fffffadfc8b68000 mssmbios (deferred)

fffffadfc8b6b000 fffffadfc8b75980 usbehci (deferred)

fffffadfc8b8b000 fffffadfc8b97a00 NVENETFD (deferred)

fffffadfc8b9b000 fffffadfc8ba7000 flpydisk (deferred)

fffffadfc8bab000 fffffadfc8bb9000 vga (deferred)

fffffadfc8bbb000 fffffadfc8bc5000 mnmdd (deferred)

fffffadfc8bcb000 fffffadfc8bd5000 RDPCDD (deferred)

fffffadfc8bfb000 fffffadfc8c06000 nvnetbus (deferred)

fffffadfc8c0b000 fffffadfc8c15000 Fs_Rec (deferred)

fffffadfc8c2b000 fffffadfc8c34000 watchdog (deferred)

fffffadfc8c3b000 fffffadfc8c48000 Msfs (deferred)

fffffadfc8c4b000 fffffadfc8c59000 fdc (deferred)

fffffadfc8c5b000 fffffadfc8c67000 serenum (deferred)

fffffadfc8cab000 fffffadfc8cb3000 ASACPI (deferred)

fffffadfc8cc3000 fffffadfc8ccb000 audstub (deferred)

fffffadfc8cdb000 fffffadfc8ce3000 CdaC15BA (deferred)

fffffadfc8cfb000 fffffadfc8d03000 CdaD10BA (deferred)

fffffadfc8d7b000 fffffadfc8d83000 vmnetadapter (deferred)

fffffadfc8deb000 fffffadfc8df3000 secdrv (deferred)

fffffadfc8df3000 fffffadfc8dfb000 Null (deferred)

fffffadfc8dfb000 fffffadfc8e02000 pciide (deferred)

fffffadfc8e02000 fffffadfc8e09000 dmload (deferred)

fffffadfc8f13000 fffffadfc8f19700 usbohci (deferred)

fffffadfc8f28000 fffffadfc8f2de80 ksthunk (deferred)

fffffadfc9063000 fffffadfc906a000 Beep (deferred)

fffffadfc9193000 fffffadfc9195800 splitter (deferred)

fffffadfc91f9000 fffffadfc91fa400 swenum (deferred)

fffffadfc9205000 fffffadfc9206d80 USBD (deferred)

This is a base 64-bit Windows system (asus motherboard, based on an
NVIDIA chipset.) I’ve installed VMWare on this machine as well. 2MB
installed (maybe if I install another 2MB I’ll get an additional 24
hours out of the box.)

Verifier is enabled for ALL drivers on this system - but the tag value
does not show up in verifier (“!verifier 3”) but does show up in the
pool tag list (already 1MB in use) - suggesting that whoever owns this
driver is bypassing verifier’s version of the memory allocation routine.
A quick string search of the binaries (\windows\system32\drivers) does
not show the tag in any of them, either.

My own driver is a totally virtual in-memory file system - except for my
ERESOURCES my structures come from paged pool. The test scenario is a
continuous rename/delete multi-threaded test (where we’re trying to
delete the files and rename them simultaneously, looking for complex
race conditions down these paths.)

So, if anyone has information to save me time, please let me know.
Otherwise, you know what I’ll be doing for the next day or two. :wink:

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

it’s a memory block which is allocated by kernel verifier - and not by any 3rd party driver
i’ll send you more details on your email

Petr Kurtin

Thanks Petr - and the others who pointed out the fact that this tag is
used by verifier (hence why I couldn’t find it in any of the drivers.)
A quick “findstr /m” on the nt binaries does indeed turn it up. At a
minimum, then there’s certainly a bug in the debugger’s pooltag file -
since this wasn’t listed, I hadn’t expected it would be an OS structure.
There may be a secondary verifier issue, but I’ll have to do further
testing to determine if this is in fact the case.

Scott also suggested using nt!PoolHitTag to try and find it. That also
works rather well:

1: kd> kv

Child-SP RetAddr : Args to Child
: Call Site

fffffadfc8e4dda8 fffff8000105b15c : 0000000000000000 fffff800012bb539 0000000000000000 0000000070706556 : nt!DbgBreakPoint

fffffadfc8e4ddb0 fffff80001183a93 : 0000000000001000 0000000000000000 0000000000000000 fffffadfccdea000 :
nt!ExpInsertPoolTracker+0x2c

fffffadfc8e4de00 fffff8000102cc8f : fffffadf00000080 fffff8000101a300 ffffffff80000b34 0000000000000020 :
nt!ExAllocatePoolWithTag+0x2af

fffffadfc8e4ded0 fffff800013c7eda : fffffadfc8e4e118 0000000000000000 fffffadf70706556 fffffadfc41874b0 :
nt!ExAllocatePoolWithTagPriority+0x36c

fffffadfc8e4df40 fffff800013c8408 : fffffadfcce3d830 fffffadfcdbf4a50 0000000000000070 fffffa8001d75e80 :
nt!ViGrowPoolAllocation+0x2a

fffffadfc8e4df70 fffff800013c7ada : fffffadfcce3d830 fffffadfcdbadc00 fffffadf58494d4b fffffa8001d75e80 :
nt!VeAllocatePoolWithTagPriority+0x2a9

fffffadfc8e4dff0 fffffadfc41741e6 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 :
nt!VerifierExAllocatePoolWithTag+0x8d

fffffadfc8e4e030 fffffadfc41753c9 : 0002001900000000 fffffadf00020019 fffffadf00000000 fffffa80001c0cc0 :
kmixer!QueryRegistryValueEx+0x46

fffffadfc8e4e0b0 fffffadfc417541a : 0000000000000010 0000000000010286 fffffadf00000000 0000000000000018 :
kmixer!GetUlongFromRegistry+0x39

fffffadfc8e4e100 fffffadfc416d1f0 : 0000000000000010 0000000000010206 fffffadfc8e4e158 0000000000000018 :
kmixer!GetMixerSettingsFromRegistry+0x1a

fffffadfc8e4e130 fffff80001312bce : fffffadf00000000 0000000000000000 000000000000001c fffffadfcdbadc00 :
kmixer!DriverEntry+0x60

fffffadfc8e4e160 fffff8000132a893 : 0000000000000004 ffffffff80000b40 0000000000000003 ffffffff80000b40 :
nt!IopLoadDriver+0xbad

fffffadfc8e4e320 fffff8000123f0a3 : 0000000000000000 fffffadf00000000 fffffadf00000001 fffffadf00020019 :
nt!PipCallDriverAddDeviceQueryRoutine+0x5f3

fffffadfc8e4e510 fffff80001234c4c : 0000000000000001 fffffadf00000001 fffffadfc8e4e5f0 fffffadfc8e4e770 :
nt!RtlpCallQueryRegistryRoutine+0x4e5

fffffadfc8e4e5c0 fffff80001329e3a : 0000000000000000 0000000000000001 fffffadfccdf7ce0 0000000000000001 :
nt!RtlQueryRegistryValues+0x3fb

fffffadfc8e4e6c0 fffff8000132bcdf : fffffadfcdbe47e0 0000000000000002 fffffadfcdbe47e0 0000000000000001 :
nt!PipCallDriverAddDevice+0x4aa

fffffadfc8e4e890 fffff8000132da65 : fffffabdb4f8cf00 fffff800013db401 0000000000000002 fffffadfccdca800 :
nt!PipProcessDevNodeTree+0x267

fffffadfc8e4ec20 fffff800010c25d4 : fffff80000000003 0000000000000000 fffffadfce928040 0000000000000000 :
nt!PiProcessReenumeration+0x85

fffffadfc8e4ec70 fffff80001056d6c : 0000000000000000 fffff800011b5ca0 fffff800010c22d0 fffffadfce928040 :
nt!PipDeviceActionWorker+0x304

fffffadfc8e4ed00 fffff80001272bae : fffffadfce928040 0000000000000080 fffffadfce928040 fffffadfc8a83680 :
nt!ExpWorkerThread+0x13b

Which *hints* that this is verifier. Of course, there might be an
underlying memory leak within my own drivers leading to this issue as
well (since verifier masks pool allocations when used with “!poolused”,
although I noticed in previous runs - when I had a non-paged pool leak -
that the memory would eventually show up in the poolused list) but it
seems to be rather poor form for the tracking tool to itself create what
seems to be a rather substantial problem (let’s face it - 200+MB of
non-paged pool is a LOT of memory to allocate.) This might be related
to the slightly larger pool address spaces (128GB for each pool last I
checked) as well.

Well, at least I can now go back and look at my own code. Memory leaks
aren’t as interesting as race conditions, but they still need to be
eliminated.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 24-27, 2006.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Petr Kurtin
Sent: Sunday, December 18, 2005 7:06 PM
To: ntfsd redirect
Subject: Re:[ntfsd] “Vepp” tag hunt - assistance requested

it’s a memory block which is allocated by kernel verifier - and not by
any 3rd party driver

i’ll send you more details on your email

Petr Kurtin


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com