jaclaz

The (necessarily due to the translation) "vague" syntax provided seems to imply that a "LOGO" ON command must be run before (and possibly also a HOTK one -which is commented out in your PECMD.ini) jaclaz

I would also explore other (non-malware related) hypothesis, a good idea would be to make a full boot with log: http://support.microsoft.com/kb/833721/en-us and if nothing "strange" is logged in Ntbtlog.txt proceed with a full Boot time logging with procmon: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx WARNING this will create a BIG file. Another tool that tends to be forgotten nowadays is Bootvis: http://en.wikipedia.org/wiki/BootVis (the wikipedia page provides links to some other similar tool) available from Softpedia: http://www.softpedia.com/get/Tweak/System-Tweak/BootVis.shtml It could well be a "problematic service" . jaclaz

Post the full pecmd.ini anyyway. Which password is 123456? The (google translation) of the syntax is here: http://translate.google.com/translate?sl=zh-CN&tl=en&prev=_t&hl=en&ie=UTF-8&eotf=1&u=http://blog.csdn.net/kingli_2008/article/details/6765792 As you might know the tool is Chinese and there is a lack of proper documentation in English AFAIK. And the SAME build, but without the password request works perfectly? BUT unfortunately crystall balls are unavailable at the moment , and possibly for this you should ask for help on the AutoIt Forum (in any case if you don't post WHAT you have written, noone will be able to help you). BTW the "official" support board for Win8PE_SE is: http://theoven.org/index.php jaclaz

That's all about how much you value your time. But puntoMX has been IMHO a bit on the low side. That rig is worth all of 130 US$ . You see, the point is not about value of the thingy, but a lot about WHO would be the prospective buyer, let's see: a gamer? No. a business? No. a grandma/grandpa? No. a kid (see gamer above)? No. a hobbyist interested in SOME of the parts? Yes, BUT he/she will want to attribute a value to only those parts, and will offer you at the most 125/130 US$ someone interested in EACH and EVERY of the parts? Yes. (the difficult part is finding him/her). jaclaz

Good Yet another happy bunny in the basket, I presume : jaclaz

Additionally, NOT alternatively, run Combofix: http://www.bleepingcomputer.com/combofix/how-to-use-combofix jaclaz

Good. jaclaz

Good , but not "entirely" flawless (see below): Time to try adding some grub4dos "magic" Add to the ROOT of the drive where your 32 bit system is: grldr menu.lst Edit it's boot.ini adding a line to it : C:\grldr="grub4dos" The menu.lst should be: Copy FROM the root of the partition where you have the 32bit XP the files: NTLDR NTDETECT.COM BOOT.INI TO the partition where you have installed the XP 64 bit. Create on this partition the file "thisis_64_bit_part.txt" (or however the file that you used in menu.lst, the name must be "univocal", i.e. a file with the same name must NOT exist on the WIn32 partition). Try booting, then: choose the "grub4dos" <- this is in the BOOT.INI in the active partition, the one where you have the 32 bit install choose the "Windows XP 64 test" <- this is in the menu.lst choose again "Windows <- this is in the BOOT.INI on the partition where you have the 64 bit install Once (hopefully) booted you should be able to remove L: (the XP x86 partition) as it should be not anymore "boot partition". If everything is OK, try again booting how you are doing now (choosing the X64 system in the first BOOT.INI choice) and see if everything works, report. jaclaz

Sure , but the Registry is "vast" . The related keys are mentioned in the already given thread about migrate.inf (which is an indirect way of editing - actually forming - the Registry at install time): http://www.911cd.net/forums//index.php?showtopic=19663 HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices The matter, JFYI, is expanded in detail here: http://diddy.boot-land.net/firadisk/files/mounteddevices.htm and on the old KB by MS (DO NOT EVEN THINK to change the system drive letter the way it is described here, this is in the case that it was already wrongly renamed to restore it): http://support.microsoft.com/kb/223188/en-us and here: http://www.msfn.org/board/topic/10905-change-drive-letters-to-your-liking/ (again DOES NOT apply to the drive letter the XP is booted from) jaclaz

Remove this: which is of no use anyway. And try again. Or add the line: under the [operating systems] label (BEFORE the [spybotsd] label). jaclaz

I sometimes don't get you. After I spent so much time to try and explain you the matter, what do you come out with? "NoDrives Manager" It is this one I presume: http://nodrvman.sourceforge.net/ that makes NO sense whatsoever, 15 Mb of bloat (smartly UPXed to a mere 5 Mb ) that does a COMPLETELY DIFFERENT THING from what we have talked till now! . JFYI, that tools make a drive not visible in Explorer (this has NOTHING to do with hiding a partition in the MBR or remove drive letter assignment) : http://www.ghacks.net/2007/12/16/hide-drives-in-windows-explorer/ http://www.pctools.com/guides/registry/detail/148/ You can use *anything* that does the SAME thing, not *anything* that does ANOTHER thing! About the MBR, you asked for suitable tools which (obviously) allow BOTH the saving AND the restoring, and then you used another tool to do the backup AND don't know how to restore it if needed? Hdhacker (as well as dsfi) can. Same goes for grub4dos, you can ask instead of going on "random" sites, this one: http://ptspts.blogspot.com.es/2009/07/how-to-create-bootable-cd-running.html points to an obsolete version of grub4dos (which you were already told to avoid) This other site: http://www.rmprepusb.com/tutorials/makegrub4dosiso uses a version of mkisofs and a command line for it that is overly complex and completely UNneeded for the scope at hand, the "simple" way, enough for your scope is detailed in the guide: http://diddy.boot-land.net/grub4dos/files/install_cd.htm jaclaz

But the answer is to a non-asked (or irrelevant) question. Is it advisable to backup the MBR (as is) if it is involved in the Fn thingy? YES. Is it advisable to backup the MBR (as is) if it is NOT involved in the Fn thingy? YES. No matter WHAT they contain is it advisable to backup also hidden sectors? YES. Is there ANY cost or issue in doing the above? NO. Just §@ç#ing make a backup of them - NO MATTER WHAT - and move on to next step. jaclaz

Do you know WHY a SxS folder exists? Do you know WHAT it's contents are and WHY they are there? jaclaz

As said there are several tools available for free. What I personally use is grub4dos BUT it has features far exceeding your needs (and is more complex to setup and uses - when plainly installed - not only the MBR but also a few of the hidden sectors) and it potentially gives to your customers "powers" that they really shouldn't have (unless they know where their towel is), NOT recommended for your specific use. A simpler solution that I also use often is mbldr (fully contained in the MBR): http://sourceforge.net/projects/mbldr/ See here for it's use as a replacement of the Softthinks MBR: the issue as hinted before is with F11 (use F10 instead). Another option is Terabyte thingy MBR Utility: http://www.terabyteunlimited.com/downloads-free-software.htm See here for tips/info: page__st__26 jaclaz

There were TWO points I was trying to make: there may be n different ways the "recovery" or "service" partition is booted there are (at least) THREE different ways to avoid automatic drive lettering #1: Ponch just confirmed what was hinted before and partially documented on mentioned Dan Goodel's pages, DELL (which BTW has historically and gerically a "quirk" for introducing changes in almost *anything* from BIOSes to XP install disks, and generally adopting NON-standard solutions) the "DE" partition can contain everything and the contrary of everything. As well the video does not in any way provide means to know (for sure) the exact mechanism that is used to boot to the "DE" partition, the F2 may cause a jump to a routine fully embedded in the BIOS, chainload a "special" DELL MBR passing to it a "switch" parameter, chainload directly another sector on the hard disk, there are many possibilities. Not knowing exactly the specific way the specific machine uses, backing up everything is logical, since it costs nothing (in terms of money) and very little (in terms of time). #2: The generic problem is the following: How is it possible to avoid that a partition or volume is auto-mounted and/or that drive letters are automatically assigned to it? Normaly an XP will autoassign drive letters along an algorithm that is detailed here: but for what is needed here is VERY simple: First Primary partition on first hard disk drive gets letter C: There are at least THREE different ways to avoid that: (ONLY valid at Setup) use a migrate.inf to force the assignment of another letter to that partition (and force the C: to the other partition) (valid BOTH at setup and during "normal" operation) hide the First Primary partition in the MBR partition table, this way NO letter will be assigned to it. (ONLY valid during "normal" operation) force the unmount of the partition and/or assign to it NO drive letter #1 is the most complex and thus more prone to error #2 is the most simple BUT in the case of a dual boot needs a third party boot manager capable of hiding/unhiding partitions #3 is simple and needs NOT the use of a third party boiotmanager BUT cannot be used at setup (actually during setup this aproach is the same as #1 and needs a migrate.inf) The idea is to use the #2 (simpler) during setup and #3 (simple and needing not third party tools) during "normal operation". One of the possible ways to do #2, i.e. hide the partition (in the MBR) through the use of grub4dos has been given, you can use any other tool to do the same. Once the XP is installed, you unhide the partition (again any suitable tool can be used) and implement #3 by using Disk Management or Diskpart (or a direct Registry editing, whatever suits you). jaclaz

If you are positive that it spins up and you have something like 10 or 11 clicks (sorry I have not an audio card) before it spins down I am afraid it's gone. Google for "11 clicks seagate" (without double quotes) That should mean that the disk cannot read it's own "configuration data" from the platter. It may be something trivial (cleaning accurately the PCB contacts) and sometimes doing "crazy" things (like keeping it vertical or upside down) you can manage to have it recognized (maybe once every several attempts), or it may be a catastrophical (head or bearing) failure. No way to really know. If you try it in a USB enclosure you should see the disk not being recognized properly in the "Safe to remove" popup/window. jaclaz

Yes , this is needed only if you boot form a hd-like device, such as a USB stick or external hard disk. To the numbered points: 1. *any* file, the idea is just to have a file that you can see with the ls command (in order to make sure that you are on the "right partition". I suggested a (can be an empty file or a text file containing something like "Hello peeps! ") named "thisis_64_bit_part.txt" but you can use any. I guess an explanation needs to be made. You are used to see partitions on the disk through Disk Management which shows them as a graphical map of the hard disk, i.e. representing them as a "stripe" with the beginning of the disk on the left and the end on the disk on the right, and with the various partitions represented in the order they occupy on the hard disk. I will try to be more clear, the "first" partition in disk manager is the partition the occupies the first part of the disk (leftmost), "second" is the one to the right of it, etc, etc. BUT a number of other addressing methods for partitions use NOT their position on disk but INSTEAD the position of the corresponding entry in the partition table. The partition table has 4 "slots" or "entries" for writing partition address data (let's for the moment set aside Extended partition and Volumes inside it). These entries are numbered, in grub4dos: #0 is first partition entry #1 is second partition entry #2 is third partition entry #3 is fourth partition entry it is perfectly possible (and happens more often than not, and especially when a "Recovery" partition is involved in the setup) that a partition entry does NOT correspond to the order in which it is placed on disk. Example, your "Recovery partition" may well be written to partition entry #0 BUT being placed at the END of the disk, OR, in one of the changes made in the past on the disk partitioning, entry #1 could be empty. So a sensible thing to do (better be safe than sorry) is to check which partition corresponds to a given partition entry. In grub4dos making a given partition (in the sense of the partition whose address data is written to a given partiion entry) root and then check which files are on it with ls is a quick way to make sure that you are dealing with the "intended" partition. 2. I am not sure to get the "meaning" of the question, right now, from what you report you have three partitions: the Recovery partition (which is already hidden, otherwise your first - 32 bit - XP install would have NOT gotten the C: drive letter) the partition (non hidden) where you have already the XP 32 bit installed (that you need to hide when installing the XP 64 bit) the partition (non hidden) where you are going to install the XP 64 bit (that needs to remain non hidden in order to install to it) 3. Yes and no. NO, as a matter of fact we are going to use grub4dos simply as a MBR partitiion table editing tool, you can do the same booting from a DOS floppy with (say) MBRwizard, or from a PE and using MBRFIX or *any* disk editor. grub4dos is simply more handy as it is easily bootable (from CD/DVD in your case), has NTFS read access, has direct (and IMHO simple/linear syntax) MBR partition table access. YES, the idea is to NOT touch the MBR (i.e. NOT writing the grldr.mbr to the MBR AND following few sectors) because this may cause the impossibility to boot again the Recovery partition. The "enhancement" (let's call it "difference" ) with the solution proposed by submix8c is that in his solution grub4dos (still NOT installed, but called/invoked through the renaming of the files approach) the grub4dos becomes a "permanent" part of the booting sequence, whilst in the one I proposed grub4dos is just a tool to manage the MBR partition entries at install time. If something is not really-really needed I find it better to NOT make it a key step of booting "forever", though nothing prevents from (as an eaxample) haveing grub4dos as a "third option" in the BOOT.INI. I am FIERCELY against the concept of the RENAMING of the files (still better be safe than sorry) before or later it could happen that because of you, or a stupid windows update or anyway *somehow* the NTLDR file (which is a grldr under false name) is overwritten (or that some stupid software checks that NTLDR is actually the real NTLDR or whatever) creates an unbootable system or some other "damage" (additionally the renaming of the grldr may cause issues in more recent grub4dos builds) The original idea of renaming was by spacesurfer: http://www.911cd.net/forums//index.php?showtopic=18031 but later it was (hopefully) "bettered" by this: i.e. by changing the filename invoked by the bootsector, so that files kept their original names. 4. There is NO provision in Disk Management to hide/unhide partitions AFAIK. Why do you think there are so many "third party" tools to manage the MBR? You will find tens of (wrong ) references about Diskpart being capable of hiding partitions, while most the connected commands are about assigning or removing the assignment of a drive letter to a volume, example: http://forum.thewindowsclub.com/windows-tips-tutorials-articles/31678-how-hide-show-your-hard-drive-partitions-using-diskpart.html There is however a way is to set a given ID to a partition, this is a RIGHT example: http://defaultreasoning.com/2009/05/29/unhide-the-recovery-partition-on-a-basic-disk-with-diskpart/ Basically (at least for MS "recognized" parition ID's) any partition ID that begins with 1 means that it is a hidden partition of the type ID-10, like: 16 is a hidden partition ID 06 17 is a hidden partition ID 07 etc. About backing up the MBR, we are before a doubt. To backup ONLY the MBR the easiest would be a GUI tool, such as HDhacker: http://dimio.altervista.org/eng/ the MBR is the first sector of the \\.\PhysicalDriven (n is the same as DISK #-1 in disk management or diskpart, i.e. first disk is \\.\Physicaldrive0, second disk is \\.\PhysicalDrive1, etc) BUT in your case we don't know whether the "Recovery partition booting mechanism" relies on: the MBR only the MBR and *some* hidden sectors the MBR and all (normally 62) hidden sectors, i.e. first 63 sectors none of the above and the code is in the BIOS To be on the safe side I would backup: only the MBR the whole first head (63 sectors) the whole set of hidden sectors (if not 63) using a command line tool like dsfo (part ot the dsfok toolkit): http://members.ozemail.com.au/~nulifetv/freezip/freeware/ the corresponding commands would be (choose the "right" n, for the first two : dsfo \\.\PhysicalDriven 0 512 C:\mymbr.bin dsfo \\.\PhysicalDriven 0 32256 C:\myhid.bin for the third one you need to check how many hidden sectors you have (normally in a disk partitioned under XP is 63, but if it has been partitioned in Vista or later this number maybe different, normally 2048) To check them quickly you can use the partition editor here (dtidata partition repair tool): http://www.dtidata.com/ntfs_partition_repair.htm http://www.dtidata.com/free_data_recovery_software/dtidata_partition_repair_tool.exe 99.99% you will have a partition with "Rel Sectors" (i.e. "hidden sectors" or "sectors before" or LBA offset of partition) of 63, in the 0.01% in which this does not happen, you will need to multiply it by 512, example for 2048 sectors 2048*512=1048576 and thus: dsfo \\.\PhysicalDriven 0 1048576 C:\myhidall.bin Take your time digesting the info, maybe I pushed too much in a single post.... jaclaz

Look, I don't want to seem grumpier than I normally am , but the idea is that you come here for help because you cannot solve an issue by your own. You are here asking for advice. The advice is: there is NOTHING you can do on that disk, if not, maybe, salvage the data on it, whilst updating it's firmware will VERY LIKELY brick it for good, DO NOT, for ANY reason, attempt updating the firmware. Besides it is written all over the place that: NO hard disk is "safe" ALWAYS make backups (possibly more than one) DO NOT EVER "trust" a hard disk and NEVER, EVER one "revived" after unbricking with this method NEVER update firmware on any disk that does not pass BOTH the short and long Seagate tools test You cannot seriously come here saying that: you don't have a recent backup of the data you don't have a recent backup of the data of a disk that you have unbricked with this method you think that upgrading the firmware will solve the issue If you REALLY think that upgrading the firmware will solve the issue, then go on, do it , BUT don't come back whining that the disk bricked itself/became completely inaccessible. jaclaz

Your disk is most probably gone (for good), unfortunately. This thread (and also the very limited knowledge we have) is ONLY about BSY or LBA0 issues, and NOT about ANY other issue. Use the Seagate tools on the disk to diagnose it, BOTH the short and long test, if it doesn't pass either, your disk is "gone". I hope that - since you already had this issue happen - that you have a backup of the Data, otherwise, procure yourself another disk and try imaging the failing disk as soon as possible BEFORE running the tests, if you are lucky you will be able to do that before the disk dies. jaclaz

To translate Charlotte's post in plain English: Hoko, you SUCK at taking photos! AND Charlotte's eyesight is not as good as it once was! The Jumper J1 is (on the manual AND in the photo) EXACTLY where it should be. (Yes, it's the right one for AGP video). jaclaz

@Ponch Here we have a "third" factor which is the Recovery partition. Until the exact nature (and booting/accessing mechanism) of it is ascertained, changing the MBR CODE is NOT a suitable solution , hence the suggestion to use a selection mechanism outside and beyond the MBR. Risks connected to overwriting the MBR code (in the case it uses a proprietary solution like the mentioned "Softthinks") are detailed here: JFYI, among the "self contained in the MBR only" bootmanagers, the current state of the art is (and it is since years) MBLDR: @androemda43 Only to counterbalance your report, I have run for several years a multiboot PC with: DOS (6.22) Windows 98 SE Windows 2000 (actually TWO installs of it) Windows XP without a single itch/issue/problem whatever (and each OS - within it's filesystem/addressing limits - could "see" the other installs). Certainly the multi-boot setup was accurately planned, and it is very possible that Windows 7 may have issues with XP, but I do have a couple system where there is Windows 7 installed as "main" system AND there is an XP "service" partition (and each can see the other) where I have had not (yet) any issue whatsoever, time will tell. I have run for years double boot XP+XP and never had a single issue, so unless you know for sure that there is some issues for XP32+XP64, your recommendation of preventing them to "see the other" seems overcautious (and in any case Dogway is going to have them NOT "see the other"). jaclaz

Actually also DURING and AFTER it, until Me. The NT family was/is another thing..... jaclaz

What happened is hard to say, but from what you write it is possible that the disk has NOT been damaged (much) All modern hard disks have a kind of "fuse" (actually two of them, one on the 5V and one on the 12V ). They are not actually "fuses" as we normally know them, if they are triggered they short to ground. Technically they are called TVS diodes, see: http://en.wikipedia.org/wiki/Transient-voltage-suppression_diode If the TVS(s) worked as they should have been: when the disk is powered by a "proper" power supply (with short protection) the effect is that the PC won' t start at all or very quickly shut down. when the disk is powered through an (usually el-cheapo) external power supply such as those you find in external cases and "SATA/IDE adaptor", which have not such protection the effect is that the power supply fries . So, maybe, you are lucky and you just fried the sata/ide adapter power supply because the disk protection actually worked and the TVS (either or both of them) shorted the power to ground. If this is the case, besides getting a new power supply for the adapter (or buy a new complete set, most probably cheaper) all you need to do is to verify that the TVS are shorted (any common multimeter will do) and remove them (by desoldering them or CAREFULLY prying them out of the disk PCB). Please consider that without the TVS's in place the PCB has NO protection against overvoltage/overcurrent, so the idea is first get another new hard disk and use the old one in this unprotected setting ONLY for the sheer time needed to image it over the new one. Later, and depending on how cheap you are, you may think to get a couple of TVS diodes from another disk you can find as scrap and re-solder them. It is fairly easy to "spot" the TVS(s) on a PCB, example: If you need help in finding them, post a picture of the PCB. jaclaz

The cause for the issue is to be detemined, but the actual effects can maybe be mitigated. Right now the issues (effects) are that: you cannot boot win "normal" mode (because the system crashes) you can boot to safe mode BUT the shell doesn't load (fully), i.e. you get the desktop and Explorer is running BUT you have no Start button/tray Your next attempt could be that of attempting to load an alternate shell (winfile) to see if you can boot in safe mode (and from it do what rloew suggested). Try following this: http://www.mombu.com/microsoft/windows-98-general/t-windows-starts-but-no-start-button-desktop-image-only-229791.html jaclaz

What I care to stress about is that NO such thing as an EISA partition exists (if not in the perverted mind of the good MS guys) since something like 25 years (and actually never existed as a "standard"). EISA is (was) an update/extension to the ISA bus: http://en.wikipedia.org/wiki/Extended_Industry_Standard_Architecture On some machines equipped with that bus, a "hidden" partition containing the configuration utilities was created. This partition had a partition ID of 12 which has NEVER been tagged (if not by the good MS guys) as EISA, as a matter of fact everyone know (knew) it as the Compaq Diagnostics partition: http://web.archive.org/web/20030411231940/www.powerquest.com/support/primus/id233.cfm http://www.ctyme.com/intr/rb-2270.htm (Compaq was one of the "Gang of nine") because it was the firm that at the time made the first machines and particularly the first "commonly used" machines based on this bus. The bus soon faded into oblivion, and was replaced by faster buses, such as VESA and later PCI. But there was a precedent of a "hidden" partiion with id 12 that has been later used extensively by Compaq itself and later by other manufacturers (including Intel and IBM to name a couple) for Recovery or Diagnostics use, see: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html Microsoft NT based systems - trying possibly to be smart - tag in Disk Management the ID 12 partition as EISA instead of "unknown". A partition ID that means "nothing" in the sense that it DOES NOT IDentify a particular filesystem as it can contain everything and the contrary of everything should not be tagged with something that actually does not exist (and possibly NEVER existed), IMNSHO. Dell's Recovery partitions normally have a partition ID of DE, see: http://www.goodells.net/dellrestore/ http://www.goodells.net/dellutility/ if XP tags a DE partition as "EISA" it is twice wrong (and no, that doesn't make it a right ). jaclaz