jaclaz

Yep . The MBR (shifted to offset 63 sectors) has these data: #0 0C 80 0 1 1 1023 254 63 63 31278492 The PBR which is at offset 63 from the MBR, i.e. offset 126 of the physicaldrive and has these data: 3 0003 OEM String: MSWIN4.1 11 000B Bytes per sector: 0200 512 13 000D Sectors per cluster: 10 16 14 000E Reserved sectors: 0020 32 16 0010 Number of FAT(s): 02 2 17 0011 Max ROOT entries: 0000 0 19 0013 Small type sectors: 0000 0 21 0015 Media type: F8 248 22 0016 Secs per FAT (small): 0000 0 24 0018 Sectors per Head: 003F 63 26 001A Number of Heads: 00FF 255 28 001C Sectors Before: 0000003F 63 32 0020 Large Sectors: 01DD459C 31278492 Since IMDISK mounts the volume you need to double the offset offset=(63+63)*512= 64512 whilst the length is correct: length= 31278492*512=16014587904 jaclaz

It is not at all harmonized worldwide, in most places it is 70 years, but it will be fun in some 27 years time (when the software will be 50) what will happen, as countries such as New Zealand and South Africa have this shorter term: https://en.wikipedia.org/wiki/List_of_countries'_copyright_lengths Bahrain will be earlier (40 years porotection for computer software). jaclaz

I don't think they are admitting anything, they simply found a way to take the money the enterprises owed them for the Windows 10 licenses in another form , I would call it "simple pragmatism". jaclaz

Another way would be to put the target price at (say) 50 US$ (please not the stupid 49.99) BUT play head/tails with a coin on each purchase. On average you will get 25 bucks ... This way there is the added vaue of the entertainment provided by the gambling ... jaclaz

Well, you will need to provide a range for "reasonable", my previous suggestion would have led to a random price between 1 and 100, what is your reasonable range? (so that we can remove some numbered balls from the sack ) jaclaz

Well, technically, we don't have any actual evidence that it was the original counter (not buffer) issue. Not that it helps you in any way, but the actual reason may well be any among the zillion ones that can brick a drive (and that by pure coincidence the known procedure can partially solve). About attempting to change the PCB, simply DON'T: On a modern hard disk replacing the PCB implies replicating the so-called "adaptive data", this is (poor man's method) achieved by transplanting (desoldering/resoldering) the "ROM" (actually EPROM) from the old PCB to the new one, or by professionals by using specialized hardware to save its contents and then restore them to the "new" PCB. To complicate the matter some hard disks use to store "internal" (and "vital") data part on the ROM and part on the platters (cannot say specifically if it is the Seagate 7200.11 case). There are tools (either software or hardware+software) to (hopefully) repair failed drives (assuming that the failure is not mechanical - i.e. heads/platters/motor) but they are in a range of price (between 400 and 10,000/12,000) that exclude the use for a DIY job (and besides they are usually terribly documented or so complex that you won't be able to use them without taking some courses and some experience). jaclaz

What about drawing a ball from a BINGO sack? jaclaz

Well, you first check the heatsink (visually, by prodding it, etc., even better dismounting it, making sure that thermal paste/grease is fine), if it is properly seated, good (and of course, as Yellow Horror suggested the CPU fan shoulf be spinning). A common issue (when a computer shuts off quickly) is that the processor is overheating, like when there is no heatsink properly connected, there is a thermal protection on it that will switch off the computer. Then, if that is OK, you do the routine of stripping each and every unneeded piece of peripherals, leaving only the video and jetboard connected and see what happens. Typically it is likely than an "external" (in the sense of anything not physically soldered to the motherboard) device or that cable/connection to it is either defective or mis-connected (or badlt seated), so removing everything often makes the thing "stay on". jaclaz

Two separate answers. You may want to try (on the recovered 49 GB chunk) the DMDE tool, since (normally) the $MFT starts on LCN 786432, i.e. sector 6291456 of the volume, or roughly 3 GB from the start, it is within the recovered chunk, so there should be no issues with recovering path/filenames: https://dmde.com/ For the rest of the disk you may want to try a disk tool that can read/image the disk "backwards", in some cases it can help recovering data that "forward" reading does not. Unfortunately, though, I suspect that the rest of the disk is actually "bricked" in such a way that recovery - even if maybe partially possible - is outside and beyond the possibilities of DIY, only a professional (maybe) can afford the needed tools and has (maybe) the knowledge to recover that data. You may want to try asking for support/help/ideas here: http://www.hddoracle.com/index.php jaclaz

Good. It is possible that *something* in Windows 10 prevents that from working, but you should have a look at the first sector of the X: drive, maybe - for whatever reasons - the way the offset is "seen" under windows is different, I was expecting more (in case of issues) something like an "access denied" kind of error. Or maybe viceversa the losetup is using a different offset, not relative to the sector 0 of the physical device (i.e. since you already started with an offset of 32256 bytes its scan, the actual bootsector is on 63+63=126 sectors inside the image), though from what you posted it doesn't seem so, you can still try the "direct" mount with offset I suggested early that should be the direct equivalent to IMDISK usage. Unfortunately - due to the nature of IMDISK being a volume (and not a disk) virtual driver - it hooks not to many of the usual windows subsystems, so mountvol, diskpart and disk manager cannot be used to see what is happening and you need a hex view of the first sector to check it is actually the bootsector/PBR. Alternatively, dd the first 128 sectors of the physicaldrive (or of sdb in Linux) to a file, compress it to a zip and attach it to your next post, and I will have a look at it. jaclaz

Well, more or less, the volume(s) on those cards must be on (contiguous) extent(s). Nothing - in theory - would prevent you to use IMDISK to map a contiguous extent to a volume, allowing you to access it. See: http://reboot.pro/topic/20450-mounting-split-image/?p=192170 Whether this will be allowed in (stupid) Windows 10 is to be tested. On Linux, mount using the offset and (if needed) sizelimit *like*: https://raspberrypi.stackexchange.com/questions/13137/how-can-i-mount-a-raspberry-pi-linux-distro-image/13138#13138 should do nicely, The only needed thing is to find the beginning offset and length/size of the volume(s), but this shouldn't be difficult if you can view the actual sector on the machine where the Ontack software is installed. jaclaz

Not really, you were explictly referring to Superfetch, which - as Jody just posted (for free[1]) - would be the first thing to disable. jaclaz [1] and with my personal endorsement and cachet (har harder har har)

WHY? I mean , boot to a PE, do the needed/wanted partitioning, then install the Windows WITHOUT using the installer. It's easier and faster. References: Origin: http://reboot.pro/topic/10126-nt-6x-fast-installer-install-win7-directly-to-usb-external-drive/ Current development: https://msfn.org/board/topic/149612-winntsetup-v391/ jaclaz

Hmmm. http://www.jucs.org/jucs_18_2/performance_evaluation_of_recent/jucs_18_02_0218_0263_martinovic.pdf jaclaz

Right here: jaclaz

Which doesn't negate that you are getting older and forgetful : jaclaz

The disk seems fine (in the sense that the data copied by dd makes sense, it is not 00's or F6's). The partition table is "normal": #0 07 00 0 32 33 1023 254 63 2048 976766976 the MBR boot code is GRUB (possibly GRUB2) and extends up to sector LBA 104 (which is unusual, as normally that would be contained within sector 62 to allow partitioning with CHS alignment), anyway the disk is MB aligned (i.e. PBR is on sector LBA 2048), so it's fine. The PBR is a "normal" NTFS one invoking BOOTMGR, to be picky it is the version "NT62" i.e. the one coming with Windows 8/8.1, and it is just fine. The address of the $MFT is in the "usual" position on cluster 786432, which is also "fine" and "normal". Most probably there is some corruption in the NTFS filesystem itself, it is not common (but it can happen), the "resetting" procedure may alter the P-list (or the G-list, or both) and if one or more remapped sectors is "lost" AND it is a "vital" one the result is an unreadable volume. Standard/suggested procedure: 1) procure yourself a 750 GB (or larger) hard disk (if you have or can afford a 1.5 or 2 TB one, better) 2) dd the whole failed disk to an image file (if possible make a second copy of the image) 3) try accessing the image with DMDE: https://dmde.com/ (though not exactly for the newbie/faint of heart) in case of (relatively) simple issues it can be used also by a non-expert of NTFS, it is read-only by default so it is safe. Usually (not always but usually) DMDE is able to allow the recovery of files (without "fixing" the underlying NTFS) keeping the folder structures and names, so assuming that the disk was not full up to the brim and you can use a 1.5 or 2 TB disk, you should have enough space on it to salvage the relevant files. Then, once these are "safe", we may talk of analyzing and hopefully fix the NTFS. To do this - should you need assistance - start a new thread as that would be off topic here (and the thread is long enough already. jaclaz

The delay in "user partition format successful" shouldn't be connected, It depends on cases. sometimes it is almost instant, sometimes it takes seconds, sometimes it takes minutes. From the UBUNTU (that has somehow access to it) try dd_ing the first few sectors of the WHOLE disk (in your case (/dev/sdb) to a new file. If the disk was originally partitioned in Windows XP or earlier, 100 sectors will be enough, if it was partitioned under Vista or later, you need 2100. Now, if the dd command fails, then there is an issue with the disk, if it does produce a file let's see what's in it with a hex editor. jaclaz

Maybe was. after this reply : jaclaz

Ok, this is actually Windows 10 related: https://www.bleepingcomputer.com/news/microsoft/windows-10-kb4100347-intel-cpu-update-causing-boot-issues-and-pushed-to-amd-users/ jaclaz

Actually older and grumpier (besides cheap and extremely picky), in a few years you may be able to reach the same levels, however. jaclaz

a. You save the firmware settings. b. You reboot to the install media. c. You try again installing the (stupid) Windows 8.1. Four possible outcomes: 1) you got the right setting and the install/setup won't ask you for a GPT disk/partition anymore 2) you got the wrong setting and install/setup will behave exactly as it did originally (in this case other possible settings in BIOS/UEFI may be needed) 3) no matter if the changed setting did anything, your PC will be struck by lightning or however catch fire instantly 4) *something else*[1] jaclaz [1] the *something else* includes a catastrophic overwriting of the hard disk, no matter if due to your mishandling of the procedure or to a malfuncioning of the proocedurte itself, hence the initial:

Yep , or as we say, homophones . jaclaz

Sure , nothing should popup, by design, you only changed a setting, no taaa-daa, nor music band or fireworks to celebrate the accomplishment . It is when you try again and launch the install/setup that it shouldn't (anymore) nag you with GPT, I don't tink there is any difference between a DVD and a pendrive source. The idea is that the setup somehow checks for the presence of UEFI boot mode and if it finds it, the UEFI install prevails over the Legacy one, without giving you an option to change the mode, this would be typical MS. jaclaz

Try setting that to Legacy Only. jaclaz