119 replies to this topic

[maanu]

ok no problem , i will check and report back if any issues with latest winvblock

thanks a lot /

oh and by the way , have a look at last post of this topic

http://reboot.pro/11731/

same user reported success in same matter as this topic has/

[Vortex]

Hi Sha0,

Thanks for the latest development release. I tried it and again the Server 2003 installation stopped with the blue screen reporting the 7B message.

What is interesting is that if I replace the Server 2003 .iso file with an XP .iso file, everything works fine. Trying the XP installation, the real partitions of my hard disc and the virtual partition hosted by the .img file are visible in the setup options : selecting the virtual partition does not cause any problem.

The .iso file is specified now without the -- mem option :

map /W2K3STD.ISO (hd32)

or

map /XP.ISO (hd32)

The .img file has a MBR and a partition.

Edited by Vortex, 22 January 2011 - 11:23 PM.

[Sha0]

Hi Sha0,

Thanks for the latest development release. I tried it and again the Server 2003 installation stopped with the blue screen reporting the 7B message.

!!

What is interesting is that if I replace the Server 2003 .iso file with an XP .iso file, everything works fine.

Is the Windows Server 2003 .ISO an official, unaltered image file of a disc from Microsoft? That confirms what maanu was saying was a common problem, but strikes me as highly unusual... I just re-tested in VMware Workstation and it works. Testing in QEmu though, it didn't work.

So another question: What kind of HDD are you using to store the .ISO and image file? USB? SATA/AHCI? IDE?

Trying the XP installation, the real partitions of my hard disc and the virtual partition hosted by the .img file are visible in the setup options : selecting the virtual partition does not cause any problem.

And is that XP .ISO an official, unaltered image of a disc from Microsoft?

The .iso file is specified now without the -- mem option...

...The .img file has a MBR and a partition.

Excellent. I assume you are saying that: You have encountered success for booting an XP installation .ISO with both that .ISO and an image file as G4D sector-mapped disks. If so, thanks for reporting!

I'll try to figure out why QEmu isn't booting properly; maybe it's your same problem.

[maanu]

Shao .

before you test on ur real hardware , please be informed that issue with server 2003 DOES not occur on a few models of hardware . but that is very rare . i have read about it in firadisk thread that the same problem occurred on 1 system , while it worked on another (talking about server 2003 )

for more information , use google translate and read the following thread ,

http://bbs.wuyou.com...23&extra=page=1

specially 6 and 7 page .

[Vortex]

Hi Sha0,

I am doing my test on a real hardware. It's an Intel D865GSA mainboard with Pentimum IV 3.2 Ghz processor. My SATA hard disk storing the .img file operates in IDE mode. Both of the images are from MS : XP SP3 and Server 2003 SP2

The tool I use to create the .img file is CreateRawImg.exe created by TheK, a member of this forum. I will try to recreate the .img file with another tool.

You wrote :

I assume you are saying that: You have encountered success for booting an XP installation .ISO with both that .ISO and an image file as G4D sector-mapped disks. If so, thanks for reporting!

I installed XP with the option map /XP.ISO (hd32) , a sector-mapped disc. I will test also the RAM booting option map --mem /XP.ISO (hd32)

I can confirm Maanu's statement below: I had only one success with Server 2003 installation, it was a Biostar motherboard but I don't remember now the model code of the board. The success with 2003 is very rare and another attempt to install 2003 on an Intel DP35DP board failed too.

Maanu's statement :

please be informed that issue with server 2003 DOES not occur on a few models of hardware . but that is very rare

[Vortex]

Hi Sha0,

This time, I installed Windows XP on an .img file created with Firadisk :

devcon disable root\firadisk



reg add HKLM\SYSTEM\CurrentControlSet\Control\Firadisk /v StartOptions /t REG_SZ /d "disk,vmem=C:\xp.img,size=4285338624"



devcon enable root\firadisk

The installation procedure :

title XP setup



map --mem /XP.ISO (hd32)

map /XP.img (hd0)



map --mem /winvblock.ima (fd0)



map --hook



root (hd32)



chainloader (hd32)/I386/SETUPLDR.BIN



title Continue XP setup



map /XP.img (hd0)

map --mem /winvblock.ima (fd0)

map --mem /XP.ISO (hd32)

map --hook



root (hd0,0)

chainloader /ntldr



title Boot XP from image file



map /XP.img (hd0)



map --hook



root (hd0,0)

chainloader /ntldr

Trying the same installation procedure with Server 2003 failed again : BSOD with 7B

I think that the method to create the .img file is not important. You can build an .img file with any tool but it should contain a valid MBR and partition.

Test hardware : The same Intel D865GSA board with SATA disk in IDE mode

[Sha0]

Hi Sha0,

Hello again, Vortex.

I've been trying to track this bug down for the QEmu case, in case it's the same bug. It might be, since VMware works and you and maanu have reported that some models work and some don't.

In investigation, it appears that the GRUB4DOS information is being wiped out by Windows. I see the information by looking at QEmu's memory before the Windows kernel is running, but the information is cleared to all-zeroes after the Windows kernel is running. I do not know why this would happen, but am still thinking about it. Also, I asked in forum member karyonix' thread about a G4D non-contiguous, sector-mapped disk feature.

If the G4D data is wiped out, we aren't finding the G4D disks. This should be verifiable by using MEMDISK. Unfortunately, MEMDISK doesn't produce sector-mapped disks. If you wish to try it anyway, you could:

title with_memdisk

  root (hd0,0)

  kernel /memdisk iso

  initrd /2003.iso

--- EDIT ---

Actually, I just thought of a sneaky way that might work...

title phase1

  root (hd0,0)

  map /2003.iso (0xff)

  map --hook

  kernel /memdisk

  initrd /wvf6.vfd

Where wvf6.vfd would be a bootable floppy image with the WinVBlock files and also GRUB4DOS (again)! Thus GRUB4DDOS -> MEMDISK -> GRUB4DOS -> (0xff)/I386/SETUPLDR.BIN. Although the first G4D's INT 0x13 hook is still unprotected, perhaps having MEMDISK as a middle-man would prevent Windows from erasing the G4D hook.

[maanu]

Shao

have u checked the xp boot process and compared it with server 2003??

if xp's kernel also does the same thing then we r again back to square 0...

[Vortex]

Hi Sha0,

I tried memdisk from syslinux 4.03 :

title 2003 setup



root (hd0,0)

kernel /memdisk iso

map /Srv2003.img (hd1)

map --mem /winvblock.ima (fd0)

map --hook

initrd /W2K3STD.iso

memdisk threw an exception displaying the error message TRAP 00000006 and everything stopped.

About your second method : how to boot the grub4dos loader grldr found inside the vfd file? Can I replace the vfd file with a classical .img file?
The problem is that I don't know how to force memdisk to boot grldr. What to do in the step MEMDISK -> GRUBDOS ?

How it happens that Windows wipes out the grub4dos information depending on the hardware?

[Vortex]

Another failing attempt with the same TRAP 00000006 exception :

title 2003 setup



kernel /memdisk iso

map /Srv2003.img (hd0)

map --mem /winvblock.ima (fd0)

map --hook

initrd /W2K3STD.iso

This time the .img file contains a copy of the .iso file. After map --hook, Srv2003.img becomes hd0

The driver injection method didn't work with the original Winblock V0.0.1.8 release ( installing Server 2003 on a real partition , installing the Winvblock driver and making an .img file of this setup ) The Windows boot logo appears and in some seconds the system restarts itself.

Edited by Vortex, 23 January 2011 - 09:17 PM.

[Sha0]

...
have u checked the xp boot process and compared it with server 2003??

if xp's kernel also does the same thing then we r again back to square 0...

XP is fine. Even 2003 is fine... In VMware. There's something fishy going on... But the bug exists independently of WinVBlock! While running QEmu, after doing the map --hook, I switch to the QEmu monitor with <Control>-<Alt>-<2> and then look at the INT 0x13 vector with:

(qemu) xp /1xw 0x4c

0000004c: 0x9cc00100

That's a segment and an offset. Shift the segment up a nibble, add the offset. 0x9CC0 << 4 == 0x9CC00. 0x9CC00 + 0x100 == 0x9CD00. That's where the INT 0x13 hook should be:

(qemu) xp /19cb 0x9cd00

0009cd00: '\xeb' '>' '\x00' '$' 'I' 'N' 'T' '1'

0009cd08: '3' 'S' 'F' 'G' 'R' 'U' 'B' '4'

0009cd10: 'D' 'O' 'S'

That confirms the G4D hook is intact! Then I switch back with <Control>-<Alt>-<1> and do the chainloader (0xff)/I386/SETUPLDR.BIN and boot. I let Windows boot (without loading the WinVBlock F6 floppy at all) and BlueScreen. Then I switch back to the monitor and inspect the hook again:

(qemu) xp /19cb 0x9cd00

0009d00: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00'

0009d08: '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00' '\x00'

0009d10: '\x00' '\x00' '\x00'

G4D's hook has been wiped!

[Sha0]

Another failing attempt with the same TRAP 00000006 exception...

Are you talking about a Blue Screen of Death or something else?

Also, this really appears to be G4D's fault or Windows' fault. I'm not sure I can fix it in just WinVBlock, because it happens before WinVBlock is run. Still investigating...

[Vortex]

Hi Sha0,

it's not a BSOD. The exception message is displayed after the initrd command and the operation stops completely. It's probably an exception threw by grub4dos or memdisk as I can observe the black & white screen displaying the messages generated by grub4dos and memdisk.

Even if grub4dos is wiped out, isn't the windows installer supposed to detect the real partitions and continue with the setup options?

Edited by Vortex, 23 January 2011 - 10:01 PM.

[Sha0]

it's not a BSOD. The exception message is displayed after the initrd command and the operation stops completely. It's probably an exception threw by grub4dos or memdisk as I can observe the black & white screen displaying the messages generated by grub4dos and memdisk.

If you type all of your GRUB4DOS commands in manually at the G4D CLI, which is the last command executed before this exception? I would guess that it would be the boot command, since MEMDISK cannot cause an exception until it has been booted. Also, please add the pause instruction to the MEMDISK kernel options (where you have iso).

Even if grub4dos is wiped out, isn't the windows installer supposed to detect the real partitions and continue with the setup options?

Nope. Windows wants to attach its boot medium; the CD. Since the CD is a sector-mapped disc in this case, a driver like WinVBlock is crucial. Since WinVBlock cannot find the sector-mapped disk (G4D has been wiped out), there's no boot medium for Windows. FYI, the 0x0000007B code happens right before SMSS.EXE is loaded from the boot medium. SMSS.EXE (in this scenario) is Windows Setup. So to answer your question: Windows Setup hasn't loaded yet. (Not to be confused with SETUPLDR, which is not Windows Setup.)

[Sha0]

Well, some results, at last.

QEmu's "serial port" feature on Windows doesn't function how I'd like it to. It appears that if anything running inside the VM polls the keyboard, then a Windows <-> WinDbg connection won't be made until after a crash; too late for investigation of early kernel processes.

So I had to take my HDD image and convert it to QCOW2 format:

qemu-img convert -f raw vortex_test.hdd -O qcow2 vortex_test.qcow2

So that I could save QEmu snap-shots later. I started QEmu:

qemu -hda vortex_test.qcow2 -serial pipe:com_1

Then I waited until just after Windows' SETUPLDR asks you to press F2 for ASR. I quickly switched to the QEmu monitor with <Control>-<Alt>-<2> and typed:

stop

to stop execution before the kernel was given control. Using <Control>-<Alt>-<1> I had a look at the VM's display and confirmed that I did not see the 80x50 text mode with "blah starting Windows..." at the bottom. I went back to the monitor and saved the VM's state:

savevm ready

Then I closed QEmu and closed WinDbg, then started WinDbg again, then started QEmu again, but with an extra switch:

qemu -hda vortex_test.qcow2 -serial pipe:com_1 -loadvm ready

So with this "trickery," I got WinDbg connected to QEmu after anything in the VM would poll the keyboard. Finally I was able to get an initial break-point established. WinDbg was started like this:

"C:\Program Files\Debugging Tools for Windows\WinDbg.exe" -k com:pipe,port=\\.\pipe\com_1,baud=115200,resets=0,reconnect -b

I mightn't be able to convey how annoying it's been today and yesterday not being able to get an initial break-point for QEmu. But anyway, now that I got one, I set a data break-point on the GRUB4DOS INT 0x13 hook, since it was being wiped.

ba w1 &0x9CC0:0x0100

g

And most fortunately, the break-point was hit! Here was the call stack:

nt!RtlpBreakWithStatusInstruction

nt!KeUpdateSystemTime+0x12c

hal!HalpReenableInterrupts+0xa

hal!HalpBiosDisplayReset+0x36d

BOOTVID!VidInitialize+0x106

nt!InbvDriverInitialize+0x69

nt!Phase1InitializationDiscard+0x14e

nt!Phase1Initialization+0xd

nt!PspSystemThreadStartup+0x2e

nt!KiThreadStartup+0x16

Lo and behold, it's the boot-time video driver that's wiping out the G4D hook (by the looks of it). Not only does it wipe out the G4D hook, but it wipes out the entire EBDA.

I'm not 100% how to resolve this issue, but I can add some code to WinVBlock to display a message on the Blue Screen of Death if this has been detected.

A very interesting report indeed, Vortex and maanu.

[Vortex]

Hi Sha0,

Many thanks for the analysis, much appreciated. Back home, I will retry the setup with memdisk. Another interesting case : as I mentioned before, the driver injection method does not work also for Server 2003. Creating an .img file from a normal Server 2003 installation on a real partition does not work too. Do you think that both of the two cases have a connection with the video driver?

Edited by Vortex, 24 January 2011 - 06:12 AM.

[karyonix]

Interesting investigation

From Google search, there is BIOS emulator in HAL of Windows Vista (both x86, x64), Windows Server 2003 (x64 only).

The x86 BIOS Emulator in the Windows Vista HAL
http://www.geoffchap...6bios/index.htm

Calling BIOS from Driver in Windows XP x64
http://x86asm.net/ar...windows-xp-x64/

I don't know whether it is related to this problem.

[Wonko the Sane]

Cannot say if useful but in XP embedded there is something intended to boot a "headless" system.
BUT it seems like the actual bootvid.dll is required anyway:
http://www.iwecom.co...dlessSystem.pdf

Since the ReactOS bootvid.dll is "compatible":
http://reboot.pro/360/
http://www.911cd.net...showtopic=19706
maybe one could see if that call/whatever can be removed.


Wonko

[Vortex]

Hi Sha0,

At work, I installed Server 2003 ( real partition ) on a Biostar 945GC-M4 motherboard with Intel 82945 Express VGA card. After installing the latest development release of Winvblock, I created an .img file of the system partition and made the necessary modifications in the registry \ the MountedDevices section. grub4dos booted successfully the OS on the virtual partition hosted by the .img file. This was my only successfull attempt with Server 2003

A second trial was to perform an unattended installation on the same hardware. Copied the I386 folder and created the $OEM$\Textmode folder. Created the unattended.txt file. The first gui phase initiaded by winnnt32.exe goes without problem. Rebooting the system to move the text mode phase, I get a BSOD with 7B displaying the message :

Winvblock: Alive

[Vortex]

Hi Sha0,

Trying the .iso installation on the same Biostar 945GC-M ended with BSOD 7B : Winvblock: Alive

title Install Server 2003



map --mem /winvblock.ima (fd0)

map /Server2003.iso (0xff)

map /srv2003.img (hd0)

map --hook 

chainloader (0xff)/I386/SETUPLDR.BIN

[Sha0]

...Do you think that both of the two cases have a connection with the video driver?

If the bug I found is the same one that you, maanu and others are experiencing with some hardware, then yes, it would absolutely be responsible for preventing WinVBlock from finding GRUB4DOS virtual disks.

It wouldn't matter if you took an already-installed OS image with WinVBlock or Firadisk already installed. If the G4D INT 0x13 hook is obliterated, there's no way for WinVBlock to find the G4D virtual disk, regardless of what's inside the virtual disk. (Except, see further below...)

...From Google search, there is BIOS emulator in HAL of Windows Vista (both x86, x64), Windows Server 2003 (x64 only).

The x86 BIOS Emulator in the Windows Vista HAL
http://www.geoffchap...6bios/index.htm
...

Yes I've read Geoff's article before. Thanks.

...maybe one could see if that call/whatever can be removed. ...

Yesterday I produced a dummy BOOTVID.DLL that does nothing. The QEmu VM still crashed and the G4D hook (and EBDA) was still wiped, so that means that another module must have called into HalpReenableInterrupts() or otherwise wiped it. So I must retract the statement that BOOTVID.DLL is the culprit; perhaps it's the HAL, itself.

...At work, I installed Server 2003 ( real partition ) on a Biostar 945GC-M4 motherboard with Intel 82945 Express VGA card....This was my only successfull attempt with Server 2003

A second trial was to perform an unattended installation on the same hardware...Rebooting the system to move the text mode phase, I get a BSOD with 7B...

Hmmm... That test is quite useful. What the test's results suggest to me is that an already-installed OS' HAL is not wiping the hook, but Windows Setup is perhaps using a HAL that is. One thing I noticed yesterday was that the MP kernel was loaded when booting Windows Setup, so perhaps an MP HAL is loaded, too. The QEmu VM was uniprocessor.

...Trying the .iso installation on the same Biostar 945GC-M ended with BSOD 7B : Winvblock: Alive...

"WinVBlock: Alive" confirms that the driver was successfully running, but must not have found any disks. I'll change that message to say how many disks it found.

[Vortex]

Hi Sha0,

An already-installed OS' HAL is not always successull. My computer with Intel D865GSA board at home restarted itself. The .img file was prepared from a ready Server 2003 system ( Install Server 2003 on real partition -> install winvblock -> create the .img file from this setup )

[karyonix]

Let's try change int15 e820 handler to remove area occupied by int13 handler (and EBDA) from range of available memory it report.
(link removed)

EDIT: Remove the link. There is newer test build.

[Vortex]

Hi karyonix,

Finally, I am happy to announce success :

title Server 2003



map /srv2003.img (hd0)

map --hook 

root (hd0,0)

chainloader /ntldr



title Install Server 2003



map --mem /winvblock.ima (fd0)

map /Server2003.iso (0xff)

map /srv2003.img (hd0)

map --hook 

chainloader (0xff)/I386/SETUPLDR.BIN



title Continue Server 2003 installation



map --mem /winvblock.ima (fd0)

map /Server2003.iso (0xff)

map /srv2003.img (hd0)

map --hook

chainloader (hd0)+1

Latest development release of Winblock from :

https://github.com/Sha0/winvblock

karyonix, many thanks for your grub4dos attachment. Kindly, could you make an official release of your version?

At home, I will test on my D865GSA board.

Also, many thanks to Sha0 for his support.

Edited by Vortex, 24 January 2011 - 03:57 PM.

[Sha0]

Let's try change int15 e820 handler to remove area occupied by int13 handler (and EBDA) from range of available memory it report.
http://www.mediafire...rub4dos-test.7z

Hmmm... I just tried it out but without any luck. However, I'm not 100% sure when this code gets executed. Upon map --hook or at GRUB4DOS load-time? I read the diff, but didn't read the context from the source code. When I ran displaymem after hooking, I still saw the EBDA as the bottom of that reserved area (rather than the INT 0x13 hook).

Thanks, though!