=?Utf-8?Q?gflags_/DLLS_option_doesn=E2=80=99t_work?=

I support a large application that uses many DLLs. I am solving a problem to 
do with memory overrun (meaning that some code is occasionally writing 
slightly past the end of a memory allocation) which is classic problem 
begging for a gflags full pageheap solution – especially when I know which 
DLL allocates the memory in question. The problem is that when I specify /DLL 
foo.dll on the gflags command like so:

gflags -p /enable blah.exe /full /DLLS foo.dll

I don’t get full pageheap for any allocations let alone foo.dll. I get full 
page heap if I do not mention /DLLS foo.dll – that is all DLL’s. But that 
approach is unworkable as the application never starts as it takes for ever, 
while all the time, the process bytes grows and grows – presumably all the 
small allocations turning into 2 pages of virtual address space lost. 2 pages 
at a time out of a 2GB address space only allows for 256*1024 allocations 
after all.

I do get full page heap if I specify

gflags -p /enable blah.exe /full /DLLS MSVCR80.dll

but for my application that is effectively all DLLs.

I can get what I want by specifying 

gflags -p /enable blah.exe /full /address 10000000 10005000

where the addresses are the start and end addresses of foo.dll. This way, I 
do get full pageheap allocations for only the DLL in question, and for no 
other DLL’s – but this is not practical as I don’t always now where the
DLL 
will be loaded from invocation to invocation.

My questions is: Does /dlls really mean that at runtime, only the DLL on the 
top of the stack is examined? For example, MSVCR80 is the DLL for the first 
stack entry and foo is the next entry, but despite that, /dlls foo.dll never 
works and /dlls MSVCR80 does. /address documentation (extract below) is 
unambiguous about the address being on the call stack.

Has anyone got gflag /dlls to work for DLLs written in C or C++ using Visual 
Studio 2005 in Release builds? How can I get gflags to capture only 
allocations from my DLLS if they use the C runtime to do the allocations in 
MSCR80.dll?

Rgds,
	Rob Watson
 
<quote from Windgb help ‘Gflags Commmands’>
/dlls DLL[, DLL...] 
Enables full page heap verification for allocations requested by the 
specified DLLs and standard page heap verification for all other allocations 
by the process. 
DLL is the name of a binary file, including its file name extension. The 
specified file must be a function library that the process loads during 
execution.
</quote>
<quote – another one, same place>
/address AddressStart AddressEnd 
Enables full page heap verification for memory allocated while a return 
address in the specified address range is on the run-time call stack. It 
enables standard page heap verification for all other allocations by the 
process. 
To use this feature, specify a range that includes the addresses of all 
functions that call the function with the suspect allocation. The address of 
the calling function will be on the call stack when the suspect allocation 
occurs. <Snip>
</quote>

-- 

the `/DLLS` option makes all alocation to get Light-PageHeap
except the allocations coming from the import table of foo.dll,
that will go to Full-PageHeap.

What is the intent here ? To get Full-Pageheap only for your own DLL ?
If yes, then, how does your dll allocate memory ?
Through a OS-supplied interface,
such as RtlAllocateHeap, HeapAlloc, msvcrt!malloc ?
Or via some other allocator provided by other non-system components,
such as the VS-2005 C-Runtime ?

As mentioned earlier, with the /DLL option only the import table of the
DLL specified in the command line is proxied to get Full-PageHeap.
This process is NOT recursively applied.

Your best workaround is, as you have discovered, to proxy msvcrt80.dll

-- 

-- 
This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Rob Watson" <RobWatson@discussions.microsoft.com> wrote in
message 
news:E046CB45-5583-4537-B23B-7413271BC791@microsoft.com...
>I support a large application that uses many DLLs. I am solving a problem 
>to
> do with memory overrun (meaning that some code is occasionally writing
> slightly past the end of a memory allocation) which is classic problem
> begging for a gflags full pageheap solution - especially when I know which
> DLL allocates the memory in question. The problem is that when I specify 
> /DLL
> foo.dll on the gflags command like so:
>
> gflags -p /enable blah.exe /full /DLLS foo.dll
>
> I don't get full pageheap for any allocations let alone foo.dll. I get 
> full
> page heap if I do not mention /DLLS foo.dll - that is all DLL's. But that
> approach is unworkable as the application never starts as it takes for 
> ever,
> while all the time, the process bytes grows and grows - presumably all the
> small allocations turning into 2 pages of virtual address space lost. 2 
> pages
> at a time out of a 2GB address space only allows for 256*1024 allocations
> after all.
>
> I do get full page heap if I specify
>
> gflags -p /enable blah.exe /full /DLLS MSVCR80.dll
>
> but for my application that is effectively all DLLs.
>
> I can get what I want by specifying
>
> gflags -p /enable blah.exe /full /address 10000000 10005000
>
> where the addresses are the start and end addresses of foo.dll. This way, 
> I
> do get full pageheap allocations for only the DLL in question, and for no
> other DLL's - but this is not practical as I don't always now where the 
> DLL
> will be loaded from invocation to invocation.
>
> My questions is: Does /dlls really mean that at runtime, only the DLL on 
> the
> top of the stack is examined? For example, MSVCR80 is the DLL for the 
> first
> stack entry and foo is the next entry, but despite that, /dlls foo.dll 
> never
> works and /dlls MSVCR80 does. /address documentation (extract below) is
> unambiguous about the address being on the call stack.
>
> Has anyone got gflag /dlls to work for DLLs written in C or C++ using 
> Visual
> Studio 2005 in Release builds? How can I get gflags to capture only
> allocations from my DLLS if they use the C runtime to do the allocations 
> in
> MSCR80.dll?
>
> Rgds,
> Rob Watson
>
> <quote from Windgb help 'Gflags Commmands'>
> /dlls DLL[, DLL...]
> Enables full page heap verification for allocations requested by the
> specified DLLs and standard page heap verification for all other 
> allocations
> by the process.
> DLL is the name of a binary file, including its file name extension. The
> specified file must be a function library that the process loads during
> execution.
> </quote>
> <quote - another one, same place>
> /address AddressStart AddressEnd
> Enables full page heap verification for memory allocated while a return
> address in the specified address range is on the run-time call stack. It
> enables standard page heap verification for all other allocations by the
> process.
> To use this feature, specify a range that includes the addresses of all
> functions that call the function with the suspect allocation. The address 
> of
> the calling function will be on the call stack when the suspect allocation
> occurs. <Snip>
> </quote>
>
> -- 
> Windbg rookie