Regarding 0xCC
and 0xCD
in particular, these are relics from the Intel 8088/8086 processor instruction set back in the 1980s. 0xCC
is a special case of the software interrupt opcode INT
0xCD
. The special single-byte version 0xCC
allows a program to generate interrupt 3.
Although software interrupt numbers are, in principle, arbitrary, INT 3
was traditionally used for the debugger break or breakpoint function, a convention which remains to this day. Whenever a debugger is launched, it installs an interrupt handler for INT 3
such that when that opcode is executed the debugger will be triggered. Typically it will pause the currently running programming and show an interactive prompt.
Normally, the x86 INT
opcode is two bytes: 0xCD
followed by the desired interrupt number from 0-255. Now although you could issue 0xCD 0x03
for INT 3
, Intel decided to add a special version--0xCC
with no additional byte--because an opcode must be only one byte in order to function as a reliable 'fill byte' for unused memory.
The point here is to allow for graceful recovery if the processor mistakenly jumps into memory that does not contain any intended instructions. Multi-byte instructions aren't suited this purpose since an erroneous jump could land at any possible byte offset where it would have to continue with a properly formed instruction stream.
Obviously, one-byte opcodes work trivially for this, but there can also be quirky exceptions: for example, considering the fill sequence 0xCDCDCDCD
(also mentioned on this page), we can see that it's fairly reliable since no matter where the instruction pointer lands (except perhaps the last filled byte), the CPU can resume executing a valid two-byte x86 instruction CD CD
, in this case for generating software interrupt 205 (0xCD).
Weirder still, whereas CD CC CD CC
is 100% interpretable--giving either INT 3
or INT 204
--the sequence CC CD CC CD
is less reliable, only 75% as shown, but generally 99.99% when repeated as an int-sized memory filler.

Macro Assembler Reference, 1987