jaclaz

Well you can still have BOOTICE (free and GUI) or use efibootmgr from any "live" Linux distro. BootIce can be found also on reboot.pro (but right now it is down) , get it from Softpedia: https://www.softpedia.com/get/System/Boot-Manager-Disk/Bootice.shtml What you changed (just so you know) are some data in the UEFI NVRAM, so loosely yes, they are "in BIOS". jaclaz

Get the wget from the page I posted (and NOT from any other place): https://eternallybored.org/misc/wget/ The XP version I used is 1.19.4, (I posted with a typo before, it is not 1.9.4) Current Windows Vista+ is 1.20.4. If you actually ran 1.11.4, it is WAY OLDER and very likely has not the feature that was added to it in 2015. jaclaz

It must be a heck of an interference to affect a whole node/neighborhood, if you see in a near house something *like* this: that is likely the culprit jaclaz

There is no such thing as "Linux boot menu". The boot menu is what the bootmanager loads, very likely you have GRUB2 as bootmanager/bootloader. And of course you are not dual booting Linux and Windows 10, you decide if you want to remain generically vague (i.e. Linux and Windows) or if you want to detail which Linux distro AND version it is besides Windows 10 LTSB. More generically, if you actually have GRUB2 as bootmanager, you should be actually preoccupied of the Linux updates/upgrades, as most times they do run an "update-grub" command that actually rebuilds (or rather attempts to rebuild) the GRUB2 configuration file (which is usually grub.cfg). If you prefer, the grub.cfg menu (which is very likely what you see when you boot) in GRUB2 is not "static" and is generated (at install time and re-generated with the grub-update command) starting from a set of "base" files. Depending on the EXACT way the GRUB2 has been installed and on the contents of these files, and on the EXACT distro/versions of the Linux distro you are using, this (stupid) auto-magic regeneration may work or it may not. Most of the times it just works, of course, but when it doesn't you'd better have a plan B. Having a backup of the "current" grub.cfg is of course obligatory, but you will need to get familiar with the (complex) mechanism of grub.cfg (stupid) auto-generation and also IMHO get familiar with a few needed GRUB2 commands, as if for whatever reasons the grub.cfg is not found or it has been automagically updated and the update didn't work you will find yourself incapable of booting and stuck at a grub-rescue> prompt. Here is an exceptionally good tutorial: https://www.dedoimedo.com/computers/grub-2.html You want to make sure that either there is a directory corresponding to your Window install or that the provisions for it are inside the 40_custom one, but you should learn also how to boot both the Windows and the Linux from a plain grub-rescue> prompt via a sequence of commands, and - adviced - have handy a copy of the SuperGrubDisk: https://www.supergrubdisk.org/ https://www.supergrubdisk.org/super-grub2-disk/ just in case. jaclaz

Maybe it is the way the Wayback Machine sends the original file/date/time. I tried the: https://web.archive.org/web/20190726124532/http://download.windowsupdate.com/c/msdownload/update/software/secu/2014/09/windowsserver2003-kb2972207-x86-ita_d5cbff29878fc957eae4b256f167918417a88e2d.exe Actually I tried the http link : http://web.archive.org/web/20190726124532/http://download.windowsupdate.com/c/msdownload/update/software/secu/2014/09/windowsserver2003-kb2972207-x86-ita_d5cbff29878fc957eae4b256f167918417a88e2d.exe With good/ol' Net Vampire 3.3: https://www.fileplanet.com/archive/p-43170/Net-Vampire-3-3 and it couldn't fetch the original date BUT looking at its log : the needed info seems to be actually transferred. Now all you need is finding a tool that actually parses the info in "X-Archive-Orig-Last-Modified", but now we have a good search term, thus: https://gitlab.com/gnuwget/wget2/issues/205 So, the gnu wget seemingly can parse it, why woudn't a Windows wget? As a matter of fact I just tried this: https://eternallybored.org/misc/wget/ Version 1.9.4 as I am on XP: https://eternallybored.org/misc/wget/releases/old/wget-1.19.4-win32.zip And I got this: Hep! Now, the attentive reader will have noticed that the timestamp is not actually correct, the Wayback Machine sent: Tue, 02 Sep 2014 22:33:03 GMT Whilst the file timestamp I got is: 03/09/2014 00.33 But this is inherent to the way filesystem timestamp change depending on local time settings, the actual NTFS timestamp is UTC, i.e. roughly GMT, but it appears according to my local settings. jaclaz

Anything that: 1) is a good conductor (i.e. copper, aluminium, iron/steel etc,) 2) can be wrapped around the cable (i.e. metallic foil/tape) or into which the cable can be inserted into (metallic pipe) 3) is continuous and thus can (optionally) be grounded (on one end ONLY) will do nicely. jaclaz

Very likely it is (was) a non-canonical ACL : https://support.microsoft.com/en-us/help/320081/you-cannot-delete-a-file-or-a-folder-on-an-ntfs-file-system-volume What I would do (once everything is actually disabled/deleted/etc.) Copy the Far.exe to a FAT16/32 volume. Delete the Far.exe copy on the NTFS volume. Copy back from FAT volume to the original NTFS folder. Check again NTFS permissions. Alternatively, use SetACL: https://helgeklein.com/setacl/ jaclaz

Wait a minute, which OS is that? XP Home? (but I seem to remember that Home misses it on folders also ) In case: https://www.bleepingcomputer.com/forums/t/281059/how-to-add-security-tab-in-windows-xp-home/ Are you sure the file is actually a file (and not a link)? Anyway, try checking it with CACLS or XCACLS: https://ss64.com/nt/cacls.html https://ss64.com/nt/xcacls.html So, if I get it right, when Threatfire is running with the far.exe added to the exclusion list, you can run it once but not twice, and now with Threatfire disabled it cannot run even the first instance? Then it must be still connected to Threatfire. jaclaz

Hmmm. If you could post a link to the file, that would surely help. Free Download Manager used to have such an option, but I believe it is not there anymore in 5.x version, you might need an old version, try using the "lite" 3.9.7: https://www.freedownloadmanager.org/download.htm .Of course it may also depend on server side. jaclaz

Well, first thing you should check the permissions of the file (and of the directory where it is): http://www.ntfs.com/ntfs-permissions.htm You may need to take ownership. You are however "mixing" two different "features". One is NTFS permissions (that have been on NTFS since the dawn of time) and the other is UAC, User Account Control, which is the "new" thing since Vista). BUT it seems strange that it can run once and then no more. Is it not some feature of that "Threatfire" thingy? jaclaz

What do you mean? I.e. it started "suddenly" and "before" you had not that issue? Which kind of connection do you have? Loosely, anything up to the "delivery point" of a service (i.e. normally up to the cable box/receptacle inside your house) is property of the ISP and you cannot touch it. Changing the cable from the (ISP owned/connected) receptacle to your modem is doable, of course, but that won't help if there is RF injection before that point.. And I have never seen triaxial cable used for data transmission, they are used AFAIK in video trasmission in the aircraft industry *like*: https://www.picwire.com/cables/video-mates/ The only thing that you can do is - I believe - to have the cable replaced (by the ISP, and only if they accept to do it) and have it put into a shield, a copper pipe would do nicely but there are also specific products *like*: https://www.tech-etch.com/shield/install.html jaclaz

Yep , if you can call (keeping a straight face I mean ) running Windows 98 on a 4 Kb sectored 17 TB disk "practical" . jaclaz

Try again: bcdboot C:\Windows /l en-us /s k: /UEFI If you still have the error (and even if you haven't it), run a DIR command: DIR /S K:\Efi And/or: DIR K:\Efi\Microsoft\Boot Verify that a file K:\Efi\Microsoft\Boot\bootmgrfw.efi and a file K:\Efi\Microsoft\Boot\BCD actually exist. If they don't, try checking if bootmgfw.efi and bootmgr.efi exist here: C:\Windows\Boot\EFI\ If they do run: mkdir K:\EFI\Microsoft\Boot xcopy /s C:\Windows\Boot\EFI\*.* K:\EFI\Microsoft\Boot then try running again: bcdboot C:\Windows /l en-us /s k: /UEFI If you still have the error and you still boot to the grub rescue prompt, type in it: root (hd1,gpt1) [ENTER] chainloader /EFI/Microsoft/Boot/bootmgfw.efi [ENTER] boot [ENTER] the (hd1,gpt1) in the above means first gpt partition on first disk, if the EFI partition (the one you assigned the drive letter K; ) is not the first one, change accordingly. What happens? jaclaz

That is the issue. What you are asking is seemingly about wanting TWO "Program Files" folders, one on the HDD and one on the SSD, but there can be only one. Once upon a time programs (well most of them with the usual exceptions of - say - MS and Adobe) could be installed *anywhere* (i.e. not necessarily in "Program Files") and even had (easily) the possibility to tell them where to store their "work" files. Nowadays this can still usually be done but it is complex and a number will use as "Program Files" folder the location set in the Registry for it. If you want to have the actual files pertaining to "Program Files" residing on another disk you can (alternatively): 1) change the location in the Registry for "Program Files" (and also for "Program Files (x86)" to point to another volume OR 2) make in the C:\Program Files (or - IMHO better - the various programs folders inside it) a junction to another volume (softlink) folder Hard to say which one is a "better" solution, considering that you will also find (hopefully a few only) programs that will want to install to "C:\Progtam Files" anyway (hardcoded path in the installer) if I were you I would choose #2. A "better" solution (IMHO) is to actually manually install the programs to (say) D:\myPrograms leaving alone the "normal" C:\Program Files, this will allow you to obtain (more or less) what you asked for, i.e. two "Program Files" folders on two different volumes. Still I believe that YMMV, depending on the specific Program that may (or may not) allow that. jaclaz

The partition needs to exist AND it needs to be mounted to a drive letter. (Hint: normally EFIBOOT partitions are NOT assigned a drive letter automatically) If you don't know how to look at your partitions (Hint: Diskpart or Disk Manager) and you don't know how to assign a drive letter to a partition (Hint; Diskpart or Disk Manager) it will be a looong thread . Let alone if you need to create some space on the disk, and create/add a new EFIBOOT partition. It is of course doable, but if the main objection is "its too general and lowlevel" you won't get very far, in order to do (mildly) advanced things you need (mildly) advanced knowledge, or refrain from doing them or ask for assistance before doing them. I have no idea : 1) how was (EXACTLY) your "old" disk, OS, etc. setup before 2) how (EXACTLY) you partitoned and formatted the new disk 3) how (EXACTLY) you copied what (EXACTLY) 4) what (EXACTLY) is on your new disk 5) what (even if not exactly, approximately) is your level of familiarity with the Windows (and/or Linux) OS 6) etc. Is it so surprising that the advice is "general" (because of the lack of details) and "lowlevel" (since if you need ot repair a boot it is actually "lowlevel")? Anyway, see if an almost complete tutorial helps: http://woshub.com/how-to-repair-uefi-bootloader-in-windows-8/ If you don't have the EFIBOOT partition, how to create it may depend on whether you have space for it on the disk or if you need to resize another partition, generally the "right " set of instructions are here (as in theory a Windows 8+ installation also has a MSR 128 MB partition/volume: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions https://systemscenter.ru/waik.en/html/79f51a90-a8e9-410d-bd76-af197b865a49.htm jaclaz

BCDBOOT: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcdboot-command-line-options-techref-di jaclaz

Little green men have come a long way since when they were just stealing socks ... green men 2.0! jaclaz

No it isn't, should have been called BluetoothMonitor: https://www.nirsoft.net/utils/bluetooth_viewer.html jaclaz

Try following this: https://www.tenforums.com/drivers-hardware/22049-how-completely-remove-bluetooth-device-win-10-a.html https://www.tenforums.com/drivers-hardware/22049-how-completely-remove-bluetooth-device-win-10-a.html#post1540911 The mentioned tool seems like capable to unpair on-yhe-fly ALL Bluetooth devices: http://bluetoothinstaller.com/bluetooth-command-line-tools/ http://bluetoothinstaller.com/bluetooth-command-line-tools/btpair.html jaclaz

lawlietfox-67.0.4-1-win64-vc15-nopgo-O2 How queer. jaclaz

OT, I know, but it would IMHO suit a system with A: as systemdrive (no idea if it actually works post-XP): http://www.novell.com/coolsolutions/tools/14474.html jaclaz

Well, the WinPE is still a Windows NT. And you still have to check the disk signature on BOTH disks, one at the time, and check the given Registry key on both (again one at the time). Mind you, it is perfectly possible that the program you used takes care of the possible issue, but: vs.: might be the disk signatures. As a matter of fact this: Plainly means: "assign the C: drive letter to the volume that is residing on the disk with signature 00026180 starting at offset 0x140A300000, i.e. 86070263808, i.e. LBA 168105984" the latter being strangely similar to the lines in the log: IF this: had been (hypothetical): I would personally have been more convinced that it operated along the previously detailed #1 approach. The: might mean that instead the previosly detailed #2 approach has been used. But you'll never know until you check. Now, be nice, open a disk viewer editor and check the Disk Signature on both disks (again with them connected one at the time) or boot from USB to grub4dos and in it issue: cat --hex --skip=440 --length=4 (hd1)0+1 (hd1) in the above is assuming that you have only one disk besides the USB stick you booted from that should be (hd0) jaclaz P.S.: cluster size is an attribute of the filesystem, it has NOTHING to do with the issue at hand.

No. If the system loads there are no issues with the active partition. The actual (good ) question is how (EXACTLY) the disk was cloned (IF it was actually cloned)? Point being that NO TWO clones can be connected to a WINNT system at the same time. The sheer moment two disks with the same disk signature are connected at the same time to a NT system the disk signature ot one of the two will be changed. The one with the changed signature won't boot, because the OS cannot (in a nutshell) "find itself". There are two possible solutions (depending on the use of the "clone"): 1) set the changed disk signature back to the old one [1] 2) set the references in the Registry to the new disk signature [2] or remove them and let the system recreate them [3] The relevant Registry key for #2 is: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices Each value in it referring to a volume or to a drive letter residing on a "hard disk like" device is a hex value made of: Disk Signature+Offset to the beginning of the partition, EXAMPLE: 59 AE 59 AE 00 7E 00 00 00 00 00 00 Please note how the values are - as usual - reversed, the Disk Signature value in the Registry is in the same order as it is written to the MBR @offset 440 decimal but the actual disk signature value is AE 59 AE 59 as seen in a number of tools. the 00 7E 00 00 00 00 00 00 is 0x07E00, i,e, 32,256, aka 63 sectors by 512 bytes=32,256 jaclaz [1] this assumes that the "original" will NEVER be connected again at the same time as the "Clone" [2] which is a bit complex, doable but needs some time and attention, particularly if there are many volumes [3] this may change the drive letter assignment of volumes that were not auto-assigned previously [4] both [2] and [3] above (but it is rare) may cause issues with programs that use the Disk Signature for some form of verification

Some August news: https://seclists.org/fulldisclosure/2019/Aug/0 The good MS guys were seemingly not particularly impressed, however : jaclaz

Download links don't "die overtime on MSFN". Users posting links to not reliable hosting servers (or unmaintained ones) create (not-so-surprisingly) unreliable links. Anyway, JFYI, a generic rule of the thumb when requesting a missing file is to post an EXACT reference to what you are missing, a link to where it is cited, a link to where it was, etc,: a description like "the 20mb file listed here" is totally pointless (and lots of people that actually may have the file won't lose their time in this guessing game). jaclaz