前一遍说到了为什么访问内存会越界，以及我们是如何找到根本原因的。
在知道为什么有越界访问之后，我们下一个问题是：为什么第一次调用mapviewoffile会失败？为什么第二次调用mapviewoffile会成功了？
查阅了msdn一下。如果在调用MapViewOfFile()的时候，dwNumberOfBytesToMap如果大于文件的size，那么该call就会失败，并且error code是access denied。
这个解释貌似和我们发生的很贴切。因为第一次size太大了，第一次就会失败。但是如果第二次我们指明map到文件末尾，那么就会成功。
但是，我们审阅了我们的代码后，觉得不会发生这样的情况。size是根据文件信息读出来的，因而不会有错。
那会是什么引起的了？
因为message会不断的增加，所以message writer会check当前的buffer有没有写完。如果快写完了，那么就flush当前的view，close当前的handle。然后调用createmappingfile()，创建一个更大的MMF。同时为给这块shared memory取一个新的名字。
会不会是message reader这边用错了handle了？
看一下handle的information。
0:000> !handle 0x00000cb0 f
Handle 00000cb0
Type Section
Attributes 0
GrantedAccess 0x4:
None
MapRead
HandleCount 2
PointerCount 4
Name \BaseNamedObjects\3835699D-D3CE-4847-BFCA-A50791DF408D_Log_FileMap10
最后的数字，10，是writer新取的instance number。这个数字很蹊跷，因为应该不会这么大。
看一下实际上应该是多少。
0:000> dt _HeaderLogMessageInfoStruct 0x04dbb6e8+0x05c
MsgMMFReader!_HeaderLogMessageInfoStruct
+0x000 NumberOfRecords : 0x5112
+0x004 WriteNewLogRecordOffset : 0x260070
+0x008 WriteNewRecordIntoBlobOffset : 0x284719
+0x00c SizeOfLogMMFFile : 0x2a0000
+0x010 SizeOfDataMMFFile : 0x2a0000
+0x014 CurrentLogMappingNumberInWriter : 2
+0x018 CurrentBlobMappingNumberInWriter : 1
+0x01c UnreadInfoMsgCnt : 0xfffffe1d
+0x020 UnreadWarningMsgCnt : 0x122b
+0x024 UnreadErrorMsgCnt : 0x21f
+0x028 TotalInfoMsgsCount : 5469
+0x02c TotalWarningMsgsCount : 4651
+0x030 TotalErrorMsgsCount : 853
+0x034 InformationMsgsViewed : 0
+0x035 WarningMsgsViewed : 0
+0x036 ErrorMsgsViewed : 0
+0x038 FirstRecIn24HourWindow : 0x2636
+0x03c FileCreationTimeStamp : _SYSTEMTIME
+0x04c LastTouchTimeStamp : _SYSTEMTIME
我们看到，Writer那边的instance number才是2。而reader那边居然用的是10。这才是导致MapViewOfFIle失败的真正原因。
又重新看了遍code。发现代码那边有check number change scenario。但是，代码是这么写的：
if (m_currentLogMappingNumber < m_msgLogHeaderStruct.CurrentLogMappingNumberInWriter)
{
// remap the mmf
}
这个地方用的是比较大小来决定需不需要重新mapviewoffile。这个才是真真正正的root cause! 应该用“！=”来判断！
把这个地方改为"!="后，这个问题再也没有重现过。