OllyDbg supports many different types of breakpoints.

INT3 breakpoints

To set INT3 breakpoint, OllyDbg replaces first byte of the 80x86 command by a special code 0xCC (one-byte interrupt with a vector 3, also known as a "trap to debugger"). When CPU executes INT3, it calls OS interrupt handler which in turn reports it as an exception of type EXCEPTION_BREAKPOINT to OllyDbg.

Number of INT3 breakpoints is unlimited. They work only on code. Misplaced INT3 breakpoint (set on data or in the middle of the command) may easily lead to the crash of debugged application. If OllyDbg is not sure whether INT3 breakpoint is allowed, it will ask for confirmation.

There are four kinds of INT3 breakpoints:
One may set all four breakpoints on the same address, and they will be correctly processed.

OllyDbg frequently uses temporary INT3 breakpoints for internal purposes. In the extreme case of hit trace restored from the disk, OllyDbg sets INT3 breakpoint on every traced command.

Hardware breakpoints

80x86 CPUs support 4 hardware breakpoints. Hardware breakpoints can be set on memory read, memory read or write, or on instruction execution. They cover 1, 2 or 4 bytes of memory, and protected memory must be aligned on this size. If execution breakpoint is set on data, or read breakpoint on command, it will make no harm.

Like INT3, hardware breakpoints may be manual, one-shot and temporary. Manual breakpoints may have associated condition and may protocol the values of expressions.

Hardware breakpoints are practically transparent for the debugged application, but they are very scarce. They are slightly faster than INT3. If OllyDbg is allowed to use hadrware breakpoints, it will automatically select INT3 or hardware breakpoint when stepping over instructions.

Memory breakpoints

OllyDbg can set memory breakpoints on read, write and/or on instruction execution. Number of memory breakpoints is unlimited. Note that 80x86 CPU can set memory attributes only on the complete memory pages, 4096 bytes long. Therefore memory breakpoints produce many false breaks and in some cases may be very slow.

Memory breakpoints are user-controlled. They may have associated condition and may protocol the values of expressions.

If kernel attempts to access protected memory page, this may result in the crash of the debugged application. Memory breakpoint on the stack is an absolute no-go.

Guarded pages (breaks on access)

Guarded pages are one-shot breakpoints set on access (read, write or execution) to memory page. Windows report them as an exception of type EXCEPTION_GUARD_PAGE and automatically remove guarding from the touched page. Guarded pages seem to be kernel-safe.

OllyDbg may use guarded pages to pause the debugged application.

API functions:

int Setint3breakpoint(ulong addr,ulong type,int fnindex,int limit,int count,ulong actions,wchar_t *condition,wchar_t *expression,wchar_t *exprtype);
int Removeint3breakpoint(ulong addr,ulong type);
int Enableint3breakpoint(ulong addr,int enable);
int Confirmint3breakpoint(ulong addr);
int Confirmint3breakpointlist(ulong *addr,int naddr);
void Wipebreakpointrange(ulong addr0,ulong addr1);

int Sethardbreakpoint(int index,ulong size,ulong type,int fnindex,ulong addr,int limit,int count,ulong actions,wchar_t *condition,wchar_t *expression,wchar_t *exprtype);
int Removehardbreakpoint(int index);
int Enablehardbreakpoint(int index,int enable);
int Findfreehardbreakslot(ulong type);
int Confirmhardwarebreakpoint(ulong addr);

int Plugintempbreakpoint(ulong addr,ulong type,int forceint3);

int Setmembreakpoint(ulong addr,ulong size,ulong type,int limit,int count,wchar_t *condition,wchar_t *expression,wchar_t *exprtype);
int Removemembreakpoint(ulong addr);
int Enablemembreakpoint(ulong addr,int enable);