Re: C++ in KMDF
- From: Walter Oney <waltoney@xxxxxxxxxxxx>
- Date: Wed, 03 Oct 2007 03:41:00 -0400
"Doron Holan [MSFT]" wrote:
are you sure it works for 64 bits if the size parameter is enregistered?
the address of the register is not going to give you the caller's stack is
it? Besides, there is a compiler intrinsic which will give you the caller's
address with out pointer trickery. The problem with new localizing all
allocations to one function is not that you can work around the issue by
capturing the caller's address, it is that other tools which do not know to
jump up one stack location are affected. for instance, driver verifier will
report all allocations coming from your operator new() and you then have to
manually inspect the pool on your own to find the real caller (if it is even
stored on a fre build)
Actually, I don't know because I've never had a memory leak in the
64-bit version of one of my drivers. All the leaks got plugged while
testing in 32-bits. But for future reference, what's the intrinsic?
I don't much care if verifier gets the wrong address because verifier
never sees a memory leak unless the release build has a bug that wasn't
in the debug build. My debug cleanup reports the leak via an ASSERT and
then ExFreePool's the allocation. This has never failed to find all the
leaks in years of driver writing. Mind you, I only went down this path
because I needed to be able to debug drivers on my laptop while
travelling, and that meant using Soft-Ice, and that meant needing a way
to keep a verifier error from bug-checking on the very first error.
--
Walter Oney, Consulting and Training
http://www.oneysoft.com
.
- References:
- Re: C++ in KMDF
- From: Tim Roberts
- Re: C++ in KMDF
- From: Walter Oney
- Re: C++ in KMDF
- From: Doron Holan [MSFT]
- Re: C++ in KMDF
- Prev by Date: Re: C++ in KMDF
- Next by Date: Build Error: Time is In Future Error
- Previous by thread: Re: C++ in KMDF
- Next by thread: Re: Installing a virtual modem via INF
- Index(es):
Relevant Pages
|