托管进程写入共享内存时遭异常终止会导致结构体部分写入吗？

Great question—this is one of those edge cases that’s tough to replicate but critical for building reliable IPC systems with shared memory. Let’s break this down clearly:

首先，CER的保护范围有边界 #

CER (Constrained Execution Region) is designed to guard against .NET runtime-level interruptions like thread aborts, unhandled managed exceptions, or garbage collection pauses during critical operations. It ensures that either the entire protected code block runs to completion, or none of it does—preventing partial state changes from managed-level failures.

But here’s the key: operating system-level process termination bypasses CER entirely. When the OS kills a process (e.g., via Task Manager, taskkill /F, or low-memory termination), it doesn’t give the .NET runtime or your code any chance to finish executing, clean up, or trigger CER safeguards. The process’s memory space is immediately marked for release, so any in-progress memory writes can be left in a partial state.

结构体写入的原子性是另一个关键 #

Whether you get partial writes also depends on your struct’s size and alignment:

• Atomic writes: If your struct is the size of a native CPU word (4 bytes on 32-bit systems, 8 bytes on 64-bit) and properly aligned, the CPU itself guarantees atomicity. Even if the process is killed mid-write, the struct will either be fully written or in its original state—no partial updates.
• Non-atomic writes: For larger structs (e.g., multiple fields spanning 16+ bytes), the runtime will split the write into multiple CPU operations. In this case, an OS-level termination can absolutely leave the struct in a partially written state, regardless of CER protection.

如何避免这种风险 #

Since you can’t control OS-level process termination, you need defensive design patterns in your shared memory ring buffer:

• Add a validation marker: Include a version number, checksum, or "completed" flag in your struct. Write the struct content first, then atomically set the marker (or vice versa: set a "writing in progress" flag, write the struct, then clear the flag). Readers should only process structs where the marker confirms a complete write.
• Use atomic operations for critical fields: For structs with critical fields, use Interlocked class methods to update them atomically. This won’t help with the entire struct, but it can prevent partial updates to individual high-stakes values.
• Ring buffer entry fencing: Design your ring buffer so each entry has a clear "occupied" or "ready" state tracked via atomic indices. Readers only advance their read pointer when an entry is marked as fully written.

模拟测试的小技巧 #

You’re right that this is hard to replicate consistently, but here are a few tricks:

• Attach a debugger to the writing process, set a breakpoint in the middle of the struct write, then immediately kill the process via Task Manager or taskkill /F.
• Add a short Thread.Sleep(1) in the middle of your struct write (only for testing!) to increase the window where termination can hit a partial state, then automate killing the process during that sleep.

内容的提问来源于stack exchange，提问作者Thomas Zeman