Exceptions in NTDLL.DLL

[Minh Tuan Luong]

Hi all,

If a program generates an exception in NTDLL.DLL by calling functions
such as RtlFreeHeap or NdrAllocate, is there anything the programmer can
do to correct this? How does one go about finding the API call which
called these functions?

Any help appreciated

--
"Shoot for the moon. Even if you miss, you will land among the stars." -
Anonymous

[Tomas Restrepo]

Minh,

> If a program generates an exception in NTDLL.DLL by calling functions
> such as RtlFreeHeap or NdrAllocate, is there anything the programmer can
> do to correct this?

The likely cause is a bug in your code you haven't found yet, maybe an
incorrect parameter.

> How does one go about finding the API call which
> called these functions?

Simple: Run the program under the debugger, wait for it to crash, then open
the call stack trace window, and follow it.

--
Tomas Restrepo
tom...@mvps.org
http://members.xoom.com/trestrep/

[Minh Tuan Luong]

Hi Tomas,

This is what I get from the call stack! Do you think there is something
wrong with my code? I don't know where to start to even debug this.

NTDLL! RtlpCoalesceFreeBlocks@16 + 255 bytes
NTDLL! RtlFreeHeap@12 + 183 bytes
RPCRT4! operator delete(void *) + 18 bytes
RPCRT4! WMSG_SASSOCIATION::~WMSG_SASSOCIATION(void) + 43042 bytes
RPCRT4! WMSG_SASSOCIATION::DealWithCloseMessage(void) + 80 bytes
RPCRT4! WMSG_ADDRESS::ReceiveLotsaCalls(void) + 901 bytes
RPCRT4! RecvLotsaCallsWrapper(class WMSG_ADDRESS *) + 9 bytes
RPCRT4! 77e16821()
RPCRT4! ThreadStartRoutine(class THREAD *) + 23 bytes
KERNEL32! BaseThreadStart@8 + 81 bytes

--

[Jay Bazuzi]

The RTL (run time library) is trying to tell you that you're doing something
wrong in the heap. It will spew a message to the output window that should
give you more info.

Note that this will only give you this info when you launch under the
debugger on NT. You get a special "debug heap" in that situation.

It looks like this code is triggered by something in another thread. While
in break mode at the crash, use Debug.Threads to check them out.

Minh Tuan Luong <lu...@icenet.com.au> wrote in message
news:383E0E64...@icenet.com.au...

[Tomas Restrepo]

Minh,

>
> This is what I get from the call stack! Do you think there is something
> wrong with my code? I don't know where to start to even debug this.
>
> NTDLL! RtlpCoalesceFreeBlocks@16 + 255 bytes
> NTDLL! RtlFreeHeap@12 + 183 bytes
> RPCRT4! operator delete(void *) + 18 bytes
> RPCRT4! WMSG_SASSOCIATION::~WMSG_SASSOCIATION(void) + 43042 bytes
> RPCRT4! WMSG_SASSOCIATION::DealWithCloseMessage(void) + 80 bytes
> RPCRT4! WMSG_ADDRESS::ReceiveLotsaCalls(void) + 901 bytes
> RPCRT4! RecvLotsaCallsWrapper(class WMSG_ADDRESS *) + 9 bytes
> RPCRT4! 77e16821()
> RPCRT4! ThreadStartRoutine(class THREAD *) + 23 bytes
> KERNEL32! BaseThreadStart@8 + 81 bytes

To start up, I suggest you point a breakpoint in the WMSG_ASSOCIATION
destructor, before the call to delete. Then examine what the pointer value
is and track that object down, putting breapoints each time farther down the
call stack. It's a rudimentary way of debugging it, but it works.

Also, I would check the code throuughly, looking for possible heap
corruptions, like a buffer overrun.

One final thing: As aparently you are using multiple threads, make sure you
are linking your app against the Multithreaded or DLL CRT, and that you are
starting the thread using __beginthreadex() instead of CreateThread().

[Minh Tuan Luong]

Hi Tomas,

Thanks again for your reply.

Tomas Restrepo wrote:
>
> Minh,
> >
> > This is what I get from the call stack! Do you think there is something
> > wrong with my code? I don't know where to start to even debug this.
> >
> > NTDLL! RtlpCoalesceFreeBlocks@16 + 255 bytes
> > NTDLL! RtlFreeHeap@12 + 183 bytes
> > RPCRT4! operator delete(void *) + 18 bytes
> > RPCRT4! WMSG_SASSOCIATION::~WMSG_SASSOCIATION(void) + 43042 bytes
> > RPCRT4! WMSG_SASSOCIATION::DealWithCloseMessage(void) + 80 bytes
> > RPCRT4! WMSG_ADDRESS::ReceiveLotsaCalls(void) + 901 bytes
> > RPCRT4! RecvLotsaCallsWrapper(class WMSG_ADDRESS *) + 9 bytes
> > RPCRT4! 77e16821()
> > RPCRT4! ThreadStartRoutine(class THREAD *) + 23 bytes
> > KERNEL32! BaseThreadStart@8 + 81 bytes
>
> To start up, I suggest you point a breakpoint in the WMSG_ASSOCIATION
> destructor, before the call to delete. Then examine what the pointer value
> is and track that object down, putting breapoints each time farther down the
> call stack. It's a rudimentary way of debugging it, but it works.

I should have told you that my program is using COM. So I think is a COM
function call or something and I don't know where the WMSG_ASSOCIATION
destructor is.

> Also, I would check the code throuughly, looking for possible heap
> corruptions, like a buffer overrun.

The error occurs when I shut down one of my client programs. So this
appears to be something to do with freeing up the heap. But most of the
code I have used for writing the basic Client and Server are based on
that in the book Inside COM. The server crashes with the error shown
above when I close the client.

>
> One final thing: As aparently you are using multiple threads, make sure you
> are linking your app against the Multithreaded or DLL CRT, and that you are
> starting the thread using __beginthreadex() instead of CreateThread().
>

Yes, I have changed my code to use _beginthreadex() instead as
recommended, but it does not apparently have any effect in solving my
problem.

[Tomas Restrepo]

Minh,

> I should have told you that my program is using COM. So I think is a COM
> function call or something and I don't know where the WMSG_ASSOCIATION
> destructor is.
>
> > Also, I would check the code throuughly, looking for possible heap
> > corruptions, like a buffer overrun.
>
> The error occurs when I shut down one of my client programs. So this
> appears to be something to do with freeing up the heap. But most of the
> code I have used for writing the basic Client and Server are based on
> that in the book Inside COM. The server crashes with the error shown
> above when I close the client.

Which chapter did you base your code on? Is this on an inproc or out-of-proc
server?

--
Tomas Restrepo
http://members.xoom.com/trestrep/