When Span<T> Interop Failures Don't Surface Until Production: Tracing Misaligned Pointers

You've shipped. Tests green. Code review passed. Then Tuesday, 3:47 AM — an access violation in a Span<T> slice that only happens under load. The stack trace points to interop code you wrote weeks ago. You rerun the unit test. Nothing. You add logging, deploy to staging. Still nothing. This is the misaligned pointer problem — and it's a beast because the CPU doesn't always complain. Not until alignment actually matters.

I've been there. Chasing a bug that only surfaces on certain hardware, under specific memory pressure. The root cause? A pointer that wasn't aligned to the natural boundary of the type it pointed to. Span<T> is fast, but it trusts you. If you hand it a misaligned reference, it won't check. The runtime might not check either — until the memory access hits an instruction that requires alignment, like SSE or AVX. Then boom. This article is about catching those failures before they reach assembly, and when they do, how to trace them back to the source.

Who Should Read This and What Goes Wrong Without Alignment Awareness

Real-World Symptoms: Random Crashes, Corrupt Data, Silent NaN Propagation

You deploy on a Friday. Monday morning, the on-call phone explodes — intermittent SIGSEGVs, heap corruption that only surfaces under load, and that one Span<byte> that sometimes decodes to garbage. No repro in staging. The crash dumps are useless: the offending address looks valid, but when you check the low three bits, there it's — a pointer that should have been 16-byte aligned but sits at 0x…008. That's the signature of misaligned interop. And the really nasty ones? They don't crash. They silently produce NaN values in SIMD paths, or corrupt a single float in a struct, or propagate a wrong hash across a dozen services before anyone notices. I have seen a team spend three weeks bisecting a performance regression before realizing that a custom allocator was returning 4-byte-aligned buffers to a Vector<T> operation — the JIT happily emitted unaligned loads, and throughput halved without any exception. That hurts.

Who's Affected: Interop-Heavy Code, Custom Allocators, SIMD Paths

This isn't a niche problem for embedded systems. You're at risk if you touch any of these: MemoryMarshal.Cast<> between unmanaged types, Unsafe.AsRef on raw pointers from native code, Span<T> backed by Marshal.AllocHGlobal or a pooled array that didn't enforce alignment. Custom allocators are the usual culprit — a slab allocator that returns offsets without padding to the next cache line, or a ring buffer that wraps an IntPtr and hands out slices at odd boundaries. SIMD paths make it more acute: Vector<T> on x64 expects 16-byte alignment by default (though modern hardware tolerates misaligned loads at a performance cost), but Vector128 and Vector256 in hot loops will degrade catastrophically if the runtime decides to use aligned instructions. What usually breaks opening is the interaction between Span<T> and fixed buffers or stackalloc — the former guarantees alignment only for the primary element, and if you cast to a larger type, boom.

'We only had 27 lines of interop code. The bug was in the last place we looked: the pointer was 8-byte aligned, but AVX2 wanted 32. CPU didn't complain — it just ran 4x slower and gave wrong results on every third call.'

— Senior engineer, after a post-mortem that started with 'impossible' and ended with 'of course'

Why It's Easy to Miss: Alignment Requirements Differ by CPU, OS, and Runtime Version

The catch is that no single environment guarantees the same behavior. Your dev machine's Intel Core i9 handles unaligned loads with grace — the hardware retries the load, splits the access, and your tests pass. The ARM64 instance in manufacturing? It traps on unaligned access by default, and the OS delivers SIGBUS or a silent fix-up that varies by kernel version. Even .NET itself has changed: Span<T> in .NET Core 3.0 through .NET 6 had different JIT heuristics for when to emit aligned vs. unaligned SIMD instructions. Most teams skip this — they test on one architecture, one runtime, one allocator. And the worst part? A misaligned pointer in a Span<T> that's passed through synchronous code might fix itself under contention or GC compaction, only to fail when the thread count changes. Not yet a output issue? Wait until the next patch Tuesday updates the runtime's alignment guarantees for your platform. Then you get random NaN propagation — the kind that doesn't throw, doesn't log, just silently poisons every calculation downstream.

Prerequisites: What You Need to Know Before Tracing Pointer Alignment

Understanding CPU Alignment Requirements and Natural Boundaries

Every modern CPU insists that certain types sit at memory addresses divisible by their size. A 4-byte int wants an address divisible by 4; an 8-byte long demands alignment to 8. That's not pedantry—it's physics. Misaligned access either traps (ARM) or slows to a crawl (x86 with split-cache-line penalties). I once watched a team's throughput drop 40% because an interop buffer landed on an odd byte boundary. The CPU didn't crash. It just quietly retired instructions at half speed.

The tricky bit is that Span<T> doesn't enforce alignment for you. It's a view, not a validator. You can create a Span<int> from a byte* at offset 3—the compiler won't complain. The runtime won't throw. Only the profiler or a output hang will reveal the cost. Natural boundaries matter especially when marshalling to SIMD intrinsics or native libraries that expect cache-line-aligned buffers. Wrong order? You lose a day bisecting.

.NET Memory Model: Pinned Objects, GC, and Object Header Overhead

Most teams skip this until a crash. The GC compacts memory, and when you pin an object, you freeze its address—but you still get the object header before your data. A byte[] starts 8 bytes (x64) after the object reference due to the sync block and method table pointer. If you blindly take &array[0] and pass that to native code expecting a contiguous struct, you're handing over a pointer that's off by a header. That hurts.

What usually breaks opening is Marshal.UnsafeAddrOfPinnedArrayElement or MemoryMarshal.GetReference—both skip the header correctly, but only if you understand what they return. I've fixed output failures where the team used fixed blocks inside a loop, re-pinning each iteration. Not only does that fragment the GC heap, it risks moving the underlying object mid-operation. The Span<T> pattern handles pinning more elegantly, but misalignment still slips in when you cast a Span<byte> to Span<SomeStruct> without verifying the pointer offset.

"The most expensive bug is the one that passes all unit tests and then fails on the second Tuesday after deployment."

— paraphrased from a debugger log I still have framed

Basic Span<T> and MemoryMarshal Usage Patterns

MemoryMarshal.Cast<byte, int> looks like magic. It's not. It reinterprets the bytes as a different type without copying—zero overhead, zero safety nets. The catch: if the underlying byte span doesn't start at an int-aligned address, the runtime may throw ArgumentException on some platforms or silently produce misaligned references on others. The behavior depends on the JIT and the hardware. Honestly, this inconsistency is the worst kind of bug—it passes your dev machine, passes CI, then blows up on an ARM64 output node.

How do you check alignment before casting? Use (int)(ptr) & (sizeof(T) - 1) == 0. If the pointer's low bits are non-zero, you need to copy or re-base. Most teams don't add this guard. They assume alignment just happens. It doesn't. One concrete pattern I rely on: allocate a buffer with an extra sizeof(T) - 1 bytes, then find the opening aligned address within that region. Wasteful? A little. Safe? Absolutely. The alternative is a assembly trace showing hundreds of thousands of misaligned loads—not a crash, just slow death.

Reality check: name the development owner or stop.

Reality check: name the development owner or stop.

That sounds fine until you realize MemoryMarshal.GetArrayDataReference returns a reference to the primary element, which is header-aligned, not necessarily struct-aligned for odd-sized types. The fix is simple: pin, compute offset, verify alignment, then cast. Skip that verification and you're gambling with your latency budget. I've seen it happen.

Core Workflow: Step-by-Step Tracing of Misaligned Pointers

Step 1: Identify the failing memory access pattern

You don't trace alignment failures—they trace you. The crash dump arrives, the access violation reads 0x7ffe8b2a0003, and !analyze -v says nothing useful. That trailing 0x3 is the initial clue. Misaligned pointers almost always end with an odd offset when the expected alignment is 4 or 8 bytes. Look at the instruction: is it a movaps, vmovdqa, or a simple mov on an unaligned SSE load? If your native library uses aligned SIMD instructions—and most high-perf Span consumers do—the CPU throws a STATUS_DATATYPE_MISALIGNMENT (0x80000002) on x64. I've seen teams waste half a day blaming the network layer. It's not the network. It's a Span<byte> sliced at byte 7, passed to a C function expecting 16-byte alignment. The pitfall is obvious in hindsight: you tested with small, contiguous buffers, but output buffers arrive from pooled arrays where the starting offset shifts.

Step 2: Use hardware breakpoints or data breakpoints in WinDbg

The trick is catching the access before the crash. Set a data breakpoint on the misaligned address: ba w8 0x7ffe8b2a0003 in WinDbg. That watches for writes of 8 bytes at the offending location. Re-run the operation. The debugger halts on the exact instruction that touches the unaligned pointer. Most teams skip this step—they scan the stack trace, see Span<T>.PinningHelper, and assume it's a GC pinning issue. It's not. The real signal is the MemoryMarshal.GetReference call that produced the span. Check the reference's offset modulo the element size: .println (poi(@rcx) & 0xF). If that remainder isn't zero for a 16-byte-aligned type like Vector128<byte>, you've found your culprit. The trade-off: data breakpoints slow execution to a crawl—expect 100x slower runs. That's fine. You're fishing for one bad access among millions of good ones.

I once traced a misalignment that surfaced only when the GC compacted heap—the pointer shifted by two bytes, and the SIMD path silently corrupted adjacent memory.

— assembly incident post-mortem, cloud rendering pipeline

Step 3: Validate alignment with MemoryMarshal and runtime checks

Don't wait for the breakpoint. Insert defensive validation at the boundary where managed Span meets native code. Before calling Unsafe.AsPointer or pinning the span, compute MemoryMarshal.GetReference(span) % sizeof(T). If the remainder is non-zero, log the caller's call stack and the offset within the source buffer. A simple Debug.Assert won't cut it—assertions disappear in Release builds. Instead, use if (RuntimeInformation.ProcessArchitecture == Architecture.X64) CheckAlignment(...). The catch is that alignment requirements differ per platform: ARM64 throws exceptions on any unaligned access, x64 silently fixes most misalignments but kills performance, and x86 with SSE raises faults only for specific instructions. I hard-code a [Conditional("TRACE_ALIGNMENT")] method that dumps the misaligned pointer and the Span's origin—usually a rented array from ArrayPool<T>.Shared—where GetHashCode on the array tells you which rental pattern produced it. That's the actionable signal. The runtime check isn't free—about 30 nanoseconds per call—but it's cheaper than a Sev-1 incident.

Tools and Environment: What You'll Need for Effective Tracing

Debugging with WinDbg, SOS, and data breakpoints

You can stare at source code all day—misalignment won't wave a red flag in C#. It's when the bits hit silicon that things splinter. WinDbg is the atomic scalpel here. Attach it to the process, load SOS via .loadby sos coreclr, and start poking at managed objects that wrap unmanaged memory. The real trick? Data breakpoints. Set one on the Span<byte>'s _reference field—the raw pointer—and pause execution the moment something writes to it. That catches both your code and any JIT-introduced offset miscalc.

I have watched teams burn two hours because they assumed Marshal.UnsafeAddrOfPinnedArrayElement returns a cacheline-aligned address. It doesn't guarantee 16-byte alignment—only that it's word-aligned. So you spin up a breakpoint triggered on a ba w8 0x7ff...c address, step through the interop call, and watch the pointer land at 0x4 mod 16. The machine stalls. Not a crash—just a retry storm. The SOS !DumpObj command shows the exact offset; !DumpVC reveals the unmanaged struct layout. Without these, you're guessing.

The catch: data breakpoints on the _reference field only fire if the pointer actually mutates—so for read-only misalignment you need a different approach. Still, for writes that corrupt adjacent memory, this is your initial line. Most teams skip this step and go straight to log analysis. Don't.

Using CET (Control-flow Enforcement Technology) and Guard pages

Hardware can do the watching for you—if you configure it. Intel's CET shadow stack won't detect a misaligned pointer per se, but it will blow up on an indirect call target that's misaligned. That's useful when your Span-encoded function pointer gets mangled by a 3-byte offset. Enable CET via SetProcessMitigationPolicy with ProcessShadowStackPolicy and run your interop tests under it. The access violation that surfaces is explicit: 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN). Not subtle.

Guard pages are dirtier but faster. Reserve a virtual memory region, commit it, then mark the pages immediately before your buffer as PAGE_NOACCESS. Any read or write that strays one byte past your aligned allocation faults instantly. Pair this with the VirtualAlloc MEM_TOP_DOWN flag to randomize page alignment—you catch the off-by-one cases that only appear on certain memory layouts. That hurts less in assembly than a silent heap corruption.

Honestly—hardware mitigation costs. CET adds ~3% overhead on hot paths. Guard pages fragment your address space. Worth it during QA; disable for release builds unless your interop surface is tiny and high-risk.

Logging alignment violations with minimal overhead

manufacturing tracing can't stop the world. You need a TraceListener that hooks Marshal.AllocHGlobal and logs the pointer mod-N remainder—zero overhead when disabled via #if DEBUG or a runtime toggle. The pattern is simple: allocate, compute (long)ptr & 0xF, and if nonzero, emit a DiagnosticSource event with the caller's stack. One microsecond cost per allocation. That's noise.

Better: wrap every interop call in a Span constructor that checks alignment once, then bakes the result into a static bool flag. Subsequent calls skip the check entirely. I built this for a media pipeline where 60,000 frames per second crossed into a C library—the check was 4 CPU cycles per frame, but the absence of it cost us a three-day outage when a new server model had different cacheline boundaries. We fixed this by adding a one-time alignment stamp to each pooled buffer.

Odd bit about development: the dull step fails initial.

Odd bit about development: the dull step fails opening.

“One misaligned read in a tight loop isn't a crash—it's a 3x latency multiplier that looks like a network problem.”

— former colleague who spent a week blaming the kernel

What usually breaks opening is the logging itself: string.Format inside a hot interop path. Use int.TryFormat or a pre-allocated char buffer. Keep the payload under 128 bytes. Anything larger stalls the allocator and masks the very misalignment you're hunting.

Variations: Different Interop Scenarios and Their Alignment Pitfalls

Calling into native libraries via P/Invoke or COM

The classic trap: you write a clean P/Invoke signature, pass a Span<byte> pinned with fixed or GCHandle, and the native side receives a pointer that looks valid — until it touches data at offset 4. On x64, most allocations from the managed heap arrive 8-byte aligned, so your span usually lands safely. But COM interop changes the game. I once helped a team whose COM server read a binary header where the primary field was a 32-bit integer followed by a 64-bit integer. The StructLayout(LayoutKind.Sequential, Pack=1) marshaled fine on the managed side; the native side read garbage for the 64-bit field every third call. The culprit? The COM apartment marshaller re-aligned the buffer to its own rules — it inserted padding where the original structure had none. That hurts. The fix wasn't changing the struct layout; it was allocating the buffer with Marshal.AllocCoTaskMem and manually writing each field at the correct byte offset.

What usually breaks initial is a union — or anything relying on FieldOffset to overlay types. The native DLL expects the span's backing memory to match a C union, but the CLR's marshaller sees the managed struct and copies fields sequentially, padding gaps. You end up with misaligned reads that silently succeed on your dev machine because the JIT happens to lay out the struct differently than the native code expects. The trade-off: you can either disable marshaling entirely (use UnmanagedCallersOnly with raw pointers) or accept the performance hit of a manual copy loop. Neither is clean. I've grown to prefer the raw-pointer path — it's uglier to write but it surfaces alignment failures at the call site, not three stack frames deep.

Using SIMD intrinsics (Vector128, Vector256) with Span<T>

SIMD instructions demand alignment — 16 bytes for Vector128, 32 bytes for Vector256. Give them a misaligned span, and on x86 you get a silent performance regression (the CPU takes an alignment assist micro-fault). On ARM64 you get DataAbort. The catch is that MemoryMarshal.Cast<byte, Vector256<byte>>(span) doesn't check alignment at all — it just reinterprets the reference. The first load works; the second, third, or fourth load blows up depending on where the span starts relative to a cache line. Not yet. Most teams skip this: they test with small buffers that happen to align, then ship to manufacturing where the buffer is an odd-sized slice from a larger pool. I saw a real-time audio pipeline that used Vector128 to process 32-sample chunks. The first 128 calls worked fine. Call 129? The span was misaligned by 8 bytes, and the audio output turned into a buzz. The fix was brutally simple — we aligned the initial buffer allocation to 32 bytes using NativeMemory.AlignedAlloc — but finding it cost three days of stepping through disassembly.

The editorial takeaway: don't trust Span<T> alignment for SIMD unless you own the allocation site. If the span comes from a library, a pooled array, or a native interop call, pin it and check (ulong)ptr % (uint)Vector256.Count before any vectorized loop. One assertion saves hours.

“The runtime won't warn you. The CPU won't crash—until it does. Alignment faults are the silent production killers.”

— field notes from a postmortem, 2023

Marshaling structs with explicit layout (StructLayout, Pack)

Here alignment failures are baked into your type definition. A [StructLayout(LayoutKind.Explicit)] with Pack=1 tells the CLR to ignore natural alignment and pack fields tightly. That's fine for data interchange — until you pass a Span<T> of those structs to a method expecting Vector128-aligned entries. The first element loads correctly; the second element starts at offset 9 (if the struct is 9 bytes) and that 16-byte load crosses a page boundary. The runtime's Span bounds check passes — the span length is correct — but the SIMD instruction faults because of alignment + page crossing. Most teams catch this only after a crash dump shows EXCEPTION_ACCESS_VIOLATION with a movdqa instruction in the callstack. The fix? Either change Pack to match the natural alignment of the largest field (usually 4 or 8), or accept the struct size bloat. That's the trade-off: packed structs save memory but break SIMD; aligned structs waste bytes but survive vectorization. Which matters more? Measure before you decide. I've seen teams lose a day optimizing struct packing, then lose two more debugging the production crash.

Pitfalls and Debugging: What to Check When Things Go Wrong

False positives: when alignment checks report misalignment that's actually fine

Nothing wastes an afternoon like a tool yelling "misaligned pointer" at a perfectly valid span. I've been there—spent three hours hunting a phantom bug because a debugger overlay showed an odd address on a pinned object. The catch: some alignment checkers don't account for the GC's actual behavior. They see an 8-byte boundary, flag it, and you tear down perfectly good code. The real culprit? The GC does guarantee object alignment on the heap—usually 8 or 16 bytes—but ref T fields inside structs can shift. Your span's internal pointer might be aligned relative to its memory block, not absolute. Run Unsafe.AreSame against the original allocation, not a raw address. That silences the false alarm.

Another red herring: Span<byte> from a stackalloc buffer. Stack frames align differently than heap objects—sometimes 4-byte alignment on x86, sometimes 16-byte with AVX-accelerated code. A misalignment warning here is often noise. Check RuntimeInformation.OSArchitecture and the JIT's SIMD policy for the method. You'll cancel more false positives than you'll catch real bugs.

Performance vs. safety trade-offs in debug vs. release builds

Debug builds pad everything with extra bounds checks. Release builds strip them. That's fine—until alignment-sensitive interop behaves differently under the debugger. I watched a team ship a Span<byte> to a native library that required 16-byte alignment. In Debug, JIT inserted no-ops that accidentally aligned the buffer. Release? Moved code around, alignment broke, and production returned garbage. The fix: test alignment in release config only, but validate with #if DEBUG assertions that dump the address. One line saves your weekend.

The trade-off bites hardest with AVX intrinsics. Debug builds let you slide with 8-byte alignment because the code path rarely uses vmovdqa. Release hits the fast path—segfault or silent data corruption. Don't trust debug-mode passes. Write a small release-only harness that calls your interop in a loop, checking for alignment drift across thread switches. That's where the seam blows out.

Common mistakes: assuming GC heap alignment, forgetting about array padding

Most teams assume new byte[1024] lands on a natural boundary. Wrong order. The GC returns aligned memory for the object header, but the data payload starts after that header. For arrays, the CLR adds padding between the length field and the first element—typically 4 bytes on 64-bit. So MemoryMarshal.GetReference might give you a pointer that's off by 4. That hurts when native code expects 8-byte alignment for an int64 struct.

Not every development checklist earns its ink.

Not every development checklist earns its ink.

‘We shipped a packet parser that crashed every 500th request. Turns out the array padding shifted the span pointer by exactly four bytes. Native memcpy just ate the shift silently.’

— lead engineer on a network telemetry project, debugging a production incident

What usually breaks first is struct interop across Marshal.PtrToStructure or Unsafe.As<byte, MyStruct>. If your struct has [StructLayout(LayoutKind.Explicit)] with overlapping fields, alignment requirements compound. The fix: pin the span with fixed and check ((nint)ptr % sizeof(T)) != 0 after the pin—not before. Pre-pin addresses lie. Post-pin tells the truth.

Honestly—most alignment bugs aren't exotic. They're the result of forgetting that Span<T> from a sliced array inherits the original's alignment offset. Slice twice and suddenly your pointer is odd. Validate at the interop boundary with a small helper: SpansAreAlignedFor<T>(Span<T> span, int requiredAlignment). Call it once, right before the native call. That's it. One check saves three rollbacks.

FAQ: Quick Answers to Alignment Questions You'll Have

Does .NET guarantee Span<T> alignment?

No, and you can't assume it does. Span<T> is a managed-safe abstraction over arbitrary memory — native heap, stackalloc, pinned arrays — and .NET never inserts padding unless the underlying allocator does. I've watched teams assume MemoryMarshal.Cast<byte, long>() gives aligned long references automatically. It doesn't. The runtime checks alignment only when you call certain Unsafe APIs or interop methods that demand it. Span<T> itself is a view, not a contract. You're responsible for verifying the address.

Why does misalignment only fail on some CPUs?

The x86 lineage is terrifyingly forgiving. Intel and AMD have handled unaligned loads in hardware for decades — at a speed penalty, sure, but rarely a crash. That changes the moment your production nodes shift from development laptops to ARM-based servers or certain embedded x86 configurations where alignment faults are fatal. We fixed this by running integration tests on an AWS Graviton instance, and the first run threw AccessViolationException inside a serialization hot path that had been "stable" for months. The catch: your CI probably runs on Intel. That is why you see zero failures locally and a production pager at 3 AM.

So I add alignment assertions — won't they tank throughput?

Only if you're naive about where you assert. A Debug.Assert((long)ptr % sizeof(T) == 0) inside a loop that processes one million elements is a disaster — branch mispredictions, instruction cache thrash. Instead, assert at the entry point of your interop boundary, once per call. We use a [Conditional("TRACE_ALIGN")] helper that flips to a no-op in Release builds. Most teams skip this: they either assert everywhere (slow) or nowhere (risky). The middle path is a single check before the first access, logged with a high-resolution timestamp. That gives you production profiling without killing throughput. One concrete anecdote: a team I worked with added this check to a packet parser and found that one misaligned int read added 6 µs per call — invisible in isolation, catastrophic at 50,000 requests per second.

'The CPU is a liar — it hides alignment faults until the business is on fire.'

— lead engineer, fintech data pipeline postmortem

Can I force alignment with stackalloc?

Partly, but you're trading one footgun for another. stackalloc gives you 4-byte alignment on x64 by default — fine for int, useless for Vector128<byte> or double arrays. The fix is NativeMemory.AlignedAlloc for heap allocations, or Unsafe.SkipInit with manual alignment tricks on the stack. That said, over-alignment bloats memory. The real pitfall: if you pipe that aligned buffer through Span<byte> and then slice it, you lose the alignment guarantee. The span doesn't track the original alignment offset. I've seen that seam blow out in a SIMD image filter — the first 10 pixels processed fine, then byte 11 started with a misaligned instruction. That hurts to debug.

What about fixed statements and pinned arrays?

Pinning an array with fixed gives you the raw address of the data, but the CLR may place the object header before it. That header forces the data portion's alignment to be at most 8 bytes on a 64-bit system, regardless of element size. So if you pin a byte[] and cast the pointer to long*, you're gambling. The first element lands at offset 0 relative to the data — aligned to 8 bytes by the GC's design — but if you advance by an odd number of bytes, you're unaligned. Wrong order: pin first, then check alignment. Right order: check the alignment of the pinned pointer before you cast it to anything wider than byte.

Next action — stop guessing

Add a single alignment assertion at your interop boundary today. Use Debug.Assert in debug builds, a #if TRACE_ALIGN log in staging, and a one-time startup check that prints the alignment status of your most critical Span sources. Run your interop test suite on an ARM machine before your next deployment. You'll either find zero issues (great — ship it) or one ugly surprise you can fix before it surfaces in production at 3 AM. Don't let the CPU's lie become your production postmortem.

Next Steps: Concrete Actions to Prevent Production Failures

Enable Alignment Checks in Debug Builds

Flip the switch today. In .NET, set DOTNET_EnableWriteXorExecute=0 alongside DOTNET_GCStress=0xC in debug config—this combo catches misaligned Span<T> pointers before they corrupt your heap. I've seen teams skip this because "it slows down iteration." It does. That's the point. A debug build that runs 3× slower but surfaces a NullReferenceException on an invalid MemoryMarshal.Cast beats a production build that silently overwrites adjacent memory. The trade-off? False positives from overly aggressive alignment checks—you'll need to whitelist known-unaligned interop handles (like video frame buffers). But start with the strictest policy and relax only after tracing each violation.

Add Stress Tests with Randomized Memory Offsets

Most unit tests allocate fresh buffers on clean 8-byte boundaries—so your interop code never actually faces a misaligned pointer. That's a mirage. Write a test harness that takes your core Span<byte> to Span<MyStruct> conversion and forces Marshal.UnsafeAddrOfPinnedArrayElement to return an offset of 1, 2, or 3 bytes. Honestly—do this in a loop with random jitter. The catch is that randomized offsets can mask real bugs if your struct padding happens to tolerate 2-byte misalignment. So pair each offset run with a memory validation pass: write a known pattern, convert, read back, and assert every field. What usually breaks first is the int field at offset 4—on ARM64 that's an instant SIGBUS. Not a crash you want to debug at 2 AM.

Instrument Production Builds with Lightweight Alignment Logging

You can't run debug checks in prod—the overhead kills throughput. What you can do is slap a single ((long)ptr & (alignmentMask)) != 0 check at the hot-path entry point and log a structured warning (not an exception) when it fires. Keep the payload tiny: pointer address, caller method, and a stack trace hash. One team I worked with saw this flag 40,000 times per hour on a single server—every call was a misaligned read from a native audio buffer that seemed to work on x64. On ARM, it silently corrupted the least significant byte of every other sample. The log let them correlate the issue to a specific driver version. The fallacy? Assuming "it runs fine on dev machines" means alignment is irrelevant. Wrong order. The production instrumentation doesn't fix the bug—it tells you where to dig. Without it, you're guessing.

'We added alignment logging on a Tuesday. By Wednesday afternoon we had three pull requests fixing the same root cause in different layers of the stack.'

— Staff engineer, audio processing pipeline