jaclaz

You know how Windows 7 is promoted: http://www.beingmanan.com/wp/2010/03/microsoft-launches-campaign-for-windows-7-professional-you-spoke-we-listened/ You do understand how with this clever idea, it is NOT MS's fault as usual , it's the dumb*** that spoke that should be crucified: http://www.imdb.com/title/tt0079470/quotes jaclaz

The first error - long before the dd one - is related to missing files: 1) Does C:\INST\XP_RAM\I386\txtsetup.sif exist? 2) Try copying bootsect.bin to C:\INST\ also. jaclaz P.S. Sorry cdob, cross-posting, though the bootsect.bin appears like a problem with the path of it in mkisosf options, it seems to me like it is needed in two places: pushd "%SourceDir%" if not exist %boot_sector_file% ( echo.&echo error: boot sector file not found &call :Help &pause &goto :eof) this checks for it in C:\INST\XP_RAM\ while mkisofs seems like looking for it in C:\INST\

You manually get the relevant parts, of course. Problem is which are them. Have you checked the actual reference for the USMT?: http://technet.microsoft.com/en-us/library/cc722032(WS.10).aspx I presume you can "break down" the migration in "smaller chunks" and find out which are the items that will choke the wizard. jaclaz

Does this method works allright if you don't sort anything? jaclaz

Probably nothing. Simply the stoopid BIOS of your stoopid thinclient cannot boot from USB if not a number of settings are made to the stick. This has unfortunately nothing to do with the "main" app, it's an "earlier" problem that - if it can be solved - will take us WAY OFF-TOPIC. I have a better idea, post your address, one of us will call at your home and make that stick bootable for you. Comeon this is a public technical forum, if you are game for it, let's try troubleshooting the issue and hopefully solve it, but private one-to-one help? Please start a new topic here: http://www.msfn.org/board/forum/157-install-windows-from-usb/ and we will try and help you. jaclaz

Probably it's a misunderstanding between "offset 50" and 50th. (which of course is 51th ordinal if offset 0 is called 1st byte). The "10 bytes" at offset 26x are the re-mapping of the .exe to point to the Virus executable code, obviously they are different, in the exact same manner as the original .exe's were different in size. http://www.avira.com/en/threats/section/fulldetails/id_vir/2661/w32_stanit.html The resizing of files, like the install_flash_player_9.exe of your example, is atypical, but it may due to the particular structure of self-extracting/installer files (i.e. they may have a .exe "stub" with appended to it the actual compressed archive of data and the virus may only consider the executable filesize). jaclaz

Good question , unfortunately no answer for it , but : jaclaz

Try reading Stanit instad of Tenga.A : http://www.avira.com/en/threats/section/fulldetails/id_vir/2661/w32_stanit.html @Multibooter Sure, I thought that the probelm was ONLY when you run XP. I am pretty sure there are similar tools fro W9x/Me. jaclaz

Then, your build is most probably missing the appropriate SATA drivers. Check what the PC that doesn't boot and the PC that does boot have different, like: Processor Hard disk bus (like ATA/IDE or SATA or SATA set in BIOS as IDE compatibility or as AHCI) Chipset Hopefully the linked to set of programs should make the USB install more or completely "universal". jaclaz

Read here: http://www.robvanderwoude.com/ntfor.php http://www.robvanderwoude.com/ntfortokens.php jaclaz

Maybe it had not enough time, it may well have a "list of priorities" and only infect a few files per session, for all we know. jaclaz

You cannot say. MRU is in Registry. NTFS normally updates last accessed time in the filesystem. Use this - in case you feel dangerously exposed : http://www.nirsoft.net/utils/clean_after_me.html jaclaz

Not a wise decision , if I may, you were lucky they didn't actually manage to ruin the thingy for real , according to the "standard" with which they are reported to operate usually. jaclaz

Not exactly useful, but thanks anyway. You want to test the restrictions? AFAIK there are none, but PMing Peter (psc) and ask him directly, or better post in the related thread: http://www.boot-land.net/forums/index.php?showtopic=9658 won't make any harm. If you want to copy/use/modify/extract info/peruse anything from the small batches or .inf, you are of course welcome. jaclaz

Well, that's ANOTHER thing. At least as I see it: RC=Recovery Console=2K/XP/2003 based - started by SETUPLDR.BIN RE=Recovery Environment=Vista/2008/7 based - started by BOOTMGR/whatever I am talking of the first, the second can be used as .iso/WIM booting, but not at all my field. Personally if I were to touch Vista or 7, I would try using something "better" than "pure" RE: http://www.boot-land.net/forums/index.php?showtopic=5917 jaclaz

English is such a difficult language, but I wonder which is the difficult part: Example: You ran: You can see that you DID NOT specify ANYTHING on command line, exception made for the script name. Command lines like these: contain the MINIMUM, REQUIRED parameter (the Source). A sommand line like this: has, besides the minimum, required source the option to use INSTEAD of the DEFAULT bootsector file "bootsect.bin" a custom one, named "myboot.bin". jaclaz

I usually have several of them. Point is which one (if any) would be useful for your problem. First thing I would do if I were you, would be to check (and disable) auto-reboot: http://www.theeldergeek.com/auto_reboot_on_system_crash.htm This way you should get a nice BSOD, which my crystal ball appears like identifying in a 0x0000007b, but we need to make sure of it's id. Then, you should forget the ngine.de guide (not that it isn't good, but it's a bit outdated) and use a newer approach: http://www.boot-land.net/forums/index.php?showtopic=9830 jaclaz

Sure, but the .iso MUST be a RAMDISK one, unless the scope is that of having a nice BSOD (a 0x0000007b if you want to know which one). The problem is NOT in the initial boot stage, it is in the second part, when the "protected mode" kicks in. If the MS RAMDISK booting is used, OK. If firadisk or winvblock are used to hook the image loaded in RAM by grub4dos, OK. If diskless angel or some similar NT driver is used, OK. I am not aware of any different method, not using a specific driver, you really should be reading the already given links: http://www.boot-land.net/forums/index.php?showtopic=8944 http://www.boot-land.net/forums/index.php?showtopic=4952 jaclaz

Is this a rethorical question/doubt or you want to know how to make a RC .iso? If the latter, here: http://www.boot-land.net/forums/index.php?showtopic=2254 http://tips.vlaurie.com/2006/05/recovery-console-for-those-without-an-xp-disk/ More info on RC booting as .img or .iso: http://www.boot-land.net/forums/index.php?showtopic=5316 jaclaz

It would be a very good finding, even small pieces are important to put the puzzle together. jaclaz

If you are getting ANSI characters it's working. If you are getting GARBAGE characters (let alone if ANSI or ASCII ) it is NOT . Usually the problem is missing, or ineffective GROUNDing. Do a loopback test first, just to make sure the converter is working, then check that grounding the HD to BOTH the converter AND the power supply is effective. jaclaz

Is this a joke or what? HOW do you run it? By double clicking on it? It is a BATCH file! You need to open a command prompt and "run" it specifying the options (if needed) and AT LEAST the Windows_source_directory. The defaults are: rem some defaults set boot_sector_file=bootsect.bin set IsoFile=%~dp0XP.iso set SourceDir= set mkisofs_option= and, obviously you will need the external exe's: rem used external applications rem mkisofs.exe : http://cdrecord.berlios.de http://www.student.tugraz.at/thomas.plank/ rem dd.exe : http://www.chrysocome.net/dd rem gsar.exe : http://home.online.no/~tjaberg jaclaz

It is possible that you are falling/have fallen in this problem: http://www.boot-land.net/forums/index.php?showtopic=9897&hl= or anyway something closely related to it. jaclaz

The link is working for me, and memdisk is NOT used. We are talking about RAMDISK booting, not "memdisk". jaclaz

And the answer is ...... .....yes and no. grub4dos and syslinux are generally developed "in parallel", though the developer teams are different, as soon as one of the two gets to make a new feature work, the other one adds it and viceversa. When it comes to choosing it is more a matter of personal experience and "feeling" than anything else, but also remember that they are pretty much exchangeable, as grub4dos can generally chainload Syslinux and Syslinux can load grub4dos. I personally prefer grub4dos because of it's command line capabilities and the fact that the same loader works on all media, others prefer Isolinux/Syslinux: http://www.boot-land.net/forums/index.php?showtopic=8546 Where to find info about both: http://www.boot-land.net/forums/index.php?showforum=66 http://www.boot-land.net/forums/index.php?showforum=92 jaclaz