描述
问题就是：①移动磁盘上建立一个vmware虚拟机，然后用win10的iso镜像安装，安装完成后，如果重启，则可以正常重启，但是一旦关机，则再次开机一直都是Bug Check 0xC000021A，然后进行dump，为此我特地用 "windbg.exe" -b -k com:pipe,port=\\.\pipe\com_1,baud=115200,reconnect -y 在线内核调试了下，但是水平所限(等到哪天有空了再来看看究竟)，没有找出问题的究竟，但是错误的字面倒是说shell32.dll校验错误。而我用Diskgenius把它拷贝出来，校验是正常的。
②BT5-R3，CentOS7，RHEL7这三个我使用多年的vmdk，最近因为磁盘空间紧张，转移到了3T的移动硬盘上面(这个移动磁盘拷贝文件一般稳定70+MB/s，有些时候稳定在100MB/s，这里的数值是实际拷贝文件时Windows显示的。) 然而把这三个虚拟机开机一次，然后update一下，如果升级的有kernel，也就是boot分区内容有变化的话，下次就没法开机了。具体到CentOS和RHEL7就是如下
|
此问题什么时候开始的已经不可考了，但是WinXP/Win7/Win8应该是不存在这个问题的，总之最近的一些新系统关机后就再也无法开机。我注意到是磁盘的问题，而且是磁盘问题则是最近安装在移动硬盘上装win10。我尝试了检查磁盘，检查iso的hash，最终无意中发现在本地磁盘上安装就可以避免。
这个问题我可以完全排除磁盘坏道，或者NTFS元信息错误。均做过检测，正常且优良。
解决
Win10的解决办法目前就是在本地磁盘安装，然后移动到移动硬盘上去。而CentOS7/RHEL7因为是xfs系统，所以存在一个特别的解决办法。开机后如果看到 Generating "/run/initramfs/rdsosreport.exe" 这种方式的错误，而且最后停在:/#的root shell上面，那么可以直接执行 xfs_repair -L /dev/mapper/centos-root 即可（RHEL7是rhel-root)正常开机启动。而如果是EFIs错误，则可以用iso光盘Rescue功能，进入之后选择 Skip，然后再shell里面执行上面xfs_repair，则就可以救活移动硬盘上面的CentOS7/RHEL7系统。
猜测
这里只是大胆“瞎说”，目前没有进行验证。
Win10的启动分区和CentOS7/RHEL7的xfs里面的boot部分，有非常底层的代码和硬件编号还是什么相关联，而vmdk动态修改的过程中可能会发生重新分配物理地址，中间引起了什么混乱。
另外一个猜测就是我只在最近才发现，而3T最近快装满了，这是不是说明vmdk文件在物理磁盘上碎片的时候才会出现这个问题？
附录
Win10物理机上面用Vmware Workstation 12.
移动硬盘用Diskgenius检测坏道数量0，有600个良，其余均是优。
移动硬盘用chkdsk查不出问题。
CentOS7只要一操作内核(删除/升级)，必定是可以直接重启，但关机后开机必定CRC mismatch.
Win10在本地磁盘安装好后，拷贝到移动硬盘，再在里面安装各种软件，开关机均正常。
Win10直接在移动硬盘新建虚拟机不下5次，均是可以重启，关机后开机必定0xC000021A
这里有一个类似情况，不过是他不是移动硬盘，而是Windows Server2012的存储池。存储池必定CRC mismatch，本地磁盘正常。
更新(2016.6.25)
最近发现好像问题在于SCSI磁盘的问题上，也不知道问题出在哪个地方。避免在移动硬盘上使用SCSI磁盘即可避免问题。
参考这里。