jaclaz

Sure, you will need a multimeter and some very basic knowledge on how to use it. See here: But once you have found out it actually is a TVS shot, what are you going to do? There may be REASONS why the TVS diode is short-circuited, and removing it may "fry" something (the whatever the TVS diode "sacrificed it's life" in order to protect). It is also possible that it was just a transient on the power line, but if you don't know how to check for a shot diode, with all due respect , I doubt you are able to diagnose the actual cause. jaclaz

Yes/No. The cause may be the particular version of the grub4dos MBR (for the Acer's) or a problem with partitioning/formatting (more likely for the HP's). Typically you should: use beta 7 (latest) use RMPREPUSB to initialize/partition/format the stick (use 2PTNS settings) in case get latest RMPREPUSB try on the "pesky" machines report what happens As an alternative, you can backup your existing stick (with something like the NT backup, i.e. "file-based"), repartition/re-format it with beta 7 (or directly with RMPREPUSB - advised) then restore the files from the backup. In BOTH cases YMMV, if you want to actually troubleshoot the issue, start a new thread an post some EXACT details of HOW the stick is setup/partitioned/formatted AND the exact models you have problems with. Same goes for the Dell's, provided that you already read attentively the FAQ's and complied with what is in them (modified NTDETECT.COM, SATA integrated). jaclaz

If the PSU shuts itself off you have a shorted TVS diode. If BOTH TVS diodes are OK, you will need to try an external USB enclosure. DO NOT try the disk drive into an external enclosure until you are POSITIVE the TVS diodes are OK, as most external power supplies have NO protection against short circuits and will simply burn. Do not underestimate the amount of power (Amps) the drive may drain at spin-up, expecially if it has a "sticky" bearing. In other words, it is possible that your current PSU does not provide enough power, and first suggesdted course of action is to try the drive in another PC (surely working) and with only that drive connected to the PSU (in the sense of no other disk drives connected). jaclaz

@nilkanth It seems to me like your post is completely void of any relevance to the actual topic. As soon as you will acknowledge this post, I will split posts related to your issue to a new topic, where it will be easier to help you without "polluting" the present one, that is intended as an "experimental" one, nothing that you should (for the moment) try at home, as ilko_t pointed out there are several tested and working methods, it is pointless to use a harder way to get the job done, unless it is for "fun" or for the sake of experimenting. jaclaz

Check, double check, triple check, contacts, cleaning them thoroguhfully. See here: Try tightening a little bit more screws around contacts after having removed the cardboard. jaclaz

Something like: @ECHO OFF SETLOCAL ENABLEEXTENSIONS SETLOCAL ENABLEDELAYEDEXPANSION SET /A Counter=0 FOR %%A IN ( "c:\windows\prefetch\*.*" "c:\windows\temp\*.*" "%homepath%\Appdata\Local\Temp\*.*" "c:\temp\*.*" "%homepath%\Local Settings\Temporary Internet Files\*.*" "%homepath%\Local Settings\Temp\*.* ) DO ( CALL :do_count %%A CALL :do_del %%A ) GOTO :EOF :do_count FOR /F %%B IN ('dir /b %1') DO ( SET /A Counter+=1 ECHO !Counter! ) GOTO :EOF :do_del ECHO del %1 GOTO :EOF jaclaz

Sure . It takes only a few lines of batch to implement the file version check, and as well only a few lines of code in C or in C# "standalone", if using .Net, it will take a few lines + a considerable amount of ".Net", with all the consequent .Net install and versioning problems on 2K. At it's basics: @ECHO OFF :: V_copy.cmd - small batch sketch :: to copy executables and dll's depending on their version SETLOCAL ENABLEEXTENSIONS SETLOCAL ENABLEDELAYEDEXPANSION SET SOURCE=%~dpnx1 IF "%2"=="" GOTO :ERROR2 SET TARGET=%~dpnx2 SET TARGETDIR=%~dp2 IF "%TARGET:~-1,1%"=="\" SET TARGET=%~dp2%~nx1 IF "%~x1"=="" GOTO :ERROR1 IF NOT EXIST %SOURCE% GOTO :ERROR1 IF NOT EXIST %TARGETDIR%\NUL CALL :ERROR2 FOR /F "tokens=1 delims=[]" %%A IN ('fvertest.exe %source%') DO ( SET V_source=%%A ECHO %source% version is %%A FOR /F "tokens=1 delims=[]" %%B IN ('fvertest.exe %target%') DO ( SET V_target=%%A ECHO %target% version is %%B fvertest.exe -v %%B %target% REM Insert here checks based on Errorlevel and "UNecho/modify" the following ECHO Errolevel is !ERRORLEVEL! ECHO COPY /B %SOURCE% %TARGET% ) ) SET V_ GOTO :EOF :ERROR1 ECHO. ECHO SOURCE %source% is missing GOTO :EOF :ERROR2 ECHO. ECHO TARGET %target% is missing GOTO :EOF Please note how the above is V_copy.cmd and NOT V_xcopy.cmd. jaclaz

I would use fvertest and avoid .Net Here: http://www.westmesatech.com/wast.html @dencorso I am failing to see the practical implications. Do you mean that there are executables around with SAME "hex" version BUT different "text" version and that the latter may be newer than the first AND that it is a reliable way to get the newer file? jaclaz

I just gave you some friendly advice as you are a new member and it was possible that you overlooked that part . Obviously you are perfectly free to follow your own understanding of the mentioned bit. As well, have you read the part on the top of this thread that reads?: jaclaz

Have you checked ATTENTIVELY the Rules, particularly #1.a ? http://www.msfn.org/board/index.php?app=forums&module=extras&section=boardrules jaclaz

Did some tests, and the matter is a bit complex, but now I can say it can be done, though not with "ini related" tools, since the .inf seem like having a "queer" set of rules. Don't expect anything too soon, but I have great expectations from a new approach I just took ... jaclaz

Check also here: http://www.msfn.org/board/index.php?app=forums&module=extras&section=boardrules point #11 . jaclaz

Be aware of going too far down the memory lane.... http://www.911cd.net/forums//index.php?showtopic=21702&st=122 it shows your age... ...Why, in MY day.... http://reboot.pro/1908/ jaclaz

You are right these particular .inf files need some "special treatment". There are lots of "beautifying" uneeded spaces that create havoc! Additionally you simply cannt write properly with FEDIT something that is ALREADY between double quotes (like "$Windows NT$"). I'll do some tests with batch and a bunch of utilities and let you know. jaclaz

From the article : jaclaz

Have you actually tried FEDIT? Can you post a single example of a "base" update.inf + a couple examples of the files to be merged? jaclaz

No WAREZ support of ANY kind on this board. System Sweeper, see this: http://reboot.pro/14487/ Reatogo, you will need to use a RAMDISK approach, like with ANY other PE 1.x. Most probably you can work your way starting from here: http://www.911cd.net/forums//index.php?showtopic=24100 More generally you will need some time on the 911CD board and on the boot-land reboot.pro board, expecially in the grub4dos section: http://reboot.pro/forum/66/ As long as the sum of the times you format the thingy summed to the number of writes the OS does in use does not exceed the expected Write cycles of the SD card, that is at least 100,000. I would'n be worried by the formatting. jaclaz

What you are reporting is perfectly normal, and has NOTHING to do with SATA or SATA 2. Basically it seems like you installed the OS when a IDE hard disk was connected AND "first disk". Thus the OS install routine wrote to that disk the boot files. All you have to do is: copy BOOTMGR from the IDE disk to the SATA 2 disk copy the \boot\ folder from IDE disk to the SATA 2 disk verify that partition on SATA 2 disk is: primary active [*]verify that the bootsector on the primary, active partition on SATA 2 disk is actually the Windsows 7 one (by running bootsect.exe /NT60) See this thread: http://www.911cd.net/forums//index.php?showtopic=24353&st=0 jaclaz

Hello fredroo, welcome to MSFN. You obviously completely missed to read the Rules of the Board : http://www.msfn.org/board/index.php?app=forums&module=extras&section=boardrules It would be nice if you could read them now. If you could also write in the ENGLISH language (which does not mean put together at random English words) it would be appreciated. Really, I can understand maybe 1/3 of what you wrote. jaclaz

Well, you can sue Microsoft or your school for this. jaclaz

What happens if you boot SETUP twice? Once to just Partition/Format and start install? Then "break it" at some stage? Once for actually installing? Could first round allow copying a BOOT.INI that becomes "base" for additions? Or somehow add a "fake" (or real) IO.SYS/MSDOS.SYS/COMMAND.COM? Would in this case setup create a "stable" BOOT.INI with the provision for the DOS (like c:\bootsect.dos or the like)? Can this be somehow used to our "advantage"? What does F2 do? http://support.microsoft.com/kb/295116 Do we know in which order the "text/inf" files in setup are processed? I mean is there anything that allows the copy of the file or a rename of it just before the reboot? Mind you just semi-random ideas , let's call it free-no-limit-brain-storming.... jaclaz

Well, I guess an "average user" wouldn't go very far from there, actually they say substantially to go to (if you haven't already got a suitable software) : http://www.windowsmarketplace.com/ where obviously you CANNOT find a suitable tool, actually NO tool whatever. @slennon1972 Translated from Microsoftish the sentence: means more or less: Some links: Burner: http://www.imgburn.com/ Virtual CD drivers: http://www.ltr-data.se/opencode.html/ http://www.slysoft.com/en/virtual-clonedrive.html Most probably you can also simply open the stoopid IMG ISO in 7-zip, extracts contents to a folder on hard disk and install from there. But anyway, your question should have been "I cannot find any tool to "expand" the ".img" file I downloaded from here: http://www.microsoft.com/download/en/details.aspx?id=20599 What program application should I use/do you advise to do this? jaclaz

I think the partition can (and should) be the same one. What Windows Setup normally does is: boot from CD copy a bunch of files to the \$WIN_NT$.~BT and \$WIN_NT$.~LS folders reboot use the files in \$WIN_NT$.~BT and \$WIN_NT$.~LS folders to install (normally to \Windows\) (two phases, text mode and GUI mode) delete the \$WIN_NT$.~BT and \$WIN_NT$.~LS folders reboot boot the installed XP The general issue solved by the various little apps developed is (mainly) the avoidance of deleting the \$WIN_NT$.~BT and \$WIN_NT$.~LS folders. If you prefer the idea was/is to replicate the behaviour of the MS CD, i.e. "prepare once, install many" as opposed to "prepare once, install once", which in your particular case may be acceptable. So, I am wondering if we can use INSTEAD a WINNT32.EXE approach (which will create the \$WIN_NT$.~BT and \$WIN_NT$.~LS folders allright from a running XP on the "same source/target disk" AND "same source/target partition") The idea is to run the WINNT32.EXE on the Toshiba then: DO NOT allow rebooting on the Toshiba boot on the Acer break at reboot connect to the Toshiba do the USBbootwatcher trick connect to the Acer let it boot and continue installing on the Acer I.e. something more in the line of: I would also copy to the "target" USB disk the whole \I386\ directory of the "Source", say in a "\Source\I386\, so if later the setup needs anything that is not already in \$WIN_NT$.~LS folder, it can be got from \I386\ Please take into account that some (please read as several ) attempts need to be made in order to hopefully have the whole thingy working. jaclaz

So the moral is that the MacOSx partitioning/formatting software NEEDS "orthodox" partitioning, with partitions properly aligned to cylinder and head boundaries or simply that it doesn't work as it should? Anyway, the only meaningful thing is that we have yet another happy bunny in the basket jaclaz

Hmmm. When you boot from a USB connected disk, normally the BIOS "detects" it (and NO OTHER USB attached Mass Storage devices) and then the SETUPLDR.BIN finds the driver (if it is slipsteamed as you need) and booting goes on. In theory (but this may greatly change with different BIOSes) when you have TWO devices connected at boot, the BIOS should "map" only the one you boot from, but maybe it gets somehow "confused". In other words, the result should be that you can boot from the "source" USB disk, but cannot see the "target" USB disk (until the actual USB drivers are loaded), not a 0x0000007b. The behaviour you describe sounds even more like a "timing" or "conflict of some kind" problem. At this point I would propose you (again ) a different game. What about using the SAME USB disk as BOTH "Source" and "Target"? Start the install on the Toshiba (or any other computer). Stop at first reboot. Add the USBbootwatcher AND the CDDB mod: http://www.911cd.net/forums//index.php?showtopic=22473&hl= Try booting on the Acer. (maybe if the source has the right drivers already slipstreamed, it may work ) jaclaz