Holy cow, I wrote a book!
A customer reported that there was a leak in the shell,
and they included the output from
And yup, the memory that was leaked was in fact allocated
by the shell:
VERIFIER STOP 00000900 : pid 0x3A4: A heap allocation was leaked.
497D0FC0 : Address of the leaked allocation.
002DB580 : Adress to the allocation stack trace.
0D65CFE8 : Address of the owner dll name.
6F560000 : Base of the owner dll.
1: kd> du 0D65CFE8
1: kd> !heap -p -a 497D0FC0
1: kd> dps 002DB580
On the other hand, SHCreateMemStream is
an object creation function,
so it's natural that the function allocate some memory.
The responsibility for freeing the memory belongs to the caller.
We suggested that the customer appears to have leaked the
Perhaps there's a hole where they called AddRef
and managed to avoid the matching Release.
"Oh no," the customer replied,
"that's not possible.
We call this function in only one place,
and we use a smart pointer,
so a leak is impossible."
The customer was kind enough to include a code snippet
and even highlighted the lines that proved they weren't
UINT nDepth = 0;
//Open read-only input stream
pMemoryStream = ::SHCreateMemStream(utf8Xml, cbUtf8Xml);
The exercise for today is to identify the irony in the
Answers (and more discussion) tomorrow.