0PE_NBv1.5.1(2014-04-05)测试

不点

pseudo 发表于 2013-6-24 13:36
谢谢不点大人提醒。
以前用英文显示读秒信息，虽然关闭debug，但显示信息前的命令都比较安全不会死机，所以 ...

我没看明白究竟是怎么个来龙去脉。下面只是模糊的猜测。

是不是从 DOS 启动 grub.exe 的时候，menu.lst 只有 4K 起作用？

这是肯定的了。

因为此时是由 DOS 的 API 来加载的 menu.lst，我们只能把它放在内存中，否则进入 grub 以后就找不到它了。而当时只使用了 4K 内存，以免过多占用内存，与其他代码、数据相冲突。

就是说，本来就只是加载了 menu.lst 的开头 4K 而已。一直是这样的。这不能算是 bug，只能说，我们的文档没有明确说明这一点罢了，属于文档的欠缺。

如果用参数 grub.exe --config-file="..." 来加载，并且 “...” 里面填写的是 grub 格式的文件名（不是 DOS 格式的文件名），就没问题了。此时，在 DOS 期间是不会加载 menu.lst 的，直到进入 grub 以后，才寻找 menu.lst 文件。

不点

新版缺少了 “安装方法” 等目录，menu.lst 也不见了。

不点

pseudo 发表于 2016-11-19 18:24
猜测：
1、grldr用的不是跟iso一起生成的
2、0PE.iso文件未连续存储，有碎片。

从最后一张图片来看，这个主板的内存碎片太严重。第一个内存碎块只有 511M。在 4G 以上有 1016M。因此猜测，它是 4G 内存，在 4G 以下有 3G，而在 4G 以上有 1G。4G 以下的 3G 不是连续的，而是划分成几个小碎块。我怀疑它的 ISO 正好加载在第一个碎块（511M）上，而且 ISO 的大小几乎占满了这 511M，造成 grub4dos 没有空间运行。要知道，grub4dos 最少需要 32M 才能运行。如果 ISO 把 grub4dos 的 32M 中的顶部的一部分破坏掉了，那就等于说是破坏了字库，因此，图形模式的汉字和英文都无法显示，只有文本模式下才能显示英文字符。

用 map 的 --top 参数，可以把这个 iso 加载在 4G 以上的 1016M 空间里面，这样就不会有问题了。

重要补充：即使用户在 4G 以上没有内存块，也可以使用 --top 参数。--top 参数与用户内存的多少无关，与内存的布局无关，与 CPU 是否支持 64 位无关，与 CPU 是否支持 PAE 无关。任何电脑都可以使用 --top 参数。--top 参数的意思就是，尽可能使用最高端的那个内存碎片，而不管这个内存碎片是否在 4G 以上。

不点

pseudo 发表于 2016-11-19 21:21
@wangjf
不点大人的分析有道理：可能这个主板的内存碎片太严重。可以这样验证：
把DIY文件夹下的EFI、IM ...

如果 0pe 中的所有的 map --mem 命令都加上 --top 参数，基本就可以解决这个问题。因为现在电脑的内存普遍都很大，即使内存有碎块，由于 --top 起作用，因此通常不会使用最底端的内存块，这样也就不容易与 grub4dos 本身发生内存冲突了。

不点

wangjf 发表于 2016-11-25 15:42
今天见P大更新了0PE到20161120，下载下来在原来那台电脑上再测试一回。

电脑型号: 惠普 HP Pro 3330 MT  ...

2.按回车键，0PE也可以启动到桌面；
3按回车键，在下面的界面中死机，没有反应。

抱歉，反复看了十几遍，没看懂——主要是理解不了两个都是 “按回车键”。

不点

2012zhd 发表于 2016-12-11 21:34
1209版f6串接菜单仍然有问题。

不像是 --top 的问题。另外， --top 应该不会有问题的。

Cannot mount selected partition 的意思是说，(fd1) 这个设备无法挂上。你定位一下，看毛病在哪里。怀疑是 (fd1) 里面的内容不对。可用

map --status
geometry (fd1)
cat --hex (fd1)+1
ls (fd1)/

看看内容是否正常。

前面的 Autodetect CHS 失败信息，好像是说 (fd1) 这个虚拟软盘不是合法的 FAT 格式（也不是其它合法格式，如 NTFS 等），所以报错。有了这样的错误在先，所以 (fd1) 里面的内容就无法访问了。因此，必须先排除这个错误，然后才能执行 map --mem --top (fd1)/f6.gz (fd0) 的操作。

不点

2012zhd 发表于 2016-12-12 12:14
不点大师啊，我只是一个0pe的使用者，代码根本不懂啊。
（在两台机上测试过，都是一样的错误提示，故障 ...

忽然觉得可能是 grub4dos 的 bug。

map --rehook 的时候，要重新整理内存盘的物理存放地址，但不使用 --top（因为早期不存在 --top 选项），这样就乱了。如果不用 map --rehook，应该没问题的。如果 0pe 使用了 map --rehook，那说明我猜的方向是对的，问题的症结也猜着了。

解决办法，让 --top 成为默认、“铁定” 的选项，就是说，无论有没有 --top 选项，都从最顶端寻找可用内存块来存放 img。

可以让 chenall 或 yaya 编译一个版本来测试。如果我有空的话，我也可以做。但暂时没工夫做这事。

不点

2012zhd 发表于 2016-12-13 09:10
我曾经用0pe0920版本的grldr换上1209的菜单测试1209版0pe，一样会提示同样的错误，这似乎说明不是grub4do ...

各位，问题比较明白了。需要修正 map --rehook 命令。这个修正的动作表面上看不算大，可也是个细致活，弄不好会产生新的 bug。所以我打算找时间能够静下来，仔细处理这一问题。暂时先不要用 --top 吧。

不点

wangjf 发表于 2016-12-20 16:25
下载0PE_NBv1.5.2(20161212)2in1+10pe(20161208).7z生成0PE.iso（405MB）
把0PE.ISO、grldr、grldr.mbr放 ...

没办法，你只能等着将来新版 grub4dos 把 map --mem 修正好了之后再测试。其中大致应该包括以下两项修正的动作：

1、将 --top 设为默认（无论有没有 --top，都执行 --top 的操作）。
2、修复 map --rehook，让 rehook 可以处理位于 4G 以上的内存块。目前的 rehook 无此能力。

尤其是 grub_memmove 函数是应该仔细处理的，即，那些调用 memmove 的地方，大部分都应该换成相应的能够处理高于 4G 内存地址的函数调用。

不点

pseudo 发表于 2016-12-20 18:39
你那台机特殊，正如不点分析的，内存碎得很，按空格将iso载入内存时，由于低端没有连续的足够大的空间（ ...

关于 --top 的修改完成了。同时也仔细检查了 map --rehook，觉得没什么需要改动的。由于 --top 已经成为必然的动作，因此 map --rehook 时会自动执行 --top 的动作，不会再搞乱了。

估计应该没问题了。先试试看吧。

不点

pseudo 发表于 2016-12-21 18:16
说明：grub4dos-0.4.6a-2016-11-09版g4d很快出0PE主菜单，从grub4dos-0.4.6a-2016-12-12起的g4d版本启 ...

如果没有其它原因的话，我猜是文件长度逐渐增大后带来的内存冲突。试着比较两个版本的 grldr 的大小，看看增大了多少字节。

为了确定是不是文件大小造成的，可以先试着删掉一些不重要的命令，以便减小 grldr 文件的长度，试试看效果。如果无效，则表明不是文件长度增大造成的。如果有效，则表明确实是文件长度增大而引起的。

不点

去掉 help 命令，节约不少字节。试试看这个怎么样？
主要是验证前面的推测，即，是否由于文件长度太大而产生问题。


如果这个没问题，那就证实了推测。如果同样有问题，那就否证了上述推测。

不点

wangjf 发表于 2016-12-22 16:40
替换此grldr文件生成的0PE.ISO会出现蓝屏。
具体如下：
在1.回车键、2.空格键、3.Esc键 选项画面进行 ...

粗略分析一下。

你的高于 4G 的内存有 1G，那么你的 ISO 和其它小的 IMG 应该都放在那里了。

假如你的驱动程序（firadisk？winvblock？对不起，我可不了解它们）不支持高于 4G 的虚拟盘的话，那可能就会出现蓝屏了（07B 蓝屏，据说大概就是 “盘未识别、盘无法访问” 导致的）。

你用的是何种驱动程序？是 firadisk 还是 winvblock？

不点

wangjf 发表于 2016-12-22 19:51
没有使用驱动程序
就是在出现0PE主菜单时，选择第一项 Windows PE （XP）单核版。
不是上面的第二张图 ...

等待 2 分钟，是不是可以理解为 “不正常”？如果这确实属于不正常现象（正如 pseudo 所说的那样），那么就应该用上述带 nohelp 的版本再试验一次，这样才好确定问题究竟在哪里。请把带 nohelp 的压缩包里面的 grldr 提取出来进行测试，当然要把内置菜单调整为与 pseudo 提供的内置菜单相同。

是的，这个测试很重要。如果这个测试依旧有问题（不正常，或失败），那就怀疑 yaya 在 2016-12-12 的版本中引入了 bug。那样的话，我们需要回到先前没有 bug 的版本再重新编译测试有关 --top 的新的处理方式。

不点

另外，请 pseudo 留意，屏幕顶行的 End: 后面的内存地址 36A226（它是十六进制值），可能已经 “超标”，换句话说，就是可能已经引起冲突了。我不能确定这一点，需要仔细查一查全部代码的内存使用情况才能确定。检查是很费事的，因此，暂且不去查它；暂且当作 “没问题” 来对待。

不点

好的，退回一次修订，返回到 r734，以此为基础重新处理 --top，看看这次怎么样？

不点

firadisk 和 winvblock 当中，肯定有一个（即至少有一个）是支持 4G 以上的内存块的。这是因为有人成功把 Windows 安装在 4G 以上的内存块上。我觉得 firadisk 支持 4G 以上内存块的可能性较大，因为 firadisk 的作者还专门为 grub4dos 打补丁，让 grub4dos 支持 4G 以上的内存块。

因此，假如两者当中有一个不支持 4G 以上内存块的话，那可能就是 winvblock 了。我很长时间都没接触 memdisk 了，不知道它是否支持 4G 以上的内存块。假如不支持的话，那么，winvblock 也可能不支持。因为 memdisk 和 winvblock 都与 syslinux 有关，是 syslinux 的开发者开发出来的，对 grub4dos 的支持，可能就没那么完美了。

具体情况究竟如何，那还需要测试和验证。

是的，grub4dos 的 map 可以限定内存块的地址范围（--mem-max，--mem-min）。但通常是不需要、也不应该用的。

如果 firadisk 或 winvblock 不支持 4G 以上内存块，可以向其作者报告 bug。这是最好的做法。

一个驱动程序，如果它不支持 4G 以上内存块，这肯定不行。举例来说，如果 4G 之上有个 1G 的内存块，4G 以下有很多小的内存碎块（长度都小于 1G）。如果 IMG 长度正好是 1G，则 map --mem 肯定会把它放在 4G 以上的那个内存块上。即使很老的 grub4dos 也是如此，不需要 --top，因为那是唯一可以容纳 IMG 的内存块。如果驱动程序不支持的话，那问题就大了！所以，必须得支持，不能含糊其辞。可以认为，如果不支持，那就是有 bug。

不点

yaya 已经把我的 --top 补丁打在 0.4.6a 上了。大家可以从 chenall 的网站上下载测试了。

建议的测试方法：

1、去掉 winvblock，只留下 firadisk，测试是否有故障出现（理论上应该不会有问题）。
2、去掉 firadisk，只留下 winvblock，测试是否有故障出现（可能会由于 “img 被加载在 4G 以上” 而出现 07B 蓝屏死机）。

重要说明：

使用 map --mem-max=... 参数可以让 img 加载在 4G 以下，但是要注意，一旦执行 map --rehook，则有可能自动调整到 4G 以上。这是因为，map --rehook 在重新调整内存盘位置的时候，不使用 --mem-max 之类的参数。因此，建议永远不要使用 --mem-max 或 --mem-min 之类的参数，以免执行 map --rehook 后这些参数被 “无视” 或 “忽略”。换句话说，如果使用了 --mem-max 等参数，就不要再使用 map --rehook 命令了；但可以同时（按先后顺序）使用 map --unhook 和 map --hook 这两条命令来取代一条 map --rehook 命令，这样是不会自动调整内存盘位置的，因而是没问题的。

不点

pseudo 发表于 2016-12-24 15:52
采用grub4dos-0.4.6a-2016-12-23.7z的
0PE_NBv1.5.2(20161223)2in1+8pe10pe(20161219)
已上传，在我签名 ...

必须得有试验验证 winvblock 不支持位于 4G 以上的内存块。目前只是猜测，并未肯定。需要有肯定的证明。

一旦确认 winvblock 不支持位于 4G 以上的内存块，那就不能再用它了，除非它的开发者解决了这个问题。理由就是，map --mem 有可能把 IMG 加载在 4G 以上的内存块，无论有没有 --top 参数，无论是新版还是旧版的 grub4dos。比如低端都是 500M 的内存块，高端有个 1G 内存块，用户 IMG 是 700M，则肯定加载在高端。

在 winvblock 不支持高位内存的情况下，也是勉强可以使用它的。使用的办法就是用 --mem-max 参数限制内存块的加载位置，不让它加载在 4G 以上，同时，用

map --unhook
map --hook

来取代

map --rehook

避免把内存盘自动调整到高位内存区。这就行了，应该不会有问题。

于是提出一个新的话题：有没有人综合 firadisk、winvblock 两者的优点，写个新的驱动程序，这样大家都不再纠结该用哪个了。

不点

关于 --top，再发表一点看法，希望能够对大家有所帮助。

旧版的不带 --top 的 map --mem，根本就 “不可取”、“不可用”。我举出一个非常普通的、常见的例子：

机器总内存 4G，其中，低端的有 3G，高端的有 1G。

高端都是连续的。低端会被分割成碎块。假定低端是六块，都是 500M。

那么，map --mem 会使用最低端的 500M，这样也就容易与 grub4dos 的 32M 保留内存发生冲突了。

map --mem --mem-max=...  --top 则会使用位于 4G 以内的最高端的 500M 内存块，这就不会发生冲突了。省略号的位置是填写某个值（可以计算出来），它代表 4G 的界限。

就是说，同样都是使用 4G 以内的 500M 空间，

map --mem 是使用最低端的那一块

而

map --mem --mem-max=...  --top 则是使用最高端的那一块。

显然后者更好，而前者不可取。

不点

邪恶海盗 发表于 2016-12-26 20:33
看下坑爹的X度盘,我这是50M宽带,下行50,上行4,竟然是这德行...

不知道我该不该插话。免费的东西，你不能够指望它会怎么样，你不能指望它 “稳定”，你不能指望它 “可靠”，甚至你不能指望它 “存在”。更不用说下载速度了——因为它甚至都可以关停、消失，更不能奢谈速度。

收费的 VPS 还经常无法访问呢，更不要谈免费的东西了。

人心在 “贪”，所遇到的种种问题，皆在于太 “贪” 了。人都是 “贪”的，人都是 “得寸进尺”的。就是说，不知不觉地就在 “贪” 了，不由自主地就在 “贪” 了，而且贪了之后，自己竟然毫无察觉。贪污腐化的官员，进入监狱之后，终能悔过，然而在他 “贪” 的时候，他是毫无感觉的，他觉得一切都来得自然，他没觉得自己很 “贪”。

“贪” 还是一种 “占便宜” 的心理。人往往喜欢 “占便宜”，这也是人的一种惯性，难以消除。为什么那么多的骗子都能得逞？为什么那么简单的骗术都不能被识破？皆是因为被骗者有 “占便宜” 的弱点，让骗子们抓住了，让骗子掌控了，所以结果不仅没占便宜反而吃大亏了。这就是：贪小便宜吃大亏。

呃——请别误会，我可不是来教训人的。我说的是一般规律，我也是人里面的一个数，我也有 “贪”、“得寸进尺”、“占便宜” 的毛病。假如我没有这些毛病的话，那我就不是人了。我虽然能够意识到这个问题，但我难以摆脱。无论我怎样努力，也总会 “不干净”、“不彻底”，因而总会有那么点 “贪”、“得寸进尺”和“占便宜” 。

插话完毕；不知该不该，不知多余不多余，不知恶心不恶心，不知讨厌不讨厌，不知好不好，不知坏不坏——因此，我其实就是 “无知”啊，所以，请原谅。

不点

继续探讨 --top 和 4G 有关话题。搜到以下帖子：

https://github.com/Sha0/winvblock/issues/2

Sha0 commented on 23 Apr

15e7df1 is the last commit for the last released version, if I recall correctly. "Revisions after that" aren't expected to work. I have put all development into the "master" branch instead of a "hidden" branch, so I apologize for the confusion.

If 15e7df1 doesn't work with GRUB4DOS ISOs, I'm sorry, but WinVBlock 0.0.1.8 can't drive your RAM disk. It almost appears that you could use V.'s original WinAoE driver with Firadisk and forget about WinVBlock.

I'd obviously like for the next release of WinVBlock to address your needs.

开发者 shao miller 似乎已经知道了 WinVBlock 有问题（虽然他没说是否是 “不支持 4G” 的问题），而 Firadisk 却正常。shao 还说愿意在下一个版本中满足提问者的需要。不过，好几个月过去了（现在已经是年底了），也没见有什么动静。

不点

抱歉，前面关于 --mem-max 的用法是错误的。正确的用法是

map --mem-max=... 此处数值的单位是 “扇区”，即，512 字节。

这条命令必须单独执行，不能把 --mem-max 参数与其它参数放在一起。这条命令执行以后，将设定后续所有的 map --mem 命令的内存上限，也就是说，后续所有的 map --mem 命令，将都使用 --mem-max 设定的内存上限。同理，下限 --mem-min 的设定也是如此。

这些变量设定以后，直到它们被再次设定之前，一直起作用。configfile 命令加载新菜单，不影响设定的值。也就是说，设定的值能够跨过 configfile 而继续起作用。如果用 chainloader /grldr；boot 或 kernel /grub.exe；boot 启动新的 grub 环境，那么 --mem-max 和 --mem-min 将是初始的默认值（就是说，设定值不能跨过 boot 命令而继续起作用）。

如果设定

map --mem-max=0x800000

这就相当于设定了后续 map --mem 的上限为 4G。设定一次就够了。后续的 map --rehook 也会自动使用设定的上限。

需要注意的是，设定值不可以随意变动，因为那样会导致 map --rehook 无所适从。建议自始至终都只使用同一个设定值，不要一会儿是 map --mem-max=A，一会儿又是 map --mem-max=B。

不点

pseudo 发表于 2016-12-28 14:32
"一旦执行 map --rehook，则有可能自动调整到 4G 以上。这是因为，map --rehook 在重新调整内存盘位置的时 ...

map --mem-max 设定的是一个静态变量，可以看成是全局变量。设定以后，所有的 map --mem 都会使用这个变量来控制虚拟盘的最高内存地址。map --rehook 会自动调用 map --mem 命令，因此，也就必然要使用设定的变量值。

这个参数不是我设计的，因此起初我对它并不了解，仅凭想象给出了见解，即：

"一旦执行 map --rehook，则有可能自动调整到 4G 以上。这是因为，map --rehook 在重新调整内存盘位置的时候，不使用 --mem-max 之类的参数。"

这个解释其实是错的。是在我后来看代码的时候，发现这个问题的。

这个参数的设计，有利于在 0pe 中统一控制 map --mem 的最高内存地址。只要在开头执行一次：

map --mem-max=0x800000

就 “万事大吉” 了。当然，如果使用旧版，那还得在每个 map --mem 中添加 --top 参数，新版就不用添加了。

如果你想让你的脚本通用，即，同时适应新版和旧版，你可以这样：

1、在脚本开头执行 map --mem-max=0x800000
2、在每个 map --mem 中添加 --top

参数 --top 和 --mem-max 好像是同时实现的，印象中好像都是 karyonix 实现的。所以，这两个参数都是很早就支持了的，不用担心版本问题。

不点

pseudo 发表于 2017-1-3 15:41
@wangjf @不点
我签名处有采用grub4dos-0.4.6a-2016-12-24的版本。

我没条件测试，等着 wangjf 测试吧。

采用 --top 的处理方式是对的。当初 karyonix 应该把 “从低端查找内存块” 的策略当作 bug 废除，不用添加 --top 参数，直接修正为 “从高端查找内存块”。那样的话，也许大家早都发现 winvblock 的问题了，不会拖这么久才暴露出问题。

另外，作为一个程序设计的探讨，默认时，应该只使用 4G 以内的低端内存块，这样就照顾 winvblock 的情况了【实际情况，目前在默认时是不限制内存地址的】。在默认时只使用 4G 以内的内存块的情况下，如果要启用高端内存块，可以添加一个 --top 参数来控制【实际情况，目前的 --top 参数并非用来控制是否启用 4G 以上内存块，这与大家看到 --top 字样以后的理解是有出入的；很多人误以为 --top 就是控制是否启用高端内存块的；众人的这种误解是合理的，这反过来也说明，程序应该这样去设计，让众人的误解 “合理化”】。不过，历史就是历史，它的路也许是弯曲的，也许是变态的。我们不能完全摆脱历史。所以有时候我们要忍受，换句话说，就是尊重历史。记得当初还变态地设计了 --int15nolow 这个参数，后来证明，这个参数没有彻底解决问题。只有后来的 --e820cycles 参数才从根本上找到了症结，也解决了问题。那么，--int15nolow 也就真正成为 “无用的参数” 了。

补充一点：既然提到了 --int15nolow 是无用的，那么，将来在必要的时候是可以删除这个参数的，从而节约宝贵的 int13、int15 处理程序的代码空间。

不点

谢谢 wangjf，谢谢 pseudo，以及其他热心帮助的高人，谢谢您们的辛苦。你们提供了问题和线索，我提供了分析方法以及理论的探讨，最后由你们提供实践检验。完美解决，非常开心（貌似今天能多吃一碗饭），因此，要再次谢谢 wangjf 通报这一结果。

不点

kanhe 发表于 2017-1-5 08:19
0PE1224 用QEMU光盘镜像测试768M内存测试, 到桌面后自动加载 "启动网络影音",加载网卡不成功(已增加网卡驱 ...

"x:\wxpe\net\start_net.cmd all" 貌似是个 “运行文件” start_net.cmd 后面添加了 “参数” all，因此，它不是 “一个合法的运行文件”。我不懂 windows 的编程，希望我的这点发现能够帮助 pseudo 进行排错。

不点

pseudo 发表于 2017-1-5 16:33
建议你上传被测对象iso、测试工具及其设置要点，让大家能重现此现象。

1224跟1223主要是g4d方面有差异 ...

你能确定他修改了原版，那就是他自己的问题了。比如说，有可能他在混用新旧版本的 grldr，造成问题。

不点

kanhe 发表于 2017-1-6 08:36
今天 用下载的0PE_NBv1.5.3(20161224)2in1+8pe10pe(20161228) 原版 大小(411681447) 的文件重新制件.不改动 ...

提供一点想法，供参考。

1、pseudo 已经试验过了，没能重现这个问题。要知道，虚拟机的环境都是一样的，不可能运行状况却不一样了。真实机倒是千变万化，难以捉摸，而虚拟机是固定的，大家相当于拥有一台公共的、固定的机器。
2、要么 pseudo 上载的文件不完整，或阴差阳错上载错了；要么你下载的时候下载得不完整，这样造成了你俩测试结果的不同。
3、新旧版本的 grldr 对于 qemu，应该不会有影响的。qemu 是虚拟机，通常情况，虚拟机的内存都是连续一整块，没有内存碎片，因此，无论新版还是旧版，都是把映像文件放在同一块内存的最高端，就是说，新旧版本不会存在差异。
4、当你用 qemu 测试 iso 时，你的 qemu 里面或许也挂载了虚拟硬盘，而 pseudo 测试时不一定挂载虚拟硬盘，这也是造成差别的一个可能的原因。要知道，所挂载的虚拟硬盘里面。有可能存在某个隐蔽的、很老的、有 bug 的 grldr，它也可能是造成问题的一个原因。

好的，能想到的，大致就这些了。希望能够帮得上忙。

不点

邪恶海盗 发表于 2017-1-6 20:18
我这也驱不上,同样报start_net.cmd错误,在启动网络影音的批处理界面上显示的,要点出来才看得到,是不是跟 ...

要知道 pseudo 本人测试多次都没出错啊。既然这次你也报告错误，那么我就怀疑 pseudo 在上载过程中出错了。但由于上载的是压缩包，所以，出错的可能性并不大（否则在解压时就会报错）。有待更多的人给出测试结果。

这个问题很难定位吗？同一个虚拟机软件，同一个 ISO 文件，测试结果却不同！难道出鬼了吗？既然提到 “鬼”，那流氓、病毒也是鬼啊。请确认：自己的机器干净吗？换一台电脑重新下载，再试试。