再次修改标题！！新版的grldr已经解决了在某些联想老主板上与KON存在内存冲突的问题

不点

map 之后的内存不正确。可能是 grub4dos 的 bug。最后两个内存项目是一样的，这是错误的。

需要贴出 0x413 以及 0x40E 处的值。

做好准备，这个问题可能需要很长时间才能解决。

请使用新版 GRUB4DOS 来运行 memcheck 命令。

你可以这样来运行它，即指定路径：

(...)/.../memcheck

[ 本帖最后由 不点 于 2012-3-20 01:08 编辑 ]

zjzaog

不点大师您好
刚才试用了带不带mem，结果是一样的！
放在非ud区，结果也是一样的！
都以失败告终，我再去试试0x413和0x40E

zjzaog

前两张是map之前的，后一张上是map之后的

[ 本帖最后由 zjzaog 于 2012-3-20 01:57 编辑 ]

zjzaog

接下来请看memchek的结果

zjzaog

memchek的结果，这是0.4.5c 2012-2-27的

[ 本帖最后由 zjzaog 于 2012-3-20 01:58 编辑 ]

zjzaog

原帖由 不点 于 2012-3-20 00:10 发表
看来很难定位了。

先测试一下你的内存布局。有一个外部命令叫做 memcheck，运行于 grub4dos。你在运行了

map --mem (ud)/TOOLS/KONBOOT.IMG (fd0)
map --int15nolow=1
map --hook

之后，手动运行 memcheck 贴出显示结果。

memcheck 命令可以从以下帖子中找到和下载：

http://bbs.znpc.net/viewthread.php?tid=6146

建议你也通读一下这个帖子，以便能够贴出更多的有用信息。

不点大师请注意，以上的图作废，因为我刚刚又忘了运行map --int15nolow=1这一行，请看下面的描述：
我重新拍图，请观察，0.4.5c运行konboot还是进不去系统，会出现错误！
现在按照您的指示，在运行一下菜单前后都拍了图下来，请观察
map --mem (ud)/TOOLS/KONBOOT.IMG (fd0)
map --int15nolow=1
map --hook


===============
请看#86楼更加清楚详细的拍照

[ 本帖最后由 zjzaog 于 2012-3-27 15:22 编辑 ]

不点

好的，够我消化一阵子了。这些天还有事，可能要等待一些时间才能着手做。

chenall 或者 yaya，以及 zw2312914 可以看看毛病在哪里。

chenall

看起来问题 挺严重的，我对这些不太了解。暂时没有办法,

对了楼主用的是什么样的主板啊，我这里都是正常的。

zjzaog

2006年的联想整机，这是我的主板名称：下面附带主板的详细报告
主板:
      主板 ID                                           07/13/2005-K8M800-8237-6A7L1E19C-00
      主板名称                                          Muse K8M800-M3

[ 本帖最后由 zjzaog 于 2012-3-20 23:24 编辑 ]

zjzaog

用7月14号前（包括7月14日）的版本的grldr在map前和map后，memcheck的结果是一样的，但是7月14号之后的版本的grldr在map前后的最后一行不一样！read 0x413的结果也不一样

原帖由 rockrock99 于 2011-7-28 18:00发表在时空论坛
近期版本在戴尔Inspiron Laptop N4030笔记本上遇到问题
如题
启动PE中途蓝屏
错误代码：
STOP:0x000000B4(0x8A08A7F8,0x8A084000,0x89F6A000,0x00050000)

目前已测试版本
grub4dos-0.4.5b-2011-07-28 失败
grub4dos-0.4.5b-2011-07-24 失败
grub4dos-0.4.5b-2011-07-14(含以前) 均成功

怀疑跟"2011-07-21 (tinybit)added a map option --int15nolow. Some changes on handler."此项有关

看来这位仁兄跟我碰到的问题相似，但是他的解决方法为什么不适用于我？？不过我们的相同点是7月14日之前的版本的grldr都能用。

[ 本帖最后由 zjzaog 于 2012-3-20 23:52 编辑 ]

幸运的草

原来，我运行这个工具在VM中测试正常但在实机出问题，还以为是我机器的问题。
但看了楼主的问题，今天我也下载2011.7.10日的GRLDR测试，调用出现界面并启动WINDOWS成功。
但换新版grub4dos-0.4.5c测试，可以出现kon的界面并检测，然后出现以下提示。
Computer or run a configuration program provided by the manufactu：
Memory Map:
               00000000-0009B400
直接卡死（真卡死）。
联想机。主板型号：ms-7102

chenall

也是联想的？？巧合，还是？？？？？？？？？

zjzaog

C大，在7月14日到24日之间发生了什么样的改变，一定要重点研究哦！！！！似乎map机制有变化呀，memcheck的结果不一样，而14号前（包括14号）的则memcheck的结果一样，似乎以前的map机制更猛一点点……

幸运的草

个人认为应该是巧合，因为我的是老机，05年产的机。而新版G4D才只是去年的事。因此，没有理由认为是厂家的人为打压的问题。
对KON这个工具，只是在U盘中带有，实际根本就没有使用过。只是一个偶然的因素，试用了一下，发现真机出问题，也没有在意。而今看了楼主反映的问题。才引起注意，验证了一下。

刚对单位04年产的联想机测试，主板型号：ms-7067.
结果同＃41一样，只是提示信息有变化：
Memory Map:
                map:00000000-0009AC00

[ 本帖最后由 幸运的草 于 2012-3-22 10:11 编辑 ]

chenall

知道了7.14之后的版本出现问题就比较好定位了。

zjzaog

你同事的机子，如果用7月14号前的grldr有问题没有呢？

幸运的草

我＃44已经说了，测试结果同＃41的相同，也就是说7.14前的版本没有问题。
只是提示信息有点变化。但这台机识别U盘是是ZIP，那台机是HDD。

不点

这个问题属于 grub4dos 仿真代码中 int15 处理程序的 bug。好像 zw2312914 前不久已经发现这个问题了。当时我没在意。

放心吧，这个问题一定能够解决。只是暂时有别的事，忙不过来。

请耐心等待。

thttht

大大在这里借用地方请教一个问题！我在用--top的参数加载文件时为什么iso文件类型的光驱镜像可以正常启动，加载img的硬盘镜像里的Win2003系统时就07b蓝屏啊？--top参数的使用有什么要求吗？我的这个 img的win2003是用Firadisk 0.0.1.30驱动 做的RAMOS!

我也试了7月10日的版本，不过也不能用 --top的参数启动，同样会蓝屏！不知道我的这个问题是哪里的问题啊？是我系统的问题，还是我主板硬件的问题或是 Firadisk 驱动的问题？

并且zhaohj大让我在菜单头部加入下面这个保护内存再用 --top的参数启动，可这样还是会蓝屏！


default 0
timeout 10
checkrange 524:-1 calc *0x413 & 0xffff || map --int15nolow=1
map --e820cycles=3

------------------------------------------------------------------------------------------------------------------------
说明一下。我的机器内存为：5G


下面是主板内存大小的截图：





现在贴出截图，
这是使用--top的参数加载img的截图： （这部分截图用的是2012年2月27日的版本）











这是没有使用--top的参数加载img的截图：






============================================================================================

这里是加载iso文件的截图：（这里说明一下，这部分截图用的是2012年3月20日的版本，2012年2月27日的版本情况相同就没有在从新用2012年2月27日的版本截图 ）


加载iso文件时用不用 --top参数 都不会蓝屏，都可以正常启动！

这是使用--top的参数的：








这是没有使用--top的参数的：







[ 本帖最后由 thttht 于 2012-3-24 17:11 编辑 ]

zhaohj

Usable RAM: Base: 0x100000000, Length: 0x80000000
-----------------------
上面计算是否有误啊，他的机器一共5G内存，而这里解释是：可用内存区域4G开始长度是2G的范围。

再看map --mem --top的映射情况：
Start_Sector=b96ff8，即5933M开始的

[ 本帖最后由 zhaohj 于 2012-3-23 11:38 编辑 ]

不点

好的，现在研究 36 楼的贴图。发现了问题。

在 map 之前，read 0x40e 显示 9F80（只有低 16 位对我们有用），这表示，主板的 EBDA 起始于 9F80:0000 即，0x9F800，它占据多少空间呢？应该占据 2K 的空间，也就是，在 0x9FFFF 处结束。

而 read 0x413 也显示，用户可用的内存是 0x27E，也就是 638，单位是 KB。而我们都知道，总的常规内存是 0 - 0xA0000，共 640 K。因此，位于顶端的 0x9F800 - 0xA0000 之间的 2K 空间是用户不应该使用的内存，而位于它之下的内存 0 - 0x9F800 是用户可以使用的内存，共 638 K。

两者是不矛盾的。

但是，map 之后的显示，就有问题了。大家知道，grub4dos 的代码占据 12 K 的常规内存，因此，map 之后，用户可用的常规内存的量应该变成 626 K（638 - 12 = 626），换算成 16 进制，等于 0x272。但贴图显示的却是 0x26c，相差了 6 K。这是不正常的。grub4dos 本身应该不会犯下这么严重的错误。因此怀疑，用户在 map 之前，还有别的、 grub4dos 之外的仿真程序参与了其中（例如 memdisk 之类）。这 6 K 应该是别的仿真代码（memdisk 之类）所占据的空间。

根据以上分析，楼主的报告，应该隐瞒了实情。也许你不是故意的，但你事实上隐瞒了实情。或者可以猜测，你从 grub4dos 的相关文献中早已知道，grub4dos 的仿真不可以与别的仿真混用，但你又确实想混用，于是不得不隐瞒实情，以图侥幸得到解决。

如果不隐瞒实情，你应该先在没有 map 的情况下 read 0x413，然后立即在 map 以及 map --hook 后 read 0x413。此时，由于保证了中间没有别的仿真程序的介入，那么，读到的值应该是 0x272，而决不会是 0x26C。


当有别的仿真代码与 grub4dos 一起混用的时候，我们不能保证 grub4dos 的代码能够正常工作，尤其是与仿真相关的代码，更可能会发生计算错误。

如果确认了这一情况，那么这个问题到此为止，不要再解决了。因为无法解决。属于 grub4dos 不支持的情况，用户应该自己解决。

任何东西都是有条件的。违反了使用条件，等于超限使用。

超载、超负荷，其结果是不能预料的。




[ 本帖最后由 不点 于 2012-3-25 12:37 编辑 ]

zhaohj

不点大再分析一下49楼的情况，怎么map --mem --top会跨越5G以上？

不点

你的情况与楼主完全不同，你也知道这一点。

使用 map --e820cycles=3 时，出现任何现象（注意 “ 任何 ” 二字），都是可能的，因而都是正常的。请详细阅读有关的帖子。

ISO 文件能够正常，可能是因为 ISO 尾部的内存空间遭到破坏后影响不严重。IMG 文件不能正常启动，则可以解释为，该 IMG 文件尾部遭到破坏以后，很敏感，可能使得 IMG 里面的某个关键文件被破坏了。

尝试解决办法：先映射一个无用的 IMG 文件到内存顶端（大小自己试着确定一下），目的是让 Windows 破坏这个文件，从而不至于破坏接下来的、真正有用的 IMG 文件。

注意，“ 任何 ” 可能性都会出现，上述办法不一定解决问题。自己摸索适合的方法。以上是一些试图的解释，而不是完善的理论。

补充说明： 如果在 4G 以上有内存，我估计这是个安全地带。假定 XP 不使用 4G 以上的内存，那么，如果内存盘位于 4G 以上，则它不容易遭到 Windows 的破坏。但是，如果你被迫使用了  map --e820cycles=3 ，则 “ 任何 ” 可能性都有，失败了也不奇怪。


zhaohj:

主板把 5G 内存映射在 6G ，这很正常。只要总共内存加起来是 5G，那就没问题。里面肯定有空洞，即，有些内存是不存在的，或者不可访问的。当你有 4 G 内存的时候，你的主板却指示在 4G 以上还有 几百 M 的可用空间，道理是一样的。主板自己的 ROM 或 RAM 占据了一些内存，因此，它把 4G 中的一些可用内存映射到 4G 以上的内存空间上了。

[ 本帖最后由 不点 于 2012-3-25 14:18 编辑 ]

幸运的草

回复 #51 不点 的帖子

经多台不同时间生产的联想老机测试，2011.7.14前的GRLDR，运行KONBOOT.GZ没有问题。
　FB制作的HDD格式的U盘

菜单：title [3] >运行 KonBoot 免口令模块  \n

map --mem (ud)/BOOT/IMGS/KONBOOT.gz (fd0)
map (hd0) (hd1)
map (hd1) (hd0)
map --rehook
chainloader (fd0)+1
rootnoverify (fd0)

调用后：2011.7.14以后的出现问题。手机拍图如下。卡死。



而KONBOOT.GZ刚好为6KB。不知是否巧合？

幸运的草

注：图片中下方四行提示为KONBOOT.GZ运行的正常提示。上方的三行提示，是在下方的四行提示完后出现的。然后卡死。

to 不点

经测试，2011.7.14以后的GRLDR，确实是对KONBOOT.GZ不兼容，相同的菜单，同一个KON版本，只调换一个GRLDR就出问题。
而调用KONBOOT.GZ根本不需要仿真FIRADISK之类的，而楼主上面也报出了加载菜单。所以，造成内存的问题，您推断的理由不能成立，只能从G4D方面查找原因。
　　而KONBOOT.GZ刚好为6KB。是否为巧合？

[ 本帖最后由 幸运的草 于 2012-3-25 16:34 编辑 ]

不点

确实有这种可能性。konboot 有可能接管了 int13 或者 int15 之类的。不清楚它干了些什么。

这个问题需要深入研究了。


mem map：

0 - 9B400

这说明，此处的内存占用存在问题。让 konboot 的作者解决吧，估计作者未处理好 int15。

你的内存在未启动 konboot 时，是怎样的呢？

read 0x413 以及 read 0x40e 的结果很重要。

不点

底部那四行，可能正是问题所在。它说，它检测到一个 dummy 的 BIOS，不知它的意思究竟是什么。

它还说，它正试图修复内存映射图的项目，也就是 int15 的项目。

猜测，正是它的修复，造成了问题。换句话说，可能是它修复坏了。

不点

7月14 日的版本，不处理常规内存。但 7 月 14 日以后，grub4dos 的 int15 就要处理常规内存了。可能是 konboot 作者未处理好 int 15，它可能总是假定 int15 不处理常规内存，所以，它的修复也就是有问题的。情况大致上就是这样的。

不点

这还得评估一下 konboot 是个什么性质的程序？它为何要接管 int15？

目前我还想不通，它为何驻留在常规内存里面。找不到合适的理由。

幸运的草

不点大师的回复真快：
现按要求补了两张0x413 及0x40e的图。

未map　konboot.gz 前



map konboot.gz 后.




哦，真如你说的那样，就明白了2011.7.14前后的变化。