不是问题的问题------map --hook or map --rehook

hotdll

如下菜单：

1. title  1. 启动 Native WIN7PE 网络版
   
2. echo -e \n$[0003]  正在加载Win7PE 网络版一级内核！
   
3. echo -e \n$[0003]  此过程可能需要几分钟。。。。。。
   
4. command (ud)/BOOT/GRUB/DRV7
   
5. map --mem (ud)/ISO/win7boot.lzma (0xff) > nul
   
6. map (ud)/ISO/win7two.iso (0xfe) > nul
   
7. map --hook
   
8. chainloader (0xff)/bootmgr
   
9. boot

复制代码

在80%的机器上都能成功的引导WIN7PE，并且能识别WIN7TWO.iso 这个仿真的光驱。但是有10-20%的机器无法识别。

如果改成如下菜单:

1. title  1. 启动 Native WIN7PE 网络版
   
2. echo -e \n$[0003]  正在加载Win7PE 网络版一级内核！
   
3. echo -e \n$[0003]  此过程可能需要几分钟。。。。。。
   
4. command (ud)/BOOT/GRUB/DRV7
   
5. map --mem (ud)/ISO/win7boot.lzma (0xff) > nul
   
6. map (ud)/ISO/win7two.iso (0xfe) > nul
   
7. map --hook
   
8. rootnoverify (0xfe) //添加代码1
   
9. ls (0xfe)/ > nul    //添加代码2
   
10. chainloader (0xff)/bootmgr
    
11. boot

复制代码

从目前反馈的问题看，应该都解决了。很是奇怪，因为03和xp pe使用原来的菜单正常。

win7和xp的init13不一样吗？还是因为win7使用Init15的原因？还是g4d的map --rehook --hook命令必须在某些特定的环境才生效？之所以添加这两句是我和幸运的草大哥在无数次测试中发现，有时候调整map --hook或者map --rehook命令，会成功加载该win7two.iso仿真光驱。

后来推测是因为win7two.iso在UD区中。UD区属于USB。win7在加载USB驱动后，读取HOOK区域中中的虚拟光驱这个时候ISO没被载入。部分机器延迟的时候，会被载入。于是用上面的命令强制加载了0xfe盘。结果以前不正常的机器。正常了。

[ 本帖最后由 hotdll 于 2012-6-12 09:30 编辑 ]

sratlf

两个不都是map --hook吗

看到的区别是root不一样。。。

zhaohj

在实际应用中，发现windows的网络映射盘也会产生这种情况，需要手动显示一下映射盘的内容后那些与映射盘有关的程序才会执行。
但不是所有的机器都这样，占比例大概20%。

xwan

原帖由 zhaohj 于 2012-6-12 08:42 发表
在实际应用中，发现windows的网络映射盘也会产生这种情况，需要手动显示一下映射盘的内容后那些与映射盘有关的程序才会执行。
但不是所有的机器都这样，占比例大概20%。

个人在实机测试中也发现了这个问题，有些困惑。
不过个人测试的范围内，直接原版安装微软的系统都没发现有这个问题，基本是出在克隆版的系统上。
以XP为例，深度和小兵的GHOST系统，用过上百台机子，无一出问题。而其他各种流行的ghost系统，90%以上的会出问题，根据个人经验这个跟硬件无关，就是系统本身的问题。

hotdll

你仿真两个ISO试试。
有时候仿真会在读取非启动ISO的时候才生效。这个时候如果系统反应过快。好像会加载不上ISO

x9tian

原帖由 hotdll 于 2012-6-13 21:30 发表
这个时候如果系统反应过快。好像会加载不上ISO

  不好意思 ,   H大你这句我没搞懂,  能说详细点么

幸运的草

经过长时间的测试，终于知道了并不是hook及rehook的差别。而是native版7PE，出现34的机率是：
第一次加载出现34的机率很大，如果第一次出现34的问题，重新启动即在停留界面输入reboot命令，第二次就可以正常进入桌面。

　　至于为何这样，目前还不知，好像BIOS还需要进行学习才能识别？