PAGEHEAP GFLAGS /P WOES.

[Le Chaud Lapin]

Hi All,

I regrettably allowed my expectations of effectiveness to rise when I
discovered PAGEHEAP.EXE/GFLAGS.EXE, chiding myself for presupposing
that, instead of finding my heap-corruption bug, I might waste a few
hours trying in vain"

I have two namespace extensions running under EXPLORER.EXE under Vista
Ultimate. One of the NSE's seems to have a heap corruption bug in it
that only began to manifest recently. The bug occurs when I node-
expand at 3rd-level deep from root into the hierarchy of the TreeView
in left-hand-pane of EXPLORER.EXE. The stack trace when the heap
corruption is detected:

ntdll.dll!***@0()
verifier.dll!***@40() + 0x1fd bytes
verifier.dll!***@16() + 0x1b9 bytes
verifier.dll!***@16() + 0x125 bytes
verifier.dll!***@12() + 0x14b bytes
ntdll.dll!***@12() + 0x2f bytes
ntdll.dll!@***@16() + 0x13cdd bytes
ntdll.dll!***@12() + 0x2e49 bytes
verifier.dll!***@12() + 0x16b bytes
kernel32.dll!***@12() + 0x14 bytes
ole32.dll!CRetailMalloc_Free() + 0x1c bytes
ole32.dll!***@4() + 0x13 bytes
shlwapi.dll!***@16() + 0x3a bytes
shdocvw.dll!CNscTree::_OnGetDisplayInfo() + 0xa8 bytes
shdocvw.dll!CNscTree::_OnNotify() + 0xc7b bytes
shdocvw.dll!CNscTree::OnWinEvent() + 0x38 bytes

I have spent the last two hours trying to get GFLAGS.EXE to work
against EXPLORER.EXE so I can determine the precise moment when the
heap is corrupted. I read the KB Article for PAGEHEAP.EXE/GFLAGS.EXE
here:

http://support.microsoft.com/kb/286470

I am not able to find the right command-line sequence to confine the
allocated memory as described in the article. It seems to me that
something like this should have worked:

gflags /p /enable explorer.exe /full /unaligned

I use VS2008 to launch explorer.exe. I debug-attach to the newly
created process with VS2008. I see in VS2008 Output window:

Page heap: pid 0x5B0: page heap enabled with flags 0x3.
Page heap: pid 0x1124: page heap enabled with flags 0x3.
AVRF: explorer.exe: pid 0x1124: flags 0x1: application verifier
enabled

The first two lines are for two other processes for which I enabled
page-guarding and launched by the debugger just to make sure I am not
going insane. They appear to be correct.

As you can see, the 3rd line, which is for EXPLORER.EXE is different.
I have tried everything except enable page-guarding for entire system
an rebooting. I am unable to get a page-fault at precise point of
heap corruption. I have tried many different combination of the
gflags command above with no sucess.

Is this normal for EXPLORER.EXE?

TIA,

-Le Chaud Lapin-

[Le Chaud Lapin]

Post by Le Chaud Lapin
Hi All,
I regrettably allowed my expectations of effectiveness to rise when I
discovered  PAGEHEAP.EXE/GFLAGS.EXE, chiding myself for presupposing
that, instead of finding my heap-corruption bug, I might waste a few
hours trying  in vain"

I stayed at machine one more hour, late...one eye open, one eye
closed, randomly greping for lines of code that might be culprit...and
found the bug.

Offending line should be:

lpName->pOleStr = (LPWSTR) CoTaskMemAlloc (sizeof(String__::Character)
* (text.length() + 1));

Not:

lpName->pOleStr = (LPWSTR) CoTaskMemAlloc (sizeof(String_::Character)
* (text.length() + 1));

I am so glad I was able to use PAGEHEAP.EXE instead of sheer luck to
find this heap corruption bug. ;)

-Le Chaud Lapin-

[Jim Barry]

Post by Le Chaud Lapin
lpName->pOleStr = (LPWSTR) CoTaskMemAlloc (sizeof(String__::Character)
* (text.length() + 1));
lpName->pOleStr = (LPWSTR) CoTaskMemAlloc (sizeof(String_::Character)
* (text.length() + 1));

What are String_ and String__? Why had you not just written sizeof(WCHAR)?

[Le Chaud Lapin]

Post by Jim Barry

Post by Le Chaud Lapin
lpName->pOleStr = (LPWSTR) CoTaskMemAlloc (sizeof(String__::Character)
* (text.length() + 1));
lpName->pOleStr = (LPWSTR) CoTaskMemAlloc (sizeof(String_::Character)
* (text.length() + 1));

What are String_ and String__? Why had you not just written sizeof(WCHAR)?

Hi Jim. :)

That would have made better sense huh?

String__ is my own string class. [Yeah, I know, everyone reinvents the
wheel].

I am adding member function to String<> to get right size to pass to
CoTaskMemAlloc so that this type of thing is less likely to happen
again.

-Le Chaud Lapin-

[Brycej]

You may also want to revisit your use of GFlags, as AppVerifier contains the
more contemporary implimentation.

-Brycej

Post by Jim Barry

Post by Le Chaud Lapin
lpName->pOleStr = (LPWSTR) CoTaskMemAlloc (sizeof(String__::Character)
* (text.length() + 1));
lpName->pOleStr = (LPWSTR) CoTaskMemAlloc (sizeof(String_::Character)
* (text.length() + 1));

What are String_ and String__? Why had you not just written sizeof(WCHAR)?

Hi Jim. :)

That would have made better sense huh?

String__ is my own string class. [Yeah, I know, everyone reinvents the
wheel].

I am adding member function to String<> to get right size to pass to
CoTaskMemAlloc so that this type of thing is less likely to happen
again.

-Le Chaud Lapin-