非--mem形式 map iso镜像后读取文件失败的问题

不点

55 楼按照 4K 对齐，此时，不带 --mem 成功。已经符合前面的结论了。

至于说带上 --mem 反而失败，这可能是另外一个完全不同性质的问题：有可能是 Windows 在某个阶段破坏了内存。它有可能不遵守 int 15 内存规范，属于 Windows 的 bug，或者某个驱动程序的 bug。内存遭到破坏，那么，内存中的 ISO 就可能正好遭到了破坏。

Plantsoot

回复 #61 不点 的帖子

http://115.com/file/belayfll#
map加--mem失败不加成功的ISO.rar

发现只要增加4K以上的体积，不管文件大小是不是4K的倍数，加不加--mem都可以正常启动。

补充一句：启动的时候记得选择XPPE，默认是NTBOOT。
               刚才我实机测试问题依旧。

[ 本帖最后由 Plantsoot 于 2012-2-22 16:46 编辑 ]

不点

好的，不带 --mem 的问题，算是解决了。正如前面所说，把 iso 文件增大到 4K 对齐就 OK。

下面看看能否解决 --mem 失败的问题。这应该是属于不同性质的问题了。或许这里真的能够发现 grub4dos 的仿真代码的 bug。

先由各位下载测试之后再说。

幸运的草

下载测试了百草的PE，发现这是个0PE。
先说测试结果。实机测试确如百草所说，加--mem中间停止到命令行下，是由于PE.WIM挂载失败引起的。而不加--mem反而没问题。
　查看ISO内部，发现PE.WIM的LBA值最高。
然后用软碟通把引导GRLDR导出，再导入，使这个文件LBA值为最高，这时实机测试，反过来了。--mem测试成功，而非--mem则引导失败。

  个人意见。0PE本身有说明，只兼容makiso制作的ISO，不建议用软碟通修改制作。PE.WIM，里面有几个WIM文件。而其他PE的WIM文件只是一个。这是不同之处。
　挂载失败也要在0PE内部查起，由于--mem方式加载后，启动0PE的速度飞快。而以前有反映。0PE为了求快，造成启动失败的情况，所以，会不会是高速启动造成了挂载WIM文件失败呢。
　　因为他要选挂第一层，然后映射后再挂第二层。速度过快，WIM管理程序能否反映过来呢？

不点

好了，我再说说自己的猜测。

百草的 0pe，PE.WIM 的 LBA 值最高，它处于内存的最高处，接近内存顶端的边界。这就使得它更有可能被 Windows 的程序破坏掉。因此，--mem 启动 PE 而失败的可能性增加了。

当在尾部续上一些无用的字节以后，Windows 所破坏的，就是无用的部分了，而不是破坏 PE.WIM 文件。此时就成功启动了。

而你把 GRLDR 弄到最末尾，这使得 PE.WIM 安全了，因此，--mem 成功。

但是不带 --mem 失败了，这可能是因为修改后的 ISO 文件并非 4K 对齐的原因了，前面已经多次提到这个问题。

大家看看这个解释满意不？

Plantsoot

这样解释的话应该解释的通了，所以我在尾部增加大于4K的数据后破坏的部分是无用的部分，解释通了。

看来尾部增加一定要大于4K以上才比较保险。不同的ISO是不是都是大于4K以上才保险可能还得测试测试，

如果有时间，明天我整个300M的ISO试试看。

chiannet

的确总结的是这么回事！在G4D下使用Ultraiso编辑过的ISO的窍门貌似就是这样的。

[ 本帖最后由 chiannet 于 2012-2-22 19:49 编辑 ]

幸运的草

我要说的就是这样道理。问题基本明了，在G4D外的解决办法，几种方法我前面已经说了。
　　现在需要新版G4D的测试，即MAP　ISO时，把ISO体积空间增大＞4K，这样再进行测试，看是否问题消失。
　如果消失，那就彻底解决了这个问题。

＞＞CHIANNET
　在G4D外的解决办法有三，向ISO里添加无用文件是一种方法。第二种，就是把ISO的引导文件即.BIN或.com文件，导出再导入，即可，因为这两个文件是ISO的引导，不依赖于windows。不会出现上面的问题。
　第三个办法，就是将原ISO的引导记录保存，重新制作新的ISO，再导入原引导记录。制作时最好保证WIM文件最先导入。
　
　

不点

原因找到了以后，你的解决方法似乎还不算合理。

既然尾部容易遭到 Windows 的破坏，那么，这是用户的事情。用户制作 ISO 时，尾部应该增加适量的无用扇区。究竟增加多少，由用户来决定。这个问题不应该由 grub4dos 来解决。只要我们在文档中把这个情况说清楚，用户比我们还要聪明。用户知道应该增加多少。

况且，不同的 Windows 环境，根据所运行的软件的多少以及软件种类的不同，它所破坏掉的内存数目也应该是不同的。我们不可能一劳永逸解决所有的问题。试想？你怎么知道 Windows 破坏多少内存？目前说不定已经破坏了许许多多的内存，只不过有些地方没有影响到启动过程，未被发现而已。那些没有用到的文件，其中很可能也有一些已经被破坏了呢！比如说，零零散散地，有些地方只破坏了几个字节，而有些地方破坏一大块内存。这种情况是有可能发生的。

这个问题既然已经证明不是 grub4dos 的 bug，而且也基本算是找到了原因，甚至也有了 workaround，那么，剩下的工作就没有了，不需要做了。

需要说明的是，在 DOS 和 Linux 的情形，不可能出问题（Linux 是开源的，出了问题容易定位）。因此，也没必要为 Windows 而浪费 grub4dos 的代码，以及浪费内存。

另外，当不带 --mem 时，由于是在磁盘上就地仿真，我们根本无法增加扇区。所以，这必须由用户自己把 ISO 增补到 4K 的整数倍。

xianglang

我说上想当然的想法：或者出现问题，并不是WINDOWS将内存什么的破坏了。

不点

Windows 究竟破坏内存没有，这一点也是可以精确证明的。

只要在 Windows 下，用 hex 工具软件把虚拟光盘的最后几个扇区显示出来，就知道它是不是被破坏了。

zw2312914

to 不点大人

  if (mem == -1ULL)
  {
    query_block_entries = -1; /* query block list only */
    blocklist_func (to_drive, flags);
    if (errnum)
        return 0;
    if (query_block_entries != 1 && mem == -1ULL)
        return ! (errnum = ERR_NON_CONTIGUOUS);

    start_sector = map_start_sector; /* in big 2048-byte sectors */

    //sector_count = map_num_sectors;
    sector_count = (filemax + 0x1ff) >> SECTOR_BITS; /* in small 512-byte sectors */
====================================
    if (start_sector == part_start && part_start && sector_count == 1)
        sector_count = part_length;
  }

之后“
bytes_needed = sector_count << SECTOR_BITS;


if (bios_drive_map.to_drive == 0xFF && !(bios_drive_map.to_cylinder & 0x4000))
                    {
                      unsigned long long drvbase, drvend;
                      drvbase = (bios_drive_map.start_sector << SECTOR_BITS);
                      drvend  = (bios_drive_map.sector_count << SECTOR_BITS) + drvbase;
                                   =================================
                      drvend  = ((drvend+4095)&(-4096ULL));/* 4KB alignment, round up */
                                 ============================
                      drvbase &= (-4096ULL);        /* 4KB alignment, round down */



sector_count = (filemax + 0x1ff) >> SECTOR_BITS
取整时已经多取了字节。（实际这种取整的方式也不好，filemax 如果很大，+0x1ff会越界）
之后:

(bios_drive_map.sector_count << SECTOR_BITS)
这时计算有差错不？

[ 本帖最后由 zw2312914 于 2012-2-23 03:07 编辑 ]

不点

filemax 是 long long 的，即 64 位。我们一般的文件都没有这么大，内存也没这么大，因此实际上这么大的文件根本无法装载成功。所以，越界的问题，还不怎么担忧。

sector_count 与 bios_drive_map.sector_count 是两个不同的变量，计算是没有差错的。

第一次是向上按 0x200（扇区边界） 对齐，接着第二次又按照 0x1000 （4K边界）对齐。其结果也就相当于一个 4K 的边界对齐罢了。前面的扇区对齐似乎有点多余，但那是没错的。至于说去掉扇区对齐是否可以的问题，那可以进一步研究。如果发现去掉之后完全正确，那样也可以去掉。我现在很懒了，精力不济。请 chenall 和你们来研究吧。

扇区对齐是我当初写的代码。后来 karyonix 增加了 4K 对齐的代码。这是不同的人写的不同代码揉在一块了。chenall 和你们可以看看这里能否优化一下。

zhaohj

哇，竟然破坏了2KB，直接给出证据：
偏移0x3706000~0x37067ff的最后2kb数据破坏

[ 本帖最后由 zhaohj 于 2012-2-24 10:09 编辑 ]

zhaohj

分析一下：这个iso占用0x3706800个字节，共56346kb，除4后余2，正好2KB被破坏。
4k对齐我理解适合map --mem方式，而不适合map非mem方式。

[ 本帖最后由 zhaohj 于 2012-2-24 11:27 编辑 ]

Plantsoot

有没看我那个奇怪的情况？

ISO镜像的大小是4K的倍数，map --mem启动失败，map不加--mem反而成功。

不点

破坏掉的，正好是 2K。

这一点很值得疑惑。

而且破坏的数据正好是用 Unreadable .... （我猜测后面还有一个单词是 Data，在贴图中没显示出来）的可读字符填充 16 字节，不断重复同样的信息，直到把 2K 全部填满。

由于 grub4dos 会自动增加 ISO 的长度到 4K 对齐（虚拟后位于内存中的 ISO 应该是 0x3707000 字节），因此，我认为破坏掉的，不是 2K，而是 4K。请验证。

这就是说，这些内存并未真正使用，而是被某个软件 “ 初始化 ” 了，或者说，简单 “ 抹掉 ” 了。

那么这是谁干的呢？究竟是 Windows 干的呢，还是 winvblock/firadisk 干的？这需要进一步确认。猜测是 winvblock/firadisk 自己干的。

如果是 Windows 干的，即，它总是破坏顶端的 4K 内存，那么，这样也很容易验证。用一个虚拟软盘（其长度用 4K 对齐），就可以验证，是否软盘尾部正好有 4K 被破坏。此时最好不要运行 firadisk/winvblock，否则很难说清楚究竟是谁破坏了内存顶端。可以找找 Windows 下查看物理内存的 hex 工具。事先在 grub4dos 下记录映像文件的位置，然后进入 Windows 后查看内存，看看数据是否遭到破坏。

zhaohj

再补充两幅图（map非mem方式）：

[ 本帖最后由 zhaohj 于 2012-2-24 14:56 编辑 ]

不点

你这次贴出的是不带 --mem 的情况。上次也是的吧？

不带 --mem，就出现不能读 4K 余数部分的情况。这应该与 Windows 系统无关了。由此可以基本确定，是驱动程序自身的限制，或者算是 bug。

真实磁盘上的数据不可能被破坏，驱动程序不会轻易写入磁盘的，因为那样的话，bug 就大了。驱动程序仅仅把 4K 的余数部分，用这种方式屏蔽掉了。也就是说，当用户试图访问这些扇区时，它简单给出 unreadablesector 的内容，如此而已。

换句话说，驱动程序不支持 “ 非 4K 对齐 ” 的扇区。

你这个试验，不能证明 --mem 的情况。也就是说，内存中的 ISO 是否遭到破坏了，目前还不得而知。

zhaohj

我上面所有贴出的是不带 --mem 的情况。
---------------------
现在基本可以确定，驱动程序不支持“ 非4K 对齐 ”的扇区，并且驱动程序把 4K 的余数部分，用unreadablesector这种方式把4K 的余数部分填充了
刚又做了个试验，把ISO文件处理成4K 对齐，而且把wim文件的LBA搞成最大(导出导入就可)，完美实现虚拟光盘中所有扇区数据正常。

不点

嗨，你这是（有点）浪费呀。本来就知道 无--mem 的情况是必须 4K 对齐的，前面多次猜到了。这是已知的情况，你只不过证实了而已。当然，你证实它，也有功劳，不能抹杀。

我个人觉得最需要证实的，是 --mem 情况下遭到的破坏，究竟是怎样的？现在甚至连 “ 破坏者是谁 ” 都不能确定（是windows呢？还是winvblock/firadisk 驱动程序？）。

Plantsoot

我刚才做了个测试，我发现一个问题，不知道对不对。

1、
文件: G:\0PE4.ISO
大小: 122677248 字节（0x74FE800，0x3A7F4个512扇区，29950.5个4K扇区，姑且这样说）。

2、菜单

title  map测试
map --mem (ud)/WINVBLK.IMG (fd1)
map --mem (md)0x6000+800 (fd0)
map --mem (ud)/MYPE.ISO (0xff)
map --mem (ud)/0PE4.ISO (0xfe)
map --hook
dd if=(fd1) of=(fd0) count=1
map --status
pause
chainloader (0xff)

3、启动过程截图：



4、原始文件的WINHEX截图




5、进入PE前后，再用winhex查看map出来的光驱



6、

map --mem后，map --status
发现map自动补齐到了4K的整数倍（122679296字节），0x3A7F8个512扇区，29951个4K扇区。

进入PE后，再次用winhex查看map出来的光驱，
大小依然为122677248 字节（0x74FE800，0x3A7F4个512扇区，29950.5个4K扇区）。

补齐的数据丢失？

[ 本帖最后由 Plantsoot 于 2012-2-24 16:42 编辑 ]

不点

发现什么问题了？

也许你的 ISO 结尾处本来就有很多 00 字节呢？

不对比的话，根本不能说明问题。

ISO 文件长度被识别成多少，那是驱动程序的事。文件长度很可能记录在 ISO 文件开头的一些敏感数据区。驱动程序很容易知道真正的 ISO 文件系统的长度。

所以，长度问题，不用考虑。

现在我们只关心，究竟有多少内存被破坏了。

zhaohj

这样做了个试验：
!BAT
/srsf6/srsf6n fira
map --mem (hd0,4)/mype.iso (0xff)
map --hook
map --mem (md)0x200+4 (99)
map --hook
echo [FiraDisk] > (99)+1
echo StartOptions=cdrom,vmem=find:/mype.iso; >> (99)+1
chainloader (0xff)
boot

下面的F盘是map --mem虚拟的，G盘相当于map虚拟的
F盘内容正确，G盘有问题，破坏正好的0x800=2kb，即4kb的余数部分。

[ 本帖最后由 zhaohj 于 2012-2-24 16:41 编辑 ]

Plantsoot

刚才漏了一个图，现在补上了。

总结一下：

map --status的时候有对它进行补齐数据，比原始的文件应该要大。
对于这个ISO，map --mem，进入PE后和原始的文件是一样的。
如果解释为“ISO 文件长度被识别成多少，那是驱动程序的事。文件长度很可能记录在 ISO 文件开头的一些敏感数据区。”
是不是就是说，map --mem的时候，根本就没必要补齐，因为补齐了进入PE后也是无效的？

但有的ISO补齐后，就可以正常使用了，我这个ISO不管补齐与否都是不能正常启动的，我又糊涂了。

不点

所以猜测内存被破坏了呀。有这些现象的存在，才有猜测的根据呀。

猜测 + 证明，就是科学研究的方法呀。

补齐了以后，有可能在遭到内存破坏的时候，只破坏了补齐的无用部分，保护了 ISO 中有用的部分。

不点

你又一次证明了 无 --mem 时，非4K对齐的失败情况。

而我们实际需要的是，在带有 --mem 的情况下，内存遭到破坏的证据。这个不容易证明了。估计要有很多困难。

zhaohj

有一点我不明白，map --mem会自动4K对齐，如下面的扇区总数是0x1b838=0x3707000字节，那为何在windows下查看虚拟光驱的总字节数是0x3706800?
少了0x800字节，即2KB.

不点

刚才在前面和百草霜的讨论中已经解释过了，你翻翻看。

在 83 楼。

[ 本帖最后由 不点 于 2012-2-24 17:40 编辑 ]

幸运的草

提点建议：
还应注意另一个问题，一直不明白，但无能力证明。
　　同一个文件，为什么导出再导入，LBA值就变为最大？是不是说，它是把这个文件放到了ISO的最后位置？
这个情况和发现的FBINST的情况是一样的。
　　因此有理由怀疑，是这个工具在计算文件存放空间方面有错误呢。

[ 本帖最后由 幸运的草 于 2012-2-24 17:41 编辑 ]