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

Do you have a comparison with some other system (like - say - Windows 7 or newer) on the same network and on the same NAS? Only to exclude that is *something else* outside the XP install. Do you have IPV6 installed in the XP? (there are reports of this creating slow transfers on local network) Then you can see if any TCP optimization helps: https://web.archive.org/web/20070228142414/https://www.psc.edu/networking/projects/tcptune/OStune/winxp/winxp_stepbystep.html And you can try to reduce SMB traffic generated by Explorer: https://blogs.technet.microsoft.com/askperf/2007/09/21/windows-explorer-and-smb-traffic/ jaclaz

Life is good because it is so varied I see those as features and advantages of Windows 7 when compared to 10. jaclaz

Abanoners? jaclaz

Get the manual for your motherboard: https://www.gigabyte.com/Motherboard/GA-H81M-WW-rev-10#support-manual Check ATTENTIVELY what is written on page 24 of the manual: Report how EXACTLY you have set the settings listed in it (except the Administrator and User password settings). jaclaz

Well, for the record, I don't think that the OP was attempting a (direct or indirect) upgrade, but rather replacing one of his two instances of XP with a fresh install of 8.1. jaclaz

Not strictly Windows 10 related, but close enough to be worth mentioning here, a good analysis/rant on OneDrive, aptly titled "OneDrive Down the Road to Madness": http://www.eejournal.com/article/onedrive-down-the-road-to-madness/ jaclaz