Bug

In src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/StackWalk/Context/AMD64/AMD64Unwinder.cs, the epilogue emulation code for single-byte pop r64 instructions (registers 0–7) reads the register number from the wrong byte offset.

The Problem

On x64, a pop r64 instruction for registers 0–7 is a single byte: 0x58 + register (e.g., pop rbx = 0x5b). The register number is encoded in the low 3 bits of that opcode byte itself.

At line 479, during epilogue emulation (the block starting around line 470 where inEpilogue is true), the code reads:

byte registerNumber = (byte)(ReadByteAt(nextByte + 2) & 0x7);

This reads 2 bytes past the pop instruction, which is some unrelated instruction byte. It should read from nextByte itself:

byte registerNumber = (byte)(ReadByteAt(nextByte) & 0x7);

Reference: Native Implementation

The native C++ unwinder in src/coreclr/unwinder/amd64/dbs_stack_x64.cpp correctly does:

RegisterNumber = NextByte[0] & 0x7;

Impact

This causes the wrong register to be restored during epilogue unwinding on x64. For example, if the instruction is pop rbx (0x5b), instead of restoring register 3 (rbx), the code reads whatever byte is at controlPC + 2 and uses its low 3 bits as the register index. This corrupts the unwound context, which can cascade into incorrect instruction pointers in subsequent frames, potentially causing divergence between the cDAC and native DAC stack walks.

Fix

In the epilogue emulation section of AMD64Unwinder.Unwind() (around line 479), change:

byte registerNumber = (byte)(ReadByteAt(nextByte + 2) & 0x7);

to:

byte registerNumber = (byte)(ReadByteAt(nextByte) & 0x7);

This matches the native unwinder behavior and correctly extracts the register number from the pop opcode byte.