PoolTags and normal growth

NTFSD
1

I have been running PoolTag and watching my driver’s memory usage (flat line

  • yay!). But while watching, I’ve noticed that some of the pools just keep
    growing and growing, a few KB ever couple of seconds. I was nervous
    thinking it was my driver, but even after stopping and unloading my driver
    and app, they keep growing.

Does anyone know what these tags are, and what reasonable values should be?

Pool Tag Bytes Used

Ntff 54,812,416
FMfn 38,293,776
MmSt 30,620,320
FMsl (NON) 17,353,536
File (NON) 17,249,136
NtFr (NON) 14,733,440

Task Manager shows 567 Total MB Kernel memory (419 MB paged, 147 MB
non-paged). It’s only about 232 MB total a few minutes after boot (184 MB
paged, 48 MB non-paged), so it’s definitely been growing for the past few
hours.

Is this anything to worry about? Maybe the fact that I have 3GB of RAM
means the system will grow comfortably until it hits some internal limit?
(Vista 64 bit if that matters).

I’m interested in anyone’s experiences.

Thanks
Doug

2

I can suggest placing a “touch and go” breakpoint into the ExAllocatePoolWithTag that will be triggered only for some of the tags. Then you can inspect the stack trace and potentially see which application is allocating memory. r8d is the register that stores the tag. I tested this in Server 2003 X64:

bp ExAllocatePoolWithTag “.if @r8d == ‘fftN’ {kb;!process;} .else {gc;}”
There’s also ExAllocatePoolWithQuotaTag that needs to be considered.

----- Original Message ----
From: Doug
To: Windows File Systems Devs Interest List
Sent: Saturday, August 9, 2008 12:08:18 AM
Subject: [ntfsd] PoolTags and normal growth

I have been running PoolTag and watching my driver’s memory usage (flat line
- yay!). But while watching, I’ve noticed that some of the pools just keep
growing and growing, a few KB ever couple of seconds. I was nervous
thinking it was my driver, but even after stopping and unloading my driver
and app, they keep growing.

Does anyone know what these tags are, and what reasonable values should be?

Pool Tag Bytes Used
------------------------
Ntff 54,812,416
FMfn 38,293,776
MmSt 30,620,320
FMsl (NON) 17,353,536
File (NON) 17,249,136
NtFr (NON) 14,733,440

Task Manager shows 567 Total MB Kernel memory (419 MB paged, 147 MB
non-paged). It’s only about 232 MB total a few minutes after boot (184 MB
paged, 48 MB non-paged), so it’s definitely been growing for the past few
hours.

Is this anything to worry about? Maybe the fact that I have 3GB of RAM
means the system will grow comfortably until it hits some internal limit?
(Vista 64 bit if that matters).

I’m interested in anyone’s experiences.

Thanks
Doug

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

This is going to be painfully slow as the pool allocator is hit pretty often.

There is an extremely poorly documented (corollary: the usefulness of an NT/windbg debugging feature seems to be inversely proportional to how well documented it is) kernel feature that will get this done in a much better fashion, however.

There’s a global kernel variable (nt!PoolHitTag) which you can set to a pool tag value that is passed to Ex*PoolWithTag functions which you are interested in. When a call with this pool tag is seen, the kernel will execute a breakpoint instruction so you can inspect what’s going in the debugger. Unlike a conditional breakpoint, this does not result in many round trip times to the kernel debugger while all processors are halted on every single pool allocation, and is thus fairly generally useful.

Zero out nt!PoolHitTag when you are done with your tracing.

(It’s also present on free builds, no need to install the checked kernel.)

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calin Iaru
Sent: Friday, August 08, 2008 7:11 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] PoolTags and normal growth

I can suggest placing a “touch and go” breakpoint into the ExAllocatePoolWithTag that will be triggered only for some of the tags. Then you can inspect the stack trace and potentially see which application is allocating memory. r8d is the register that stores the tag. I tested this in Server 2003 X64:

bp ExAllocatePoolWithTag “.if @r8d == ‘fftN’ {kb;!process;} .else {gc;}”
There’s also ExAllocatePoolWithQuotaTag that needs to be considered.

----- Original Message ----
From: Doug
To: Windows File Systems Devs Interest List
Sent: Saturday, August 9, 2008 12:08:18 AM
Subject: [ntfsd] PoolTags and normal growth

I have been running PoolTag and watching my driver’s memory usage (flat line
- yay!). But while watching, I’ve noticed that some of the pools just keep
growing and growing, a few KB ever couple of seconds. I was nervous
thinking it was my driver, but even after stopping and unloading my driver
and app, they keep growing.

Does anyone know what these tags are, and what reasonable values should be?

Pool Tag Bytes Used
------------------------
Ntff 54,812,416
FMfn 38,293,776
MmSt 30,620,320
FMsl (NON) 17,353,536
File (NON) 17,249,136
NtFr (NON) 14,733,440

Task Manager shows 567 Total MB Kernel memory (419 MB paged, 147 MB
non-paged). It’s only about 232 MB total a few minutes after boot (184 MB
paged, 48 MB non-paged), so it’s definitely been growing for the past few
hours.

Is this anything to worry about? Maybe the fact that I have 3GB of RAM
means the system will grow comfortably until it hits some internal limit?
(Vista 64 bit if that matters).

I’m interested in anyone’s experiences.

Thanks
Doug

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Check pooltag.txt in the Debugging Tools For Windows\triage directory. This
is a description of a good amount of tags used in the MS supplied components
(the WinDBG pool commands like !poolused WinDBG know about the file and will
give you this info).

The big one that jumps out here is File, which is used for PFILE_OBJECTs.
This is pretty normal on a loaded system, lots of people have lots of things
open. The FM tags are filter manager and the Nt ones are NTFS, so it would
make sense that if you have lots of files open you’ll also have lots of FM
and NTFS structures in pool. And MmSt is a well know one used for sections.

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Doug” wrote in message news:xxxxx@ntfsd…
>I have been running PoolTag and watching my driver’s memory usage (flat
>line
> - yay!). But while watching, I’ve noticed that some of the pools just
> keep
> growing and growing, a few KB ever couple of seconds. I was nervous
> thinking it was my driver, but even after stopping and unloading my driver
> and app, they keep growing.
>
> Does anyone know what these tags are, and what reasonable values should
> be?
>
> Pool Tag Bytes Used
> ------------------------
> Ntff 54,812,416
> FMfn 38,293,776
> MmSt 30,620,320
> FMsl (NON) 17,353,536
> File (NON) 17,249,136
> NtFr (NON) 14,733,440
>
> Task Manager shows 567 Total MB Kernel memory (419 MB paged, 147 MB
> non-paged). It’s only about 232 MB total a few minutes after boot (184 MB
> paged, 48 MB non-paged), so it’s definitely been growing for the past few
> hours.
>
> Is this anything to worry about? Maybe the fact that I have 3GB of RAM
> means the system will grow comfortably until it hits some internal limit?
> (Vista 64 bit if that matters).
>
> I’m interested in anyone’s experiences.
>
> Thanks
> Doug
>
>
>
>

5

These are documented actually, and are all filter manager, NTFS and
Mm
allocations:

Pool Tag Bytes Used

Ntff 54,812,416

NTFS - FCB_DATA. Not related to your driver’s allocations in any way
really.

FMfn 38,293,776

Filter Manager file name cache structure.
I am not sure which FltMgr tag should be freed by the user, but
if
you’re not exhausting the pool in an hour it’s probably not this one.
(I am referring to the memory allocated by
FltGetFileNameInformation and
related APIs - these should be freed by the user - make sure you are and
you’re
fine with this tag).

P.S. I started writing this before I saw Scoot’s reply :wink:

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

6

> MmSt 30,620,320

Prototype PTE table. Grows when large files are memory-mapped.

File (NON) 17,249,136

File object.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

7

> and NTFS structures in pool. And MmSt is a well know one used for sections.

Sect is the section object, which has nothing in it except a pointer to control
area and the page protection flags usen when creating (to restict map calls).

MmCa is the non-SEC_IMAGE control area, a maximum of one per FCB.
MmCi is the SEC_IMAGE control area, a maximum of one per FCB.

MmSt is the prototype PTE table chunk (“segment”).

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com