steve6375

I noticed a similar thing. If you use oscdimg to make a Win 7 ISO using -m -n -h and then boot the ISO using grub4dos, grub4dos cannot see the bootmgr file and an ls of the contents just shows README.TXT which says it contains a UDF filesystem. grub4dos cannot read it. If however, you use the -u1 switch with oscdimg to prepare the iso file, grub4dos can read it but the filenames are in capitals. You can now boot using either chainloader (0xff) - which prompts you to press a key to boot from CD OR chainloader (0xff)/BOOTMGR - which does not prompt you to press a key and just boots immediately

If this works on a Tosh, then check the BIOS settings (especially HDD Mode = AHCI and set to compatible or disabled or IDE).

@Davlak Did you delete the partitions and reformat using XP Setup or did you leave the existing partition and just reformat. If you have off-track partitions (such as made by WinPE v2 and v3 DISKPART) then it may well fail to boot from HDD. Always create a new partition for your tests. I have to use DISKPART with the CRE PRI ALIGN 1065 command in WinPE v2/v3 before running winnt32 to ensure the partition is on a cylinder boundary. It may be the same with Setup?

This sounds like the BIOS e820h memory map function is returning incorrect memory size data. grub4dos will place the iso at the top of RAM. It is quite common for BIOSes to incorrectly report the size of memory and so grub4dos may load the ISO into memory locations that are being used for something else - shared UMA graphics memory for instance - and then the code gets trashed by the BIOS before it can be run! MemTest86+ reports e820h memory size parameters when you run it - but for this test you should not load it into memory using --mem via grub4dos or it may crash or itself modify the parameters returned - I would recommend booting from CD and running it. MemTest86+ may even fail if it tries to test memory near the top which is not there... I have reported many such errors to mainboard and notebook manufacturers over the years! Basically, Int 15h e820h reports free memory - if you try to use all the memory reported as 'free' and then test it, it fails because the values returned by the BIOs were incorrect. See this post for an explanation of what this does http://www.masm32.com/board/index.php?PHPSESSID=7c1e51e2a37a3e2e9e5873bffc9c8c21&topic=1399.0

I only just came across this post having just worked out a similar solution using ImDisk that works for 32 and 64 bit ISOs - see http://sites.google.com/site/rmprepusb/tutorials/winiso

I use this method - see http://sites.google.com/site/rmprepusb/tutorials/install-xp-from-an-iso You can use either WinVBlock or Firadisk (both are included in my F6 floppy image). If using FiraDisk you must use map --mem at both stages. If using WinVBlock the first stage can directly map to the XP ISO.

map --mem /Images/XP_RAM.ISO (0xFF)

I had similar issue to Wimb. See my tutorial on RMprepUSB website at http://sites.google.com/site/rmprepusb/tutorials/install-xp-from-an-iso Step 1 works fine when directly mapped to the ISO Step 2 GUI stage crashes unless iso is mapped using --mem :-( @tonyzg - re. RMPrepUSb and flashing cursor. Did you try latest version of RMPrepUSB = v2.1.617. This should be fixed. If not can you send me the contents of the MBR of your working USB drive as it seems that the systems that give a flashing cursor do not like the RMPrepUSB MBR??? The latest version has a modified version of grub4dos too so you can install to MBR or PBR. I would be interested to know if they both worked on all your systems?

Could be useful but Does not work if path to WIM file has spaces in it. You need to put double-quotes around path.

Just a warning about PCs with more than one SATA hard disk. There is a problem with WinPE (and Vista/Win7). When *some* systems boot, HDD0 may be \\.\PhysicalDisk0 and HDD1 may be \\.\PhysicalDisk1 BUT on some systems they may be the other way round sometimes - i.e. HDD0 is \\.\PhysicalDisk1. This happens randomly and is unpredictable. For instance Intel DQ45CB and Intel DQ57TM mainboards with two SATA hard disks do this. MS have put a new command into Diskpart in the WinPE v3 version to work around this. SELECT DISK SYSTEM will select the 'first' hard disk which MS define as the 'system' disk. SELECT DISK NEXT will then select the 'next' disk up. So any script you use should use this and not SELECT DISK x. This is OK if you have a system with an OS on one of the disks, but if you have two completely blank hard disks to start with, PhysicalDisk0 could be any one on any boot! This is a big issue for OEMs who automate OS installs onto systems with two non-identical drives, the OS can be installed randomly on the smaller drive or the larger drive! The best way to get around this issue is to disable one drive in the BIOS Setup menu or unplug one SATA drive.

Just a thought, but is AHCI enabled in the BIOS? If so disable it.

Hi, Steve. Didn't know you were member here on MSFN too. Just for the record, here we are talking about installing XP from USB - which DOES NOT and CANNOT work when booted with grub4dos .iso mapping UNLESS Server 2003 SP1 or R2 files are used with a RAMDISK approach. jaclaz Hi Jaclaz OK, I hadn't tried it. But what I do know is that you can boot to WinPE as I described in my link above. So if you put WinPE.iso on the USB stick and had the XP install files on the stick too (in straight folders) then you can install XP onto the hard disk using WinPE as the installation OS. Just partition and format using Diskpart, copy over the XP files to C:\i386, then run winnt32 and then Exit to reboot to the hard disk and let the XP install continue. There are a few caveats - you need to ptn the hard disk using WinPE Diskpart, so you must use the ALIGN=16065 switch with diskpart. You also need to use BootSect or RMBootSect to make an ntldr (/nt52) bootloader on the hard disk before you run winnt32. This is the way we install XP at our factory (but we boot directly to WinPE from USB and not via an iso and Grub4DOS). If you need the exact command line to run winnt32.exe I can dig it out for you. cheers S

RMPrepUSB will clean, partition and format a USB stick and then if you have the tick box selected, copy the folder you have specified to the USB stick. The 'This device is classed as USB-ZIP' means that of the three types of USB writeable mass storage devices (USB-FDD, USB-ZIP and USB-HDD) your USB stick is classed as USB-ZIP / Removable Drive. A USB Hard disk would appear as USB-HDD (Fixed Disk). Most USB sticks appear as Removeable. If you run a utility like BootIt.exe and use the 'Flip Removable Bit' button - then unplug and re-plug - it may change your USB stick to a USB-HDD device. If it works (and I have only see it work on Netac and Lexar USB sticks so far) then the USB stick will appear as a USB-HDD. If you can get this to work then you will have a much better chance of getting any BIOS to treat the USB stick as a hard disk. The 2PTN switch is to add an extra tiny hidden ptn which helps some BIOSes to treat the USB stick as a hard disk (USB-HDD) and not a USB-ZIP. XP, WinPE and Vista need to boot from a hard disk or a CD. These OS's think that any device that has a normal MBR + ptn table is a hard disk (if it is accessed by the BIOS using Int 13h DL=80h which is used for hard disk access). The problem is that some BIOSes map a USB stick as a super-floppy (USB-ZIP) and these don't have an MBR once the BIOS boots to them as the BIOS returned the Volume Boot Record when the MBR (block 0) is requested - ie the BIOS is trying to fool any OS that is on the USB stick into thinking it is a floppy. Also, they are accessed via Int 13h DL=0 which is used to access floppy disk devices, so the OS will not see a hard disk unless you also have a real hard disk attached. Hint: Always have a real hard disk attached when you are testing USB bootable sticks as you can get unpredictable results if the OS sees no hard disk at all in the system even if you can fool it into booting from a USB stick. A way to test if the BIOS is 'converting' the USB stick to a USB-ZIP super-floppy is prepare using RMPrepUSB to put MS-DOS on the USB stick (no config.sys or autoexec.bat). If the prompt is C:> then the BIOS is booting it as a hard disk. If the prompt is A:> then the BIOS is booting it as a floppy disk. Try different BIOS settings and RMPrepUSB settings until you can get the C:> prompt. Experiment with FAT16 and FAT32 and NTFS. I have found that some BIOSes completely ignore any USB stick that is over 512MB in size - for this reason I would recommend a Lexar or Netac 512MB USB stick for all trials. So set BIOS to 'Fixed disk' not Auto or 'Removable' - use RMPrepUSB with 2PTN switch and FAT32 (also try FAT16 and NTFS if that does not work). Another tip - if it seems to try to boot but fails - try setting the USB speed in the BIOS to low speed - I have seen this work on a few BIOSes (slow but at least it boots). Once you have a successful but slow boot - change the BIOS setting back to fastest speed (480mbs) and see if it still boots. HTH Steve

I (author of RMPrepUSB) have tried booting to WinPE v2 (Vista PE) on an Asus notebook using RMPrepUSB with no success - but - I did manage to get it to boot using FreeDos + Grub4DOS + iso boot by mapping the iso to (fd0). This might work for an XP install CD as an ISO. see here This method seems successful when the BIOS is determined to treat the UFD as a super-floppy. I have not tried fbinst but it may be just what you need.... Steve

Hi Just a few other things to be aware of with ImageX: 1. When you apply an image, ImageX will change all junctions (reparse points) to point to the current drive letter. e.g. If you capture drive C: as image 1, then partition a new disk which WinPe gives letter of D: to, when you apply the Image 1 to D:, ImageX will change the junctions points to point to D: . Now if you boot the hard disk and the partition is now C:, the junction points will still be hard coded to point to D: and will all be incorrect. To check this type DIR C:\ /a:L in Vista - C:\Documents and Settings junction point should point to C:\Users. To fix this problem, capture the image with the /norpfix switch, this stops ImageX from changing the Junction points. Alternatively, when you apply the image, make sure the drive letter that you apply it to is the same as it will be when the system is booted. If the junction points are wrong for a Vista OS, then some XP app installers will not work and some XP apps may not work. (why did MS not set the default as /norpfix ???) http://technet.microsoft.com/en-us/library/cc749447.aspx 2. Bug in ImageX - if you delete 2 images from a WIM file in succession, it will completely corrupt the WIM file!!!! See http://support.microsoft.com/kb/947247 (which is inaccurate as it does not mention you have destroyed your WIM file!) HTH Steve

i could burn it so i could test i tryed on different machines. all same error. Hi Try it on a different mainboard. Some mainboards give this error but most other mainboards boot fine from the same USB drive. On one mainboard D915GUX, I can boot a USB CD drive WinPE image, but cannot boot the same image when using a USB flash memory stick - but the same stick does boot on every other mainboard I have!

Hi You must partition the USB drive under Vista or WinPE. It won't work if you partition under XP, even if you use Bootsect afterwards. Having said that, I have written my own utility which WILL allow you to use only XP to partition and install WinPE on a USB stick from scratch :-) HTH Steve

Hi I haven't tried this yet but have you tried en-GB instead of en-UK?

Hi I am also trying to write an ImageX app. However, I don't want to use .Net because there is no official support for this in WinPE 2. Even if .Net was added to WinPE 2, then we could only load WinPE in Ram on systems with 1Gb of memory or more. As it is WinPE 2 needs over 256Mb of ram and adding .Net would probably leave little free ram. If anyone has the wimgapi.dll working with VB6 and can supply me with some basic VB6 code for using it I would be very grateful. Thanks

Hi It is my understanding that the .Default in XP is NOT where a newly created user will inherit from. This is held in the ntuser.dat reg file which is in each users Documents and Settings folder. To change this you need to load the HKU hive using reg.exe, then patch your values (either using regedt32 with the correct hivename in the keys, or using reg.exe ADD command lines) and then unload the hive using reg.exe again. If you do this on the 'Default User\ntuser.dat' file then any newly created user will inherit these settings. To set an html file as wallpaper, you also need to set the ShellState to enable viewhtml - but I haven't quite got this to work yet! The html does get set as the wallpaper, but for some reason it makes the screensaver screw up! HTH Steve