Skip to content
Tech News
← Back to articles

Why is the x86 undefined instruction called ud2? Why 2?

read original get The Art of 64-Bit Assembly by Randall Hyde → more articles
Why This Matters

Raymond Chen-style history explains why x86's guaranteed-invalid-opcode instruction is named ud2: it wasn't the first. Before Intel formally defined one, developers relied on undocumented byte sequences (0F FF and 0F B9) that happened to fault, and Intel later standardized them—hence the numbering. It's a small but useful reminder of how compilers use deliberate crashes to catch 'unreachable' code paths.

Key Takeaways
Worth a Look

The Art of 64-Bit Assembly by Randall Hyde — If quirky opcodes like ud2 make you curious about what's really happening under the compiler's output, this book walks through x86-64 assembly from the ground up. It's a great companion for anyone who reads disassembly during crash investigations and wants to understand instruction encoding rather than just recognize it.

See The Art of 64-Bit Assembly by Randall Hyde on Amazon → Affiliate link — we may earn a commission on purchases, at no extra cost to you. Product picked by AI based on this article; it is not a tested recommendation.

If you look at x86 compiler output (or if, like me, you’re looking at a crash caused by some software that tried to detour an API), you may see an instruction ud2 . What’s up with that?

The ud2 instruction is an architecturally undefined instruction, guaranteed to raise an “invalid opcode” exception. Some compilers generate it to mark “unreachable” code, so that if execution somehow manages to reach it, you get a crash rather than executing random instructions. For example, if a function marked [[noreturn]] somehow returns, the compiler will put a ud2 after the call so that the program crashes instead of falling through to the next function.

Anyway, why is this instruction called ud2 instead of just ud ? Was there a ud1 ? What was so wrong about ud1 that we had to make a ud2 ?

I think I can reconstruct what happened.

Originally, there was no architecturally undefined instruction on x86. So people who wanted to force an invalid opcode exception went looking for some byte sequence that reliably raised the invalid opcode exception when executed.

Somebody found that the 0F FF sequence led to an invalid opcode exception. Though, for whatever reason, the instruction internally decoded as if it took two parameters, a register destination and a register-or-memory source. The parameters aren’t actually used because the invalid opcode exception gets raised before anything else can happen.

Meanwhile, somebody else found that the 0F B9 sequence also had the same properties. So you now had two factions, the 0F FF believers and the 0F B9 adherents. There really wasn’t much of a battle between them, because both techniques seemed to work, and it’s not like one was coming at the detriment of the other.

Intel then worked on their next processor, and maybe they made some changes that resulted in 0F FF no longer raising an invalid opcode exception. Maybe they tried introducing a new instruction that uses 0F FF . Or maybe it was still undefined but just performed some random operation instead of raising the invalid opcode instruction. And when they started running software on their new processor, they found that some programs stopped working, and after laborious investigation, they discovered that the programs were relying on 0F FF being an invalid opcode.

In other words, they ran into Hyrum’s Law: With a sufficient number of users, all observable behaviors will be depended upon by somebody. Obligatory XKCD.

A similar discovery was made with 0F B9 .

... continue reading