jaclaz

Strange that you have not values 187 and 188, however the 197 and 198 (that more or less reflect the 5-7 bad sectors you reported) do not look good, particularly if coupled with the recent increase of failed RAW reads. The fact that it is a 320 GB drive is a good thing as - likely - it has a relatively low data density and - empirically - they tend to suffer less from "diffusion" of bad sectors (when compared to - say - 1 or 2 TB ones). What I would do if I were you: 1) of course have a verified backup 2) run the WDC testing tool: https://support.wdc.com/downloads.aspx?p=3 (extended test, which is not "data destructive" and may help in re-mapping the currently bad sectors[1]) 3) see if the disk drive "passes" Then, if it passes, and if (see note below) the tool manages to remap those bad sectors you are good to go. If it doesn't, it doesn't mean that you have to throw the disk in the trash , only consider how it surely has lost some (most) of its reliability. Anecdotally, once, many years ago, I had a (Samung) 4.3 GB disk (no, it is not a typo) that developed a "cluster" of bad sectors (some 80-100 of them) all in a definite area. At the time I demoted it to secundary backup media , and partitioned it in such a way that a few MB around the area containing the bad sectors was unused in the partition table, and it never failed (though of course it was much less used than when inside the actual PC). If the bad sectors seem to be all in a same area, you could try doing the same. jaclaz [1] please understand how, even if the disk drive "passes", there is a risk that the test will find an increased number of bad sectors, however, after the test they should be re-mapped and not be seen in chkdsk, at least in theory

Ok, but what error(s) you have? Historically (but not necessarily in your case) issues with WinsetupFromUSB derive from either a modified source or from "queer" BIOSes (and the Insyde BIOS is notorious for making these) it may be necessary to make change to the grub4dos commands on some BIOSes. There is still (just in case) the good ol' manual method 911cd is long tiime MIA, via Wayback Machine: https://web.archive.org/web/20160417164143/http://www.911cd.net/forums//index.php?showtopic=16713 jaclaz

Well, you didn't really-really expect that installing Windows from USB is possible without some (more than one) tricks? We have an entire sub-forum dedicated to the matter and to the various possible approaches/related programs, etc. https://msfn.org/board/forum/157-install-windows-from-usb/ You probably want to try : jaclaz

There are two main schools of thought on the matter. 1) The one I follow (which is objectively more complex to realize) is that first thing "boot" and "system" volumes must be separated, in the case of a Windows NT OS, installing it in a volume inside Extended, and in a multiboot scenario a volume must have a same drive letter assigned in each and every OS that accesses it AND that all volumes should be accessible from all OSes installed. The caveat is that more than a few (poorly conceived) programs will insist on installing (or however using files) on C:\, and in some cases they are a nuisance, on the other hand a (very stupid) malware virus hardcoded with C: or blindly wiping the active partition in the MBR will be able to make much less damage. 2) Alternatively, nothing prevents you from having completely separated installs, with the partition(s)/volume(s) of the "other" OS hidden from the "current" one. This gives a number of advantages, i.e. the install of each OS will be more "standard" so you won't have any issue with programs hardcoded for C:. Both are valid approaches, what I recommend in the second is to NOT have normally the "other" drive/volume visible, the idea is that before or later one is booted in the "other" OS and makes something destructive on the "wrong" volume because of a same volume having different drive letters under different OS. Of course, even in this second situation, the "other" drive/volume in a dual boot can be made visible - in case of need - to repair/fix the "other" OS. Example for #1: 1) small, FAT32 partition primary active drive letter C: 2) NTFS volume (logical volume inside Extended) Vista drive letter D: 3) NTFS volume (logical volume inside Extended) Windows 8.1 drive letter E: 4) NTFS volume (logical volume inside Extended) Common Data/Storage drive letter F: Example for #2: 1) NTFS volume active[1] primary partition Vista drive letter C: (hidden when 8.1 is booted) 2) NTFS volume active[1] primary partition 8.1 drive letter C: (hidden when Vista is booted) 3) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter D: from BOTH OSes 1st example for a "mixed mode": 1) small, FAT32 partition primary active drive letter C: 2) NTFS volume primary partition or logical volume inside Extended Vista drive letter D: (hidden when 8.1 is booted) 3) NTFS volume primary partition or logical volume inside Extended 8.1 drive letter D: (hidden when Vista is booted) 4) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter E: from BOTH OSes Of course there are other possible setups, including having the small FAT32 partition have not a drive letter assigned normally, which is what more or less is already happening on UEFI/GPT disks, i.e.: 2nd example for a "mixed mode": 1) small, FAT32 partition primary active no drive letter assigned 2) NTFS volume primary partition or logical volume inside Extended Vista drive letter C: (hidden when 8.1 is booted) 3) NTFS volume primary partition or logical volume inside Extended 8.1 drive letter C: (hidden when Vista is booted) 4) NTFS volume primary partition or logical volume inside Extended Common Data/Storage drive letter D: from BOTH OSes jaclaz [1] this approach needs a bootmanager capable of changing the active status of the partition and hide the "other" one at boot time

Good, thanks for sharing your experience/opinions . jaclaz

A tool that is often used to check that size is Sysinternals NTFSinfo. Example data from a couple volumes of mine (NTFSinfo), same size 320 GB, this is a "system" volume with a zillion little files: MFT Information --------------- MFT size : 546 MB (0% of drive) MFT start cluster : 786432 MFT zone clusters : 59059648 - 68687552 MFT zone size : 37609 MB (12% of drive) MFT mirror start : 39070076 And this is a "data only" volume: MFT size : 111 MB (0% of drive) MFT start cluster : 786432 MFT zone clusters : 48915648 - 49332416 MFT zone size : 1628 MB (0% of drive) MFT mirror start : 39070076 These are volumes of exactly the same size, on two identical disk drives, used in a very different manner for a few years, you can see the noticeable difference in $MFT size. What happened in your case, most probably , is that over time you wrote and deleted on that volume a large number of files, and most (if not all) $MFT defragmenter/cleaners do actually defragment/clean, but they do not "shrink" the $MFT, which remains "of increased size", see: https://docs.microsoft.com/en-us/windows/win32/fileio/master-file-table? AFAIK there is (or was) only a single (BTW commercial) tool from Paragon that allowed to "compact" the $MFT once the entries were emptied/cleaned, see page 21 here: https://www.paragon-software.com/docs/TD2009_Manual.pdf the tool (or its successors) does not exist anymore: https://kb.paragon-software.com/article/1807 but the function is in the hard disk manager: https://www.paragon-software.com/home/hdm-windows/ no idea if the trial of the old thing allows that : https://www.softpedia.com/get/System/Hard-Disk-Utils/Paragon-Total-Defrag.shtml There are "rumours" that if you fill the disk up to the brim (adding a single or very few very large files), the NTFS will try to reduce the (unused) $MFT areas, but I have no real confirmation. Since it is only a data volume, it might be worth a try to do that experiment (of course after having made a copy of the data), otherwise it would make sense to copy the data to an external disk, re-format the volume and copy back the data, a 232 GB volume, not completely filled should be all in all a matter of a few hours. If you want to try the "fill up to the brim" experiment, get the dsfok toolkit: https://web.archive.org/web/20190910101150/http://members.ozemail.com.au/~nulifetv/freezip/freeware/dsfok.zip and use fsz: jaclaz

Yep, Which makes little sense, /R and /B imply /F. /R and /B are somehow contrasting options. /R scans areas NOT marked as bad (i.e. not listed in $BadClus) and sees if there is anything to be added to the list. /B scan all volume and "judges" whether areas already marked as bad can be "promoted" to good and adds any bad area to the list. If you prefer, /R trusts the existing info in $Badclus, whilst /B ignores it and represents a sort of "second opinion". Still on modern media, any bad (or even "weak") sector should normally be detected by the controller and remapped to a good spare sector well before and besides any chkdisk activity. Get a tool that can read the S.M.A.R.T data, example[1]: https://hddscan.com/ look for items #5. 187, 188, 197 and 198: https://www.backblaze.com/blog/what-smart-stats-indicate-hard-drive-failures/ and post what you get on that disk. Post the exact make/model of the disk, usually there are manufacturer tool that can do deeper analysis of the device. jaclaz [1] there is a much more compact and nifty as usual tool by Nirsoft , but it doesn't show the SMART parameter numbers; https://www.nirsoft.net/utils/disk_smart_view.html

The Superdelete seems like being "simply" looooong names/paths capable. Was it the issue? The example you posted doesn't seem so long a path, and (in the superdelete context) the use of 8+3 paths should have not been necessary . (only trying to understand why it worked) jaclaz

Nice , but I have to ask. In the good ol' times there were *some reasons*[1] to install Windows on FAT32 and it was actually possible up to Vista (7 had an issue with number of files/directories connected to WinSxs, that had to be worked around): http://reboot.pro/topic/19643-winsxs-hardlinked-files/ exFAT (which I am definitely not very familiar with) should be - essentially - a sort of FAT64, so it may provide as well some advantages (and possibly drawbacks). ZhuMa, If you have experience with these, can you list what you observed/which usage cases exFAT would be suited for? jaclaz [1] various ones, not necesarily good ideas, still ..., including getting rid of file permissions, wider compatibility in some peculiar multiboot setups, in some setups slightly faster data transfer, etc.

Development of Winimize stopped circa 2007, so that seems fine. Just in case, at the time the official board for it was bootland (now reboot.pro), where you can find some of the discussions and a few tricks/ideas/etc,: http://reboot.pro/forum/53-winimize/ jaclaz

... while it should be set as Manual ... (but this is likely unrelated) jaclaz

How (exactly) are you running chkdisk? https://www.overclock.net/forum/132-windows/1603282-what-does-chkdsk-b-argument-do.html In any case on modern disks it makes very little sense, bad sectors should be remapped internally to the disk long before they are found/mapped by windows, the fact you see them might mean that there are some problems at hard disk level, like the amount of spare sectors already used. You need to run the manufaturer tools or some third party disk level tools to check the condition and health of the disk, whether this info is available may depend on the specific hard disk make/model. jaclaz

How big is the volume? How big is the $MFT? Have you tried defrafmenting the $mft with Sysinternal's contig? Is that the System (or Boot) volume or just a data volume? jaclaz

No, never thought that, all I say is that there are a few versions of devcon.exe from MS, not particularly easy to find, all AFAICR with builds earlier than when the source code was released, AND that the link in the readme : http://download.microsoft.com/download/1/1/f/11f7dd10-272d-4cd2-896f-9ce67f3e0240/devcon.exe is 404, of course if you already have that particular version and/or you retrieve it via Wayback Machine: https://web.archive.org/web/*/http://download.microsoft.com/download/1/1/f/11f7dd10-272d-4cd2-896f-9ce67f3e0240/devcon.exe it will work nicely . As well, I never said that there will be issues in using MagicIso to modify the DPMS.iso (which is not bootable), only that when people talk of editing .iso's there may be issues with this (or that) program. jaclaz

There is some language misunderstanding. No idea what you mean by UAC Virtualisation. The process manager has nothing to do with this, you mean the service manager? The service is either running or is it not. You can use (easier) the little Nirsoft tool Serviwin: https://www.nirsoft.net/utils/serviwin.html to check the installer service status. Then open regedit, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\msiserver and export it to a .reg file. The result should be the same as the .reg file posted on the given MS KB, if not, attach the .reg file you exported to your next post. Next step, try the troubleshooter here: https://support.microsoft.com/en-us/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed jaclaz

What filesystem? Which media? Which OS? There is a (rare) issue on NTFS that may create undeletable files, maybe this is the case? jaclaz

Good. For a short period of time, devcon was released as open source, and a member here compiled it (just in case): https://msfn.org/board/topic/173201-gavottes-ramdisk-automation-package/ https://msfn.org/board/topic/173201-gavottes-ramdisk-automation-package/?do=findComment&comment=1091396 As a general rule, using "MagicISO" or similar auto-magic software is not a good idea (when talking of bootable/OS installs .iso's), the point is that a .iso is NOT (by definition) editable, so what all these programs do is to re-create (transparently from the user point of view) a NEW .iso and some settings related to the original .iso may (or may not) be changed, if you prefer this kind of programs tend to work perfectly (and conveniently) until they don't. You are welcome , jaclaz

Yep, sorry , it is normal, round brackets, correcting the typo, As expected (even if it was really blurry) only one disk is seen in grub4dos (actually in BIOS), and from the size and partitioning it should be the USB stick, 7833720*512 should be a 4GB stick. Anyway the partition is NTFS and ID 0x07, how (the heck) can the XP setup see it as FAT32? (not that it should matter) Try after a cold boot, what this test confirmed is that the internal disk has not been detected at all. jaclaz

The out of focus image seems to mean that only one disk was found (the USB one) and thus it is first disk and its MBR is chainloaded. No idea why this may happen, when you are on the grub4dos menu, press "c" to get to command line, then issues commands: geometry (hd0) [ENTER] and geometry (hd1) [ENTER] and map --status [ENTER] and post results. BTW the way the USB stick is shown in the Windows Setup is "strange". As a side note, try changing in BIOS settings the boot order, settng USB as first disk (as opposed to choosing to boot from USB after having pressed F12 (or *whatever*) which seems like what you tried doing. jaclaz

Sure, if we go back to the real cause of the 2.2 TB "limit", it isn't. The limit is the 32 bit size of the two LBA fields in the partition table of the MBR, which limits the size to 2^32-1= 4294967295 sectors. So 4294967295*512=2199023255040 or roughly 2.2 TB [1]. When the sector size is 4096 bytes, the limit becomes obviously 8 times that, i.e. 4294967295*4096=17592186040320 or roughly 17.5 TB. NTFS has no issues whatsoever with larger than 2.2 TB partitions. jaclaz [1] actually on post-XP (due to other limits on XP it seems not possible) making a special arrangement of 2 partitions one can reach almost 4.4 TB

Some news from Redmond: https://support.microsoft.com/en-us/help/4576988/can-t-uninstall-microsoft-edge jaclaz

Maybe then the issue revolves around permissions and/or your login credentials? Those keys in the Registry should normally be accessible as Administrator. Or maybe you have some policies applied preventing it? You can still try running the Regedit as "Trusted Installer" and import the .reg but it should not be needed. http://reboot.pro/topic/22326-powerrun-v14-run-with-highest-privileges/ https://www.nirsoft.net/utils/advanced_run.html jaclaz

Follow the first two methods detailed here (method 1 and method 2) BUT try first #2 and only if the service does not start manually or you have the "could not be accessed" error, try method #1, followed by #2 again to make sure the service is running : https://support.microsoft.com/en-us/help/2642495/the-windows-installer-service-could-not-be-accessed-error-when-you-try jaclaz

Semi-random idea, but have you considered posting them as a collection on archive.org? jaclaz

How Nice of You, I was fearing to be Overwhelmed by the Sheer Amount of Information being Published. on the Log. jaclaz