User BreakPoint problem 
Author Message
 User BreakPoint problem

I am using visual studio 6 to remote debug a dll being
called using LoadLibrary() from an executable that is
compiled as release. The dll is compiled for debug.
Shortly after I start debugging I get "User breakpoint
called from code" in NTDLL. They are "Heap block modified
past requested size" errors. I would like to ignore these
errors and not break until I get to the dll.(So i can look
at source code instead of assembler) Is it possible to
disable these breakpoints.


Sat, 27 Nov 2004 05:54:15 GMT  
 User BreakPoint problem

Quote:

> I am using visual studio 6 to remote debug a dll being
> called using LoadLibrary() from an executable that is
> compiled as release. The dll is compiled for debug.
> Shortly after I start debugging I get "User breakpoint
> called from code" in NTDLL. They are "Heap block modified
> past requested size" errors. I would like to ignore these
> errors and not break until I get to the dll.(So i can look
> at source code instead of assembler) Is it possible to
> disable these breakpoints.

These breakpoints indicate that your program corrupts
memory. Instead of disabling them you should debug
the problem.

Here's how to debug such things. Let's say you have this
code:

    HANDLE hHeap = GetProcessHeap();
    char * p = (char *) HeapAlloc (hHeap, 0, 10);
    p [10] = '\0';  // buffer overrun
    HeapFree (hHeap, 0, p);

When you run it under de{*filter*}, NT debug heap will
dump the following message and break in:

HEAP[test.exe]: Heap block at 00132D08 modified at 00132D1A past requested
size of a

Look at the corrupted block:

00132D08  00090005  001E0700  BAADF00D  BAADF00D
00132D18  AB00FEEE  ABABABAB  FEEEABAB  FEEEFEEE

First two DWORDs here are the heap block header.
The next 10 bytes are the user data (filled with BAADF00D
initially). 6 bytes after that are guard bytes and should be filled
with 0xAB. As you can see, the first byte is 0x0 instead - this
is what caused the breakpoint.

Sometimes you can identify the problem simply by looking at
the memory. If that's not possible then you can try enabling
full pageheap for your program and running under de{*filter*}.
In many cases pageheap will detect corruption immediately
when it happens (as opposed to when free() is called).



Sat, 27 Nov 2004 08:40:40 GMT  
 User BreakPoint problem
James,

To answer your original problem, once you have fixed the
heap overruns, I find the easiest way to do this sort of
thing is to actually code in a break point.  I use it to
debug eg a COM object being called from Word.

either enter a line of code:

  DebugBreak()

or, on Intel boxes/comilers:
  __asm int 3;

and rebuild.  The library will run until it reaches this
code, at which point you will get a message saying that a
user breakpoint has been reached.  Choose the option to
enter the de{*filter*}, and a new copy of VC will open set to
your coded breakpoint.

Cheers,
Stephen

Quote:
>-----Original Message-----

>> I am using visual studio 6 to remote debug a dll being
>> called using LoadLibrary() from an executable that is
>> compiled as release. The dll is compiled for debug.
>> Shortly after I start debugging I get "User breakpoint
>> called from code" in NTDLL. They are "Heap block
modified
>> past requested size" errors. I would like to ignore
these
>> errors and not break until I get to the dll.(So i can
look
>> at source code instead of assembler) Is it possible to
>> disable these breakpoints.

>These breakpoints indicate that your program corrupts
>memory. Instead of disabling them you should debug
>the problem.

>Here's how to debug such things. Let's say you have this
>code:

>    HANDLE hHeap = GetProcessHeap();
>    char * p = (char *) HeapAlloc (hHeap, 0, 10);
>    p [10] = '\0';  // buffer overrun
>    HeapFree (hHeap, 0, p);

>When you run it under de{*filter*}, NT debug heap will
>dump the following message and break in:

>HEAP[test.exe]: Heap block at 00132D08 modified at

00132D1A past requested

- Show quoted text -

Quote:
>size of a

>Look at the corrupted block:

>00132D08  00090005  001E0700  BAADF00D  BAADF00D
>00132D18  AB00FEEE  ABABABAB  FEEEABAB  FEEEFEEE

>First two DWORDs here are the heap block header.
>The next 10 bytes are the user data (filled with BAADF00D
>initially). 6 bytes after that are guard bytes and should
be filled
>with 0xAB. As you can see, the first byte is 0x0 instead -
 this
>is what caused the breakpoint.

>Sometimes you can identify the problem simply by looking
at
>the memory. If that's not possible then you can try
enabling
>full pageheap for your program and running under de{*filter*}.
>In many cases pageheap will detect corruption immediately
>when it happens (as opposed to when free() is called).

>.



Fri, 03 Dec 2004 19:23:32 GMT  
 User BreakPoint problem



Quote:

> > I am using visual studio 6 to remote debug a dll being
> > called using LoadLibrary() from an executable that is
> > compiled as release. The dll is compiled for debug.
> > Shortly after I start debugging I get "User breakpoint
> > called from code" in NTDLL. They are "Heap block modified
> > past requested size" errors. I would like to ignore these
> > errors and not break until I get to the dll.(So i can look
> > at source code instead of assembler) Is it possible to
> > disable these breakpoints.

> These breakpoints indicate that your program corrupts
> memory. Instead of disabling them you should debug
> the problem.

> Here's how to debug such things. Let's say you have this
> code:

>     HANDLE hHeap = GetProcessHeap();
>     char * p = (char *) HeapAlloc (hHeap, 0, 10);
>     p [10] = '\0';  // buffer overrun
>     HeapFree (hHeap, 0, p);

> When you run it under de{*filter*}, NT debug heap will
> dump the following message and break in:

> HEAP[test.exe]: Heap block at 00132D08 modified at 00132D1A past requested
> size of a

> Look at the corrupted block:

> 00132D08  00090005  001E0700  BAADF00D  BAADF00D
> 00132D18  AB00FEEE  ABABABAB  FEEEABAB  FEEEFEEE

> First two DWORDs here are the heap block header.
> The next 10 bytes are the user data (filled with BAADF00D
> initially). 6 bytes after that are guard bytes and should be filled
> with 0xAB. As you can see, the first byte is 0x0 instead - this
> is what caused the breakpoint.

> Sometimes you can identify the problem simply by looking at
> the memory. If that's not possible then you can try enabling
> full pageheap for your program and running under de{*filter*}.
> In many cases pageheap will detect corruption immediately
> when it happens (as opposed to when free() is called).

Hi Pavel,

What's pageheap and how to use it?

Thanks, Bull



Sat, 04 Dec 2004 08:18:34 GMT  
 User BreakPoint problem

Quote:

> What's pageheap and how to use it?

Pageheap is used to debug various heap related problems,
such as buffer overruns and using freed memory.

Pageheap is not a separate tool - it' implemented in the OS.
To enable it, you set some flags in the registry. This causes
ntdll.dll to switch to a different implementation of the win32
heap APIs. This implementation performs various checks
and breaks into de{*filter*} if something is wrong.

The flags in the registry are usually set using a tool like
gflags.exe from http://www.*-*-*.com/
(type gflags -p -? for a list of all options).

The name "pageheap" comes from the fact that in full mode
(using /full option) every allocation is placed at the end of
a physical page, and the following page is made inaccessible.
As a result if an application attempts to read or write to the
memory beyond the allocated size, it gets an access violation.



Tue, 07 Dec 2004 04:18:43 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Very strange problem - User breakpoint

2. Unhandled Exception:User Breakpoint Message

3. User breakpoint called from code at 0x77fa018c

4. Mysterious user breakpoint?

5. user breakpoint

6. User breakpoint from code ad 0x77f9f9df

7. user breakpoint

8. user breakpoint in DBGHEAP.c

9. User Breakpoint in WS2_32.DLL

10. user breakpoint

11. User breakpoint called from ...

12. Unexplicable User breakpoint called at 77F9EEA9 - exact error someone else had posted

 

 
Powered by phpBB® Forum Software