debugging: driver verifier detects memory leak -> bugcheck 0xc4 (0x62,..,..,1)

Hello everyone,

it seems that my driver has a memory leak.
!verifier 3 driver.sys says:

PoolAddress SizeInBytes Tag CallersAddress
8a1d8fe0 1c HWnp b89bc560

?? /s b89bc560 results:

operator new
void* driver!operator new+0(
unsigned int,
_POOL_TYPE,
unsigned long)

How do I find the line in my sources where the memory was allocated?

Thanks,
/Uwe

You can’t without changing how your operator new works. Verifier just
knows how to get the caller’s address, not the caller’s caller’s address
(to get the caller of operator new). One way to fix this is to allocate
extra space as a header in your operator new to store the caller’s
address yourself (which you get by calling the intrinsic
_ReturnAddress()) and then look in your header for the callers address
when debugging. This does burn some extra memory though.

This is one of the reasons I don’t like single memory allocator in a
driver (in C, it is MyExAllocatePool or some such), it makes using the
built in tools harder and you must recreate a lot of infrastructure that
you would get for free if you didn’t follow this pattern.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Uwe Kirst
Sent: Wednesday, June 20, 2007 2:08 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] debugging: driver verifier detects memory leak ->
bugcheck 0xc4 (0x62,…,…,1)

Hello everyone,

it seems that my driver has a memory leak.
!verifier 3 driver.sys says:

PoolAddress SizeInBytes Tag CallersAddress
8a1d8fe0 1c HWnp b89bc560

?? /s b89bc560 results:

operator new
void* driver!operator new+0(
unsigned int,
_POOL_TYPE,
unsigned long)

How do I find the line in my sources where the memory was allocated?

Thanks,
/Uwe


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Is there any way to portably generate a multi-level backtrace for the
current thread from within a driver? I wrote something like this a long
time ago for i386 code with clean stack frames, but it has gotten more
complex with the x64, especially without inline assembler support.

_ReturnAddress() provides a single level, but in a lot of situations I need
at least 2-3 levels of the call stack to determine the chain of events in a
memory leak.

-John

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, June 20, 2007 9:35 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] debugging: driver verifier detects
memory leak -> bugcheck 0xc4 (0x62,…,…,1)

You can’t without changing how your operator new works.
Verifier just knows how to get the caller’s address, not the
caller’s caller’s address (to get the caller of operator
new). One way to fix this is to allocate extra space as a
header in your operator new to store the caller’s address
yourself (which you get by calling the intrinsic
_ReturnAddress()) and then look in your header for the
callers address when debugging. This does burn some extra
memory though.

This is one of the reasons I don’t like single memory
allocator in a driver (in C, it is MyExAllocatePool or some
such), it makes using the built in tools harder and you must
recreate a lot of infrastructure that you would get for free
if you didn’t follow this pattern.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Uwe Kirst
Sent: Wednesday, June 20, 2007 2:08 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] debugging: driver verifier detects memory
leak -> bugcheck 0xc4 (0x62,…,…,1)

Hello everyone,

it seems that my driver has a memory leak.
!verifier 3 driver.sys says:

PoolAddress SizeInBytes Tag CallersAddress
8a1d8fe0 1c HWnp b89bc560

?? /s b89bc560 results:

operator new
void* driver!operator new+0(
unsigned int,
_POOL_TYPE,
unsigned long)

How do I find the line in my sources where the memory was allocated?

Thanks,
/Uwe


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

RtlGetCallersAddress() (in ntddk.h) will do that for you, but only for
x86. On both 64 bit platforms, it will not return the caller’s caller
address

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of John Kraft
Sent: Wednesday, June 20, 2007 4:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] debugging: driver verifier detects memory leak ->
bugcheck 0xc4 (0x62,…,…,1)

Is there any way to portably generate a multi-level backtrace for the
current thread from within a driver? I wrote something like this a long
time ago for i386 code with clean stack frames, but it has gotten more
complex with the x64, especially without inline assembler support.

_ReturnAddress() provides a single level, but in a lot of situations I
need
at least 2-3 levels of the call stack to determine the chain of events
in a
memory leak.

-John

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, June 20, 2007 9:35 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] debugging: driver verifier detects
memory leak -> bugcheck 0xc4 (0x62,…,…,1)

You can’t without changing how your operator new works.
Verifier just knows how to get the caller’s address, not the
caller’s caller’s address (to get the caller of operator
new). One way to fix this is to allocate extra space as a
header in your operator new to store the caller’s address
yourself (which you get by calling the intrinsic
_ReturnAddress()) and then look in your header for the
callers address when debugging. This does burn some extra
memory though.

This is one of the reasons I don’t like single memory
allocator in a driver (in C, it is MyExAllocatePool or some
such), it makes using the built in tools harder and you must
recreate a lot of infrastructure that you would get for free
if you didn’t follow this pattern.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Uwe Kirst
Sent: Wednesday, June 20, 2007 2:08 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] debugging: driver verifier detects memory
leak -> bugcheck 0xc4 (0x62,…,…,1)

Hello everyone,

it seems that my driver has a memory leak.
!verifier 3 driver.sys says:

PoolAddress SizeInBytes Tag CallersAddress
8a1d8fe0 1c HWnp b89bc560

?? /s b89bc560 results:

operator new
void* driver!operator new+0(
unsigned int,
_POOL_TYPE,
unsigned long)

How do I find the line in my sources where the memory was allocated?

Thanks,
/Uwe


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Thank you for your answer,
meanwhile I could find the cause of my memory leak with the help of the
memory tag. Luckly this tag was only used once in my driver.
/Uwe

Doron Holan schrieb:

You can’t without changing how your operator new works. Verifier just
knows how to get the caller’s address, not the caller’s caller’s address
(to get the caller of operator new). One way to fix this is to allocate
extra space as a header in your operator new to store the caller’s
address yourself (which you get by calling the intrinsic
_ReturnAddress()) and then look in your header for the callers address
when debugging. This does burn some extra memory though.

This is one of the reasons I don’t like single memory allocator in a
driver (in C, it is MyExAllocatePool or some such), it makes using the
built in tools harder and you must recreate a lot of infrastructure that
you would get for free if you didn’t follow this pattern.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Uwe Kirst
Sent: Wednesday, June 20, 2007 2:08 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] debugging: driver verifier detects memory leak ->
bugcheck 0xc4 (0x62,…,…,1)

Hello everyone,

it seems that my driver has a memory leak.
!verifier 3 driver.sys says:

PoolAddress SizeInBytes Tag CallersAddress
8a1d8fe0 1c HWnp b89bc560

?? /s b89bc560 results:

operator new
void* driver!operator new+0(
unsigned int,
_POOL_TYPE,
unsigned long)

How do I find the line in my sources where the memory was allocated?

Thanks,
/Uwe


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer