jaclaz

Not a smart move , Veronica is ugly :, her cousin Victoria is much cuter , check her instead . I'll check the pictures and let you know. jaclaz P.S.: NO you have circled in yellow the WRONG traces. Follow me please. You have 4 sets of 5 contacts at the corners of a rectangle at the center of which there is a hole. Something that can be represented as: 00000 00000 O00000 00000 The read channel is (at least on the other motherboards we have seen till now) the first and second rightmost pins of the top left group of 5 contacts (when, like in your pictures the connectors are on the bottom), i.e.: 000XX 00000 O00000 00000 If you check them, they are connected to 12th and 13th pin (from top to bottom) of the largish IC on the left.I thought that the post here: http://www.msfn.org/board/topic/157329-barracuda-lp-no-not-a-720011-nor-a-720012/?p=1003759 was clear enough

I don' think that lifting the head (or the motor) contact may work on an ES2 drive. AFAIK/AFAICR the PCB needs to be detached connected AND the shortcircuit be made. If it is a BSY or a LBA0 kind of error you can determine by what the BIOS of the machine "sees" (or fails to see). If it cannot detect the disk at all, it is likely that it is a BSY error (but - with all due respect I don't care what you have handy - you may want to procure yourself a suitable OS and run a suitable tool to verify this). If the disk is seen by the BIOS byt with 0 size it is a LBA0 kind of error. If you post two CLEAR pictures of the PCB (one of each side of th ePCB) usually it is possible to identify the two pins to be shorted (the READ channel) see also: http://www.msfn.org/board/topic/157329-barracuda-lp-no-not-a-720011-nor-a-720012/ http://www.msfn.org/board/topic/157329-barracuda-lp-no-not-a-720011-nor-a-720012/?p=1003759 jaclaz

Are they? In any case the procedure is the same. jaclaz

Well, what you should attempt doing is to image the DISK (NOT the drive or partition or volume, NOR "files" inside them) "as is", using an appropriate tool. You will need another hard disk, same size or bigger. Under Linux the suitable tool would be ddrescue (actually it is advised to use Linux and ddrescue), as in the thread you mentioned: http://www.msfn.org/board/topic/170881-seagate-720011-malediction/ and see also this: http://www.msfn.org/board/topic/170938-damaged-logical-structure-of-seagate-720011/ The idea is that ddrescue attempts to read "good" data and keeps a log of what it managed to read, so that access to not read parts can be re-attempted later. Once you have an "as good as possible" image on a surely working disk, then we can attempt recovering data. No, not here (this is an international board and the "common" language is English) In any case. now that the disk is not "bricked" anymore, if you need assistance start a NEW thread (as opposed to continuing here on the "megathread"). jaclaz

Re: the cloud AND NSA This is an interesting article (though a bit longish/needing some time to read): http://www.theguardian.com/technology/2014/may/27/-sp-privacy-under-attack-nsa-files-revealed-new-threats-democracy Among the many arguments touched, I would like to highlight this: I like the idea of a mail server device similar to a phone answering machine. jaclaz

What do you mean "not recognized by windows"? I.e. is the DISK device seen in Disk Manager BUT NO DRIVE letter appears in Explorer? The actual original issue may have been: 1) a BSY the disk is NOT seen/detected by the BIOS 2) a LBA0 the disk is seen/detected by the BIOS Is the disk now seen by the BIOS? If yes, it should also be detected in Disk Manager and this means that it is not "bricked" anymore (i.e. the fix was successful ). Still it is possible that further steps are needed to recover the pre-existing partition(s) or, should this fail, only the recoverable data, see: http://www.msfn.org/board/topic/128807-the-solution-for-seagate-720011-hdds/?p=1078040 (for the record , not hidden a zillion pages back in the megathread, it is last post before your original one) jaclaz

Type SLOWLY , AFTER having waited 15 or 20 seconds after having powered the PCB: http://www.msfn.org/board/topic/128807-the-solution-for-seagate-720011-hdds/?p=841755 There isn't a "lower" or "upper" side (it depends on the way you look at it), there are the "motor" contacts (which are near the motor) and the head contacts (which are the other set), the recommended guide: http://www.mapleleafmountain.com/seagatebrick.html suggests to try insulating the "motor" contacts, but it may depend on the actual disk and the situation in which it is "bricked", just like the Tx/Rx (if it doesn't work invert the wires), if one sets of contacts does not work, try again insulating the "other" one. jaclaz

Yes. The articles you reference seem to me well detailed, but seemingly your scope is different. The idea of those is to: create a "reference" machine install to it Windows add apps/settings/whatever generalize the image deploy the image to a number of other PC's finish the configuration on the single machinesImagine that you are in the IT of a company and you get 20 laptops for the company's salesforce, instead of installing (or only configuring) and configuring 20 times, you setup a "reference" PC and then replicate it 20 times. In your case: It would IMHO make more sense (since the source and target are the same) to simply have (once the PC is configured) a "bare-metal recovery" capable image (i.e. it makes little sense to generalize the setup, since the scope is to "restore" and not to "deploy"). See (just to get familiar with the slight differences in the terms used) this thread: http://www.msfn.org/board/topic/157634-hard-disk-cloningimaging-from-inside-windows/ Then DISM is as good as anything else to do this, see: http://www.msfn.org/board/topic/153742-dism-improvements-in-windows-8/ All you have to do is: Setup your PC the way you like it Capture an image of it and store it somewhere In case of need boot to the PE, re-apply the image, if needed after having (say on a new disk or if the old disk partitioning was corrupted) create the partition(s) and run BCDBOOT to recreate the \boot\BCD. See: http://wiki.beyondlogic.org/index.php/Imaging_of_Windows_Based_Computers_using_DISM Please understand how this won't be anyway an "exact" copy of the original, and some programs (as an example those that use volume data or disk signature to verify/authenticate) might need to be re-activated. In your case I would prefer a "real" image of the disk (though .wim technology has some advantages, like a high compression and usually it is pretty fastish), or additionally and besides the .wim image, backup/store the relevant data. jaclaz

NO, if a virtual COM port is created and the loopback test works then the driver is fine. Have you checked ALL the points I listed in my previous posts? Have you double-checked them? Have you also double checked the speed/parity/etc? JFYI, by convention when I terminate a sentence with that little "hook" which is called a "question mark", it means that the sentence is a question, for which I would like to have an answer. There are cases where the PCB needs to be completely detached from the disk (as in the first original attempts/tutorial). jaclaz

AND http://reboot.pro/topic/19828-win8pese-wireless-aerthos/ jaclaz

What is the booting sequence in the BIOS? Set hard disk as first device. jaclaz

Try RunAsSystem: http://www.msfn.org/board/topic/155910-taking-back-the-registry-from-trustedinstaller/ http://reboot.pro/files/file/237-runassystem-and-runfromtoken/ jaclaz

Yep. The idea is (generically) to have a way back and "infinite chances", if chkdsk works on the disk, good, if it doesn't you restore the image to that disk (or to a new one) and try another program/method, if it works good, otherwise you restore the image .... jaclaz

Yes. No. No. Yes. It may be wise, but won't change the current status (botched/unknown) of your curret file system. Yes, I would say it is a symptom, not necessarily when you start sneezing you get a cold and this develops into pneumonia , but taking a couple of aspirins and going to bed won't do any harm . Make an image of the disk, NOW! No. jaclaz

Yeah. Type in it: jaclaz

For the record, in my understanding, this: http://www.landesk.com/migrate/xp-support.html Translates to: i.e. it is an added service, besides the need for paying MS for extended support... jaclaz

If the disk is bricked, it is bricked. If you do not remove (or loosen enough) the PCB and insulate either the motor or head contacts you won't normally have access to the disk interface via TTL. Consider the usual carpenter comparison: To join two planks of wood together you need (at least) three nails (of suitable length) and a hammer. Put the two planks one over the other and drive the nails vertically in both the planks by hitting with the hammer the heads of the nails. Q. I have the hammer but no nails. I tried banging the hammer on the planks really hard, but they don't stick together. A. You need the nails. The procedure REQUIRES that one set (or the other) of contacts are insulated (or the whole PCB is removed). You *need* a suitable Torx screwdriver to losen or remove the screws. If you really-really cannot afford (or procure one) usually these screws can be undone with *any* flat screwdriver of suitable size of which you have filed down a bit the edges, i.e. from: _| || ||_| to / \| |\ / However, quick check list: Is the disk powered?Did you try hitting CTRL+Z?Have you tried inverting Tx and Rx?Are all devices properly grounded?Have you made sure that the USB->TTL adapter provides the right (lower) TTL levels?jaclaz

Actually they are not lying (please read as "not lying more than usual"). It is most probably true that the updates (which doesn't really mean that they won't work, only that they were not intended for it) Also the following statement: is very accurate . These updates are actually intended for Windows Embedded and Windows Server 2003 customers. They do not fully protect Windows XP customers (as well as they do not fully protect Embedded And Windows Server 2003 ones ). Also here: given the amount of issues that previous updates caused (when XP was supported), I have some doubts about those updtes havine EVER being tested (thoroughly) on Windows XP , and of course "significant" without any data is one of those words that can mean anything, you know like these (ALL considered by someone constituting a significant risk to health or safety, before being debunked): http://www.hse.gov.uk/myth/myth-busting/index.htm I like these ones , carrying a parasol at a race: http://www.hse.gov.uk/myth/myth-busting/2013/case204-racecourse-parasol.htm and carrying new shoes without a box: http://www.hse.gov.uk/myth/myth-busting/2014/case248-customers-buying-shoes.htm are reknown as dangerous activities. Nothing to see here, people, move along. jaclaz

There is actually a (wrong ) assumption in the very beginning of this thread. And what is saddening is that it is the SAME assumption that has been forced down our throats by the good MS guys, that a single Operating System can be a one size fits all and all it's user should or must conform to a given behavioural model. NoelC's reported experience is the experience of a particularly knowledgeable software engineer using his computer on the workplace to do professionally whatever professional software engineers are supposed to do. Another user, let's say a kid, with no actual (yet) understanding of the OS, downloading and running (even only to briefly test them) a zillion programs, among which many "rogue" ones, any number of *ahem* diversely obtained and authenticated pieces of software, navigating 2/3 to 4/5 of the Internet, playing every conceivable (and also unconceivable) online or offline game, may have some different experience both on the stability of the OS and on the utility of "registry cleaning" tools. Personally, being (unfortunately) a grown up kid and not (cannot say if unfortunately ) a software engineer, I find that going midway, i.e. using (say) Regseeker and manually reviewing it's output before applying changes/deleting registry keys is a suitable approach. jaclaz

@drugwash Yes, almost, the thingy runs in autoexec.bat WIN.COM /W, see: http://www.msfn.org/board/topic/171878-boot-to-gui-windows-and-not-dos/#entry1078808 http://support.microsoft.com/kb/142544/EN-US so the files should be .wos, but that should only affect autexec.bat and config.sys. jaclaz

I hope you mean that it IS booting (from the PE) WITHOUT clicking noises or slowly. In other words your laptop's hard disk is defective and prevented booting even from a PE, unfortunately something that is rather common (hard disks failing) especially on laptops where the smaller hard disks (thus needing higher "precision") are also subject to shocks and have worse cooling than on desktops.. jaclaz

Naah, that is not at all a gauntlet, it is just a set of statements. This (point 7, specifically) may be interesting to challenge: http://rwmj.wordpress.com/2010/02/18/why-the-windows-registry-sucks-technically/ As well as this one : http://reboot.pro/topic/7681-the-registry-as-a-filesystem/ Though they may make it even harder to choose an approach.... I mean, choose one : IF the Registry is a database, then it makes sense to compact (please read as defragment) it periodically. IF the Registry is BOTH a database AND a filesystem, it makes sense to compact (please read as defragment) it periodically. IF the Registry is NOT a database, BUT ONLY a filesystem, then it makes even more sense to defragment it periodically. jaclaz

I take this back: evidently dencorso's crystall ball needs to be completely overhauled as unlike mine (which needing some fine tuning could not see details as I was expecting) his one provides WRONG details. Yes , seemingly the one in the top left corner is a screw holding the hard disk in place. If you post the actual laptop model, possibly a better photo and disassembling instructions can be found. jaclaz

Hmmm. The Registry is a database. A filesystem is a form of database. The Registry is also (can be seen as) a filesystem. Filesystems are defragmented as an "ordinary" maintenance task (with the exception of the Ext2/3/4 because they are so smart that it is not needed [1]). Databases are compacted (please read as defragmented) as an "ordinary" maintenance task (no exceptions that I know of). If compacting (please read as defagmenting) the Registry is a bad thing, then compacting a database is also a very bad thing to do, as well as defragmenting a filesystem. The good MS guys post deceiving information, then: http://support.microsoft.com/kb/288631/en-us Sent from my common i386 PC using Opera 12.15 and bragging about it. jaclaz [1] At least this has been *true* until the good Linux guys exited, after several years, "denial mode" and some defragmenting tools for the Ext2/3/4 filesystem wre made available.

IF it is a SATA disk drive (dencorso crystal ball is working better than mine , as he was able to see through it the actual PC, and thus know it is a desktop and has a SATA disk drive) The one with "thicker" wires, coloured in black (2 wires), red and yellow is a more general description, commonly IDE/PATA hard disk (3.5") have this: http://en.wikipedia.org/wiki/Molex_connector whilst SATA hard disks (BOTH 2.5" and 3.5") have this: http://en.wikipedia.org/wiki/Serial_ATA#Power_connectors The connector for IDE/PATA hard disks 2.5" is integrated in the data connector, like: http://www.addonics.com/products/adms25ide.php jaclaz