First, if your response is "you don't need to", don't respond. I've
tried pageheap.exe and the app verifier suite. They don't do what I
need to do.
What's the problem? MS distributes a quote-unquote buildable
MSVCRT[D]/LIBCMT/etc source code set as a part of VS. If you apply KB
article 315535, it will actually build. However, it is missing
several exports, specifically ??_U@YAXAPI@Z/??_V@YAXAPI@Z, which mean
the resultant dll will not work as a straight replacement for MSVCRT.
I don't know what these are - deleting destructors of some flavor
judging by the name.
I need to instrument the dll to find a problem I can't catch with the
debugger.
Why do I want to do this? I write an addin for a VERY large third
part app (Vltpa) which I don't have source or debug access to. At
some point, someone is corrupting a portion of one block (when and
which one varies) on the small block heap. I have proven - in my mind
at least - that my code is not the problem. However, the Vltpa can't
dup the problem without my addin even though it happens while they
have control so, QED, it must be my problem.
What I need to do is hook malloc, calloc, new, free and associated
friends to call __sbh_heap_check each time they are called. I know
how to mung the sb heap allocation to add the address of the allocator
to each block. Now, as I said the when/who varies. However, it is
always the same type of block (eg, used to store the same type of
structure) so I suspect the same allocator is requesting the block
which gets damaged.
Once I've got a failure from __sbh_heap_check - and I will - I know
who allocated the block. I can now break on all allocations from this
address and set watchpoints on the allocated block. This gets me the
offending address in the Vltpa which I can throw back at them.
I can't use an instrumented version with a different name. I'll only
track my allocations and they aren't the problem.
<sarcasm>
If MS saw fit to have functionally equivalent libraries, I wouldn't
have to be going through these hoops. MSVCRTD has pre/post allocation
hooks are really all I need. They don't exist in MSVCRT. MSVCRT
exports symbols which MSVCRTD doesn't so you can't just rename the
libraries (as I would on *nix).
What does it matter that the production libraries have the hooks? The
code already exists, some applications might find them useful, they
don't cost runtime. There might be some security issues - I'm sure
they could be worked around.
</sarcasm>
