jaclaz

It is possible (but cannot really say ) that Vista and (maybe also) Vista64 still relies on the migrate.inf file. It's a loooong shot, though. Do check this seemingly unrelated post: http://www.msfn.org/board/Installation-end...ve-t112923.html and links therein However, since you are going to reinstall VISTA anyway, I would try using a PE of some kind or even good ol' DOS and change the entries in the partition tables, in the MBR and in the EPBR to make the partitions "hidden" (simply changing first hex number of partition type from "0" to "1"): http://www.win.tue.nl/~aeb/partitions/partition_types-1.html Another possibility is that rather than in the order the partition is phisycally on the hard drive, Vista setup looks at the order in which partitions are listed in the MBR and EPBR, in this case exchanging the orfer of the entries may get the desiref result. jaclaz

Reinstalling properly would be easier. It is possible to change a Boot or System Volume letter, but really, really tricky and really NOT advised. However: http://www.goodells.net/multiboot/index.htm http://www.goodells.net/multiboot/partsigs.htm Read also these: http://www.911cd.net/forums//index.php?sho...c=19663&hl= http://www.msfn.org/board/Change-Boot-Driv...ion-t90495.html And be very careful, even a minor error could (and probably will ) lead to an unbootable system.

Well, no. Electronics components have a working temperature range, usually comprised between -30° C and +65° C, for "normal" grade components, usually -40° C and + 85° C for "industrial grade components" with some components that allow for a -65° C to +125° C : http://www.extremetemperatureelectronics.com/tutorial1.html WITHIN the given temperature range, there is an "ideal" working temperature, that almost invariably is around the middle of the allowed range, more or less amounting to a temperature at which the users of them (humans) live and operate them, i.e. +0 °C to 40 ° ,but WITHIN designed range, components behave anyway WITHIN specs. The "freezing" as well as the "tapping" method to revive a dead hard drive, can, in VERY RARE occasions allow for a TEMPORARY revival because they may resolve a mechanical problem, including defects in the soldering or connection of a component. Remember also that every year hard disk technology changes dramatically, and what may have worked in a particular occasion, on a particular type of failure, on a particular drive model/capacity most definitely won't work with next generation of drives. You can also try shouting very hard at it, using a magic wand and some spells on it, you can freeze it: http://geeksaresexy.blogspot.com/2006/01/f...cover-data.html as well as "boiling" it: http://www.mandible.net/2007/11/24/how-i-r...ble-boiling-it/ But ALL of them should be a LAST, LAST resort, only after you have decided that your data was not precious enough for you to attempt a recovery by a professional, and you have nothing to lose anyway. If it's an electronic problem a more "rational" approach like this: http://www.deadharddrive.com/ may work, but not on recent drives where the board is "coupled" to the innards. I would suggest everyone to check the above links and this one: http://www.hardwaresecrets.com/article/245 then judge themselves what would be more wise to do. jaclaz

Hmmm, besides the fact that is very difficult to read what you write (why using Arial Black? ), I guess that you failed to actually read the License of nlite, that last time I checked was this one: (bolding is mine) jaclaz

NO, but in most cases a relative can guess it, no need for "social engineering", the knowledge of habits, passions, hates, birthday dates, names of dear ones, etc., etc. should be common between the members of a same family. You joking, right? The point is NEVER, NEVER, and I mean NEVER allow access to a PC you want to keep private, if you do, do it only under your direct and attentive surveillance, otherwise it may well happen that, in the short turn of five minutes: ALL YOUR PASSWORDS ARE BELONG TO US! jaclaz

Well, it is possible to use the internal hard disk as hdb, though there is a RISK in making the "working", possibly "system", drive accessible from the VM, it would be better to use as hdb an image of the drive, rather obviously all drivers instealled within the VM may or may not be compatible with real hardware... Qemu "internally" should see hda as \\.\PhysicalDrive0 and hdb as \\.\PhysicalDrive1 LOTS of testing is needed before "advertising" this possible way, allowing direct access to system drives is VERY like playing with explosives.... jaclaz

Mind you, completely and utterly UNTESTED but read FAQs here: http://fabrice.bellard.free.fr/qemu/user-doc.html http://kidsquid.com/cgi-bin/moin.cgi/Frequ...yAskedQuestions http://calamari.reverse-dns.net:980/cgi-bi...bb75619b572be-2 jaclaz

I doubt you will find one here. Or are you looking for a suggestion? What about: arachnospellingbuster It may fit.... jaclaz

Well, NO, the detail would be a list of all single settings you used with nlite, all apps you added, all choices you made with WPI and Unattended CD Creator, with those FULL details, someone may be able to understand where the problem lies, though checking such a mass of info would take, of anyone would take the challenge, a lot of work. You must "reduce" the possibilities: Do steps 1. and 2. only, burn the CD and test it. If it works, do later steps 3. 4. 5. , burn the CD and test it. If it works, do later steps 6. 7., burn the CD and test it. This way you will know at least which app creates the problem. At this point check what could be related to keyboard and try removing/adding it or try making just a small number of things and test the result, by the way you could use a Virtual Machine instead of burning test CD's. jaclaz

@all It seems like the other day was "wish" day on boot-land and Nuno Brito has started working on this app, there is already a fully working (but still missing some asked for features) release here, ninf 1.1, enjoy: http://www.boot-land.net/forums/index.php?...ic=3960&hl= @damian666 It seems like there is not anymore need for your work, but thank you very much for your offer to do it , I am sure I can find some other interesting project for you , should you still be willing to write something for the community , again, thanks for your kind offer. jaclaz

Yep, FYI: http://www.boot-land.net/forums/index.php?showtopic=2267 the -iso-level 4 mean in "plain English", "use the 1999 ISO extensions", and since MSCDEX was written before 1999 it cannot work with them. jaclaz

@ilko_t Sorry I tried to "beautify" your post using [ codebox ] - [ / codebox ] tags instead of [ code ] - [ / code ] ones, but the board fails the parsing, please do recheck the data, I may have unwantingly introduced some changes while testing the output. @all Please find here the references, within the LOONG XP on USB thread, about modifying NTDETECT.COM: http://www.911cd.net/forums//index.php?sho...c=19235&hl= (post #3) before you ask for a direct download or something like that, do read this: http://www.911cd.net/forums//index.php?sho...3784&st=334 "level #4" people should NOT "play" with this kind of things, they may well find thenselves with an unbootable system jaclaz

Fred, some time ago I invited bearwindows to the boot-land community, mainly because of his great UNIVERSAL VIDEO DRIVER, he accepted and he has now his own little corner there: http://www.boot-land.net/forums/Universal-...driver-f60.html where he posts also about his other projects. He is a nice guy, and from time to time he visits the Boot-Land Forum. You can contact him through boot-land, should you not want to join there, just let me know if you want me to start a topic or PM him pointing him to this thread..... jaclaz P.S.: He is also member here at MSFN: http://www.msfn.org/board/m142976.html

Generally speaking there are TWO kinds of drive faults (once you are positive it is NOT the cable or motherboard): 1) Hardware ones, that comprise both electronics (the controller board) and mechanics (the innards of the drive, spinning motor, head displacement motor, defective heads) 2) Software ones Data recovery in case of faults of first kind CANNOT usually be performaed by End User, as, apart deep knowledge and experience in the field, specific hardware, spare parts and tools are needed. Data recovery in case of faults of second kind CAN usually be performed by the End User, provided that he has a little more than average knowledge, and that he is willing to spend some time on it. See this thread: http://www.msfn.org/board/Data-recovery-tool-t84345.html for a number of tools you may try to use. MAIN thing in Data Recovery is to make a "dd like" image of the disk on a new, healthy one (ideally you should make TWO copies) and attempt a recovery on the copy ONLY. This way, depending on the value you give to your data, the original, untouched, filesystem in the faulty drive can be given to professionals for another attempt. jaclaz

First things I would check would be: 1) if a RAM expansion card/chip is present take it out / check contacts / re-seat 2) if the processor is upgradeable (on a add-on card) take it out / check contacts / re-seat 3) take the cd/dvd out / check contacts / re-seat 4) (warning in most cases needs a partial disassembly of the laptop) take the HD out / check contacts / re-seat 5) (warning needs a partial disassembly of the laptop) open it up, remove keyboard / check contacts / re-seat thoroughly clean the innards from dust jaclaz

Main thing is that problem is solved! Happy about that. jaclaz

You can use MOUNTVOL command. This can be included in a batch file, if you use also vlm, part of the DSFOK toolkit here: http://freezip.cjb.net/freeware you can easily select the drive from it's label or Symbolic link. just run: MOUNTVOL >C:\Mountvol.txt and VLM >C:\vlm.txt to see which output they produce, then read "between the lines" of this: http://www.uwe-sieber.de/usbstick_e.html and get the good ol' mnt / unmount: http://www.uwe-sieber.de/files/unmnt10.zip If you search on the board, you should find a number of posts about batches using MOUNTVOL to determine drive letters. jaclaz

In other words, this is the output of DIR | FIND "<DIR>" with a "right" numbering: and this is the output of the same command with "your" numbering: jaclaz

Some links/info in this thread: http://www.msfn.org/board/NTFS-support-Win...ME-t110814.html jaclaz

First try TESTDISK: http://www.cgsecurity.org/wiki/TestDisk (i.e. Partition based recovery) and only of it does not work, a file based recovery program, like the enclosed Photorec, or any of the other ones, just search the board there are several threads listing them. jaclaz

The "base" posts are these ones: http://www.911cd.net/forums//index.php?showtopic=19663 http://www.911cd.net/forums//index.php?showtopic=18782 If installing from CD, you should have a migrate.inf with a few different MBR signatures entries and manually set the actual machine HD MBR Disk Signature (i.e. bytes 1B8h through 1BBh ) to one of those: http://thestarman.pcministry.com/asm/mbr/Win2kmbr.htm with an utility such as MBRWIZ: http://mbrwizard.com/ or MBRFIX: http://home.graffiti.net/jaclaz:graffiti.net/index.html (links at bottom of page) or any disk editor. (mind you, completely UNLIKE tested) Another possibility is to, AFTER install, changing the %SystemDrive% letter, which can be done, but it can be tricky. jaclaz

I don't think that the issue can be because of the RAID in itself, are you sure you are loading the appropriate (F6) driver? If yes, there is a probability that the drive ir RAID setup is corrupt. We are talking about a hardware RAID, don't we? I guess your next best bet is making yourself a PE of some kind (with the appropriate drivers). Doesn't the motherboard or add-on board manufacturer provide "low-level" diagnostic tools? RAID 1 should be a "total" mirroring solution, thus the two drives should be identical and each of them should be accessible separately as a "normal" disk, disabling the RAID setting in the BIOS. Make sure however that you firstly inspect the uncoupled drive with a read only system. jaclaz

You will need to fiddle a bit with Registry too, see this: http://www.msfn.org/board/Missing-Language...ion-t66594.html I guess you can take the relevant keys from one of your "working as they should" installs. jaclaz

You could try using (before actually installing) a PE of some kind (or maybe even DOS) and create a migrate.inf file, machine specific. Search both here and on 911CD boards for posts by me and cdob with keyword "migrate.inf" jaclaz

@damian666 Actually, .ini, .inf and .sif files present the same "basic" structure, i.e.: [Section] Item=value with just a few minor changes, for example the linked to .ini viewer seems not to "like" items inside double quotes, but I guess that can be easily fixed, in other words, if it will work for .sif files then it will work also for .ini and .inf ones . About helping you, I am afraid I am the latest person on this board with programming knowledge, exception made for a few small batches.... .... but I know AutoIt has a treeview feature, so it should be possible to write this thingie in AutoIt language. jaclaz