Windows 10共享内存因不可访问内存崩溃问题排查

从你提供的代码和WinDbg内存转储来看，那些4KB的????????未映射区域几乎和硬盘错误无关——硬盘错误通常会引发I/O异常而非虚拟地址未映射的问题。更可能是共享内存的创建、映射或跨进程交互过程中出现了问题，下面是几个最值得排查的方向：

1. 共享内存大小的页对齐与参数传递错误 #

Windows的虚拟内存管理是以4KB页为基本单位的，CreateFileMapping会自动将你指定的大小向上对齐到最近的页边界。但这里有两个潜在坑：

• 你传递的nSharedMemorySize如果超过了DWORD的取值范围（即大于4GB），仅用DWORD(nSharedMemorySize)会截断高位数据，导致实际创建的共享内存远小于你需要的大小。后续写入时，超出实际分配页的区域就会变成未映射的无效地址。
• 务必检查CreateFileMapping的返回值！如果因为权限不足、名称冲突等原因创建/打开共享内存失败，hMappedFile会是INVALID_HANDLE_VALUE，此时调用MapViewOfFile可能返回一个看似有效但部分页未映射的错误地址（虽然通常会返回NULL，但极端情况可能出现部分映射的异常）。

2. 共享内存名称冲突导致的对象不匹配 #

你用的共享内存名称是L"some-file-identifier"，如果系统中已有另一个进程用相同名称创建了一个更小的共享内存对象，你的CreateFileMapping会直接打开这个已存在的对象（而非创建新的）。这时候你映射的视图大小是那个更小的对象的大小，当你写入超过该大小的内容时，超出部分的页就是未映射的无效区域，写入自然会崩溃。

解决方法是创建时指定CREATE_NEW标记，强制创建新对象（如果名称已存在则失败），这样能避免意外复用其他进程的共享内存：

HANDLE hMappedFile = CreateFileMapping(
    INVALID_HANDLE_VALUE,
    nullptr,
    PAGE_READWRITE,
    0,
    DWORD(nSharedMemorySize),
    L"some-file-identifier"
);
if (hMappedFile == nullptr || GetLastError() == ERROR_ALREADY_EXISTS) {
    // 处理名称冲突或创建失败
    CloseHandle(hMappedFile);
    hMappedFile = nullptr;
}

3. 映射视图时的变量误用 #

看你的代码，创建共享内存的句柄是hMappedFile，但调用MapViewOfFile时用的是m_hMappedFile——这是不是笔误？如果m_hMappedFile是未初始化的无效句柄，或者指向了其他已被关闭的对象，那么MapViewOfFile返回的视图可能是不完整的，出现部分页未映射的情况。一定要确保映射用的句柄和创建的句柄是同一个有效对象。

4. 其他进程对共享内存的非法操作 #

你怀疑的“其他线程非法释放”可能性较低，因为UnmapViewOfFile是释放整个视图，而非部分页；如果其他进程关闭了共享内存的句柄，只要你的进程还持有句柄，共享内存对象就不会被销毁。但有一种极端情况：某个进程通过特殊操作干扰了共享内存的底层分页文件（虽然你用的是INVALID_HANDLE_VALUE创建的分页文件支持的共享内存，但这种情况非常罕见）。

快速排查步骤 #

1. 立即添加错误检查：在CreateFileMapping和MapViewOfFile后检查返回值，调用GetLastError()获取具体错误码。
2. 验证nSharedMemorySize的计算是否正确，特别是当大小超过4GB时，要正确传递dwMaximumSizeHigh参数。
3. 换一个独一无二的共享内存名称，避免冲突。
4. 用VirtualQuery检查你写入的每个地址的内存状态，确认哪些页是已提交的，哪些是未映射的。

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