接上文换硬盘。换完硬盘之后，顺手把之前装的Windows 8一起复制过来了，当作大号的PE使用，甚至还能放办公，打游戏。结果修复完引导（EasyBCD选择在当前系统下的盘符，不会修改系统挂载的盘符），一开机，发现锁屏界面是有的，但是壁纸不见了。输入密码登录，卡在“正在准备Windows”，即使不登录，想使用系统关机键关机，程序都会报错，连关机按钮都见不到。

然后在网上找，听到别人说可能是系统配置的问题，有不少人在系统备份前会主动将系统设置到sysprep模式下，在该模式中，系统会检测当前硬件，且根据现有的硬件生成合适的配置文件。然而，我遇到了两个问题：第一，该模式只能在系统内部进入，所以需要先把硬件配置完全改回原来的样子才能启动；第二，这种方法不一定成功，且失败后果很严重，尤其是当作为双系统安装在非C盘的时候，之前的配置文件会全部丢掉，无法回到原样。因为不愿浪费更多的时间在那块SMR硬盘上，只好作罢。

后来开始考虑是不是可能是根分区（借用Linux术语，这里指Windows系统所在分区）挂载出错的问题，因为Linux的GRUB配置出错的时候也会这样，系统一部分功能是正常的（因为已经加载到了内存），但是剩下的完全不可用。

然后就去查了一下Windows存不存在类似于盘符到分区UUID的缓存表一类的，结果还真找到了（https://docs.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/restore-system-boot-drive-letter）。

经过测试，解决这个问题的方法是，在任意一个可以在当前硬件配置条件下启动的系统中（比如新装的系统或者迁移的Windows 10），挂载Windows 8的SYSTEM注册表，修改其中对应的每个分区在HKLM\SYSTEM\MountedDevices中的那串二进制标识，从当前系统的值直接全选，对应覆盖复制过去就行了。

然而Windows 10可以自动在新硬件环境上自动适配分区标识，猜测可能的原因是，这个功能在Windows 10才被添加进系统的启动流程中，而Windows 8开发的时候并没有。（然而Win8能自动适配外围设备已经很强了）

HTTPS为网络安全传输带来了很大帮助，但是会因为其严格的措施，导致在很多地方出现奇怪的报错= =

这次的主角是Powershell，具体情境是在使用Download-File命令的时候，出现如下的错误信息：

The underlying connection was closed: An unexpected error occurred on a send.

两个StackOverflow链接解君愁：
https://stackoverflow.com/questions/41674518/powershell-setting-security-protocol-to-tls-1-2
https://stackoverflow.com/questions/36265534/invoke-webrequest-ssl-fails

简单总结，就是因为Powershell中需要对系统使用的HTTPS加密协议进行显式声明，然而因为我用的系统版本过低，某些常用的协议（比如TLS 1.2）并没有被默认加入到这个声明列表中，导致协议握手失败。

再次放图：

好在可以通过Powershell命令对允许使用的加密协议进行修改：

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Ssl3 -bor [System.Net.SecurityProtocolType]::Tls -bor [System.Net.SecurityProtocolType]::Tls11 -bor [System.Net.SecurityProtocolType]::Tls12;

在Powershell中读取.NET对象的属性的时候，有点像IPv6指定端口一样，需要先用中括号将对象包裹起来，然后再用两个冒号连接需要读取的属性名称。

后来找到了更简单的写法：

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12';

到此结束。

如题，竟然是Windows SDK版本的原因= =

在网上找了半天好像都没人遇到这个问题，看到这个才受到启发：https://forum.juce.com/t/missing-corecrt-h-and-windows-h-files-vs-2017/29195

如果新建了v141工具集的项目，再把Windows SDK版本设置为最新的话，就会找不到SDK里的头文件。要在设置里明确制定SDK的版本才行（例如我的是10.0.17763.0）。估计是VS2017支持自动识别的最高SDK版本是10.0.16299.0，超过了这个版本的话就不能自动识别了，导致IntelliSense认为找不到Windows SDK。

caffe就是个阴间项目。我生气了。

Windows下的配置太恶心，根本没法用，编译出来还能加载DLL失败。

唉，不想多说了。Python也是个阴间玩意，说是说DLL加载失败，可就是打死都不说是哪个。几十年了，没人管管的吗？

我为什么不管？这是我专业吗？要是能靠这吃饭，我早去考虑这个问题了。。

总而言之，还好有人提供了工具： https://github.com/lucasg/Dependencies

这个工具可以解析pyd文件的DLL依赖，感觉和ldd很像。（但是有机率崩掉？）
虽然问题没有直接解决，但是通过这个工具可以对pyd的内部依赖进一步了解，为解决问题提供可能，

把WLAN的网络桥接到LAN，按Ctrl依次选中LAN和WLAN，再在WLAN上右键点桥接。

中间可能会需要把网线拔下来，再插上去，一般来说等识别出网络的时间应该在1-2分钟内

不知道是玄学不