Windows Update 0x80070001

[mhtvsSFrpHdE]

Windows 10 22H2

If you mount virtual disk before your system drive (mount at A: or B: in case system drive is C:),
run Windows Update can result in 0x80070001, failed to download, and get these in WindowsUpdate.log

DownloadManager *FAILED* [80070001] Method failed
CAgentDownloadManager::EnsureSufficientFreeSpace

There is a workaround posted on a Chinese forum, says mount after system drive could solve this.
For example, change mount point from A: to D: or X:, Y:, Z: any letter after system drive (usually is C:)
I found that unmount temporary also help.

https://bbs.pcbeta.com/viewthread-1813767-1-1.html

[mhtvsSFrpHdE]

A copy of original post in case website is not accessible. (and Google Translate)

[技术] 解决了Windows Update/Microsoft Store/dism的奇怪80070057报错

LZ的情况应该属于很罕见的corner case，可能没有太大参考意义，不过发出来应该还是有点意义的……

这位老兄用ramdisk挂载了一个B盘，然后报错0x80070001，我猜跟我碰到的情况如出一辙：
https://answers.microsoft.com/zh-hans/windows/forum/all/windows-updateinsider/03cc63af-20bb-47e7-9672-5deba4acbcfc

1.WindowsUpdate.log里可以看到一个报错的函数名称是CAgentDownloadManager::EnsureSufficientFreeSpace
那么，顾名思义，Windows Update在下载东西之前，会先检查系统盘的空间够不够用。
2.挂上WinDbg跟踪，可以看到，做这个检查的时候，会调用一个API函数GetVolumeNameForVolumeMountPointW。查微软官方文档可知，这个函数的作用是：用给定的盘符，去查对应的卷GUID是什么。
3.这个API函数是被循环调用的，C盘D盘E盘挨个查。然而LZ的系统盘盘符不是C，在字母顺序里很靠后。用这个API函数查C盘D盘E盘……都没事。
4.直到UltraISO的虚拟光驱I盘，到这里就不行了，BOOM！

为什么LZ的系统盘盘符不是C？因为LZ当初装这个Win10的时候比较中二，喜欢搞一个比较拽（字母顺序靠后）的盘符。

就酱。

怎么解决呢？很简单，把UltraISO的虚拟光驱干掉就可以了。
如果舍不得，可以用管理员权限（必须是管理员权限）启动UltraISO，然后打开软件配置，把虚拟光驱的盘符调到系统盘的后面即可。

那么，为什么要修Windows Update？Win10的更新不是流氓得出名么？把它干掉不是正好？
因为：不仅仅是各种补丁，有很多东西都是依赖Windows Update下载的，比如 微软应用商店、可选功能（比如XPS文档阅读器）、系统组件（比如.NET Framework 3.5）、dism（涵盖上述的可选功能和系统组件两方面）……
总之，但凡是依赖Windows Update的东西，都会时不时会给我80070057一下；各种该完成的下载任务，总是会死在这个报错上，无法完成。
当然，并不是没有了这些东西日子就过不了……UWP应用可以不下载，补丁可以手动打、甚至干脆不打，系统组件可以dism /source参数指定（不过这招只适用于.NET3.5这样的系统组件；可选功能的话就蛋疼了，微软搞了一个独立的Features on Demand光盘，不开放给公众下载）……

其实，这个问题我之前也折腾过，不过无功而返（具体情况记不太清楚了）。
dism /online /cleanup-image /scanhealth和sfc /scannow都没有发现异常，而且各种大小更新靠手动下载ISO/MSU、手动安装也一直很顺利。
直到最近，看到了EnsureSufficientFreeSpace这个函数名，才终于顺藤摸瓜找到病根儿

(Google Translate)

[Technology] Solved the strange 80070057 error of Windows Update/Microsoft Store/dism

The situation of LZ should belong to a very rare corner case, and it may not have much reference value, but it should still be meaningful...

This guy used ramdisk to mount a B disk, and then reported an error 0x80070001. I guess the situation is exactly the same as mine:
https://answers.microsoft.com/zh-hans/windows/forum/all/windows-updateinsider/03cc63af-20bb-47e7-9672-5deba4acbcfc

1. In WindowsUpdate.log, you can see that the function name of an error report is CAgentDownloadManager::EnsureSufficientFreeSpace
   So, as the name suggests, Windows Update will check whether there is enough space on the system disk before downloading something.
2. Hang up the WinDbg trace, you can see that when doing this check, an API function GetVolumeNameForVolumeMountPointW will be called. Checking the official Microsoft documentation shows that the function of this function is: use a given drive letter to find out what the corresponding volume GUID is.
3. This API function is called cyclically, and the C drive, D drive, and E drive are checked one by one. However, the system drive letter of LZ is not C, which is very late in the alphabetical order. Use this API function to check drive C, drive D, drive E...it's all right.
4. Until UltraISO's virtual CD-ROM I disk, it will not work here, BOOM!

Why is the system drive letter of LZ not C? Because when LZ first installed this Win10, he was a middle schooler, and he liked to make a drive letter that was more sloppy (lower in alphabetical order).

Just sauce.

How to solve it? It's very simple, just delete the virtual CD-ROM drive of UltraISO.
If you are reluctant, you can start UltraISO with administrator privileges (must be administrator privileges), then open the software configuration, and set the drive letter of the virtual CD-ROM to the back of the system disk.

So, why fix Windows Update? Isn't the update of Win10 famous for its rogue? Wouldn't it be nice to kill it?
Because: not only various patches, there are many things that rely on Windows Update to download, such as Microsoft App Store, optional features (such as XPS document reader), system components (such as .NET Framework 3.5), dism (covering the above optional features and system components)...
In short, anything that relies on Windows Update will give me 80070057 from time to time; all kinds of download tasks that should be completed will always die on this error report and cannot be completed.
Of course, it’s not that you can’t live without these things... UWP applications can not be downloaded, patches can be applied manually, or even not applied at all, and system components can be specified with the dism /source parameter (but this trick is only applicable to .NET3.5 system components; optional features would be a pain in the ass, Microsoft has created an independent Features on Demand CD, which is not open to the public for download)...

In fact, I have tossed about this problem before, but it was in vain (I don't remember the specific situation clearly).
Dism /online /cleanup-image /scanhealth and sfc /scannow found no abnormalities, and manual download of ISO/MSU and manual installation of various updates have been smooth.
Until recently, after seeing the function name EnsureSufficientFreeSpace, I finally found the root cause of the problem.