jaclaz

Yep , but again (like in your first post) you are using improperly the term "cluster", while the issue revolves around the "sector" or "block" size. Most probably you miss (in the Windows 7 that you DO NOT use) this hotfix: https://support.microsoft.com/en-us/help/982018/an-update-that-improves-the-compatibility-of-windows-7-and-windows-ser which - notwithstanding it says it is only for 512AF disks- should apply also to 4K disks, mainly because it has newer drivers (SATA) and also some changes in the USB stack. But we will need a confirmation/denial by someone that actually uses Windows 7 AND such large drives. jaclaz

Yep, I meant in device manager. jaclaz

Good, so it is something "internal" to the machine and the network is likely OK. Now try disabling the NIC. In theory a machine with a disabled NIC is an isolated machine, so if the slowness is network related it should go away. jaclaz

Well it seems clearly an issue related to network. That could be either a "wrong" setting in something related to network, like NIC driver, its settings and/or network protocols (and/or file/resource sharing) on the actual system or *something* on the network itself. These can be tough to troubleshoot, becase the same symptoms may be caused by different issues (including some external to the actual machine). If you physically disconnect the LAN, what happens? (provided that it is a cabled LAN, if it's a Wi-Fi try disabling the interface) Then you should go through the whole set of checking *anything* related to network, IP assignments, gateways, DNS, TCP/IP and MS network client, etc., etc. jaclaz

Wise words jaclaz

Good. Now that the issue is solved, we can comment wondering what (the heck) the good MS guys "touched" related to GPT partitioning and/or Disk Manager and/or Mount Manager (or Explorer) "touched" to create the issue (which seemingly is not an isolated case, but happened to lots of people). That partitioning scheme wth the "recovery" partition is AFAICR the same - suggested by MS themselves in official documentation - since Windows 8 (i,e- circa 2012) and in themselves the behaviours of the involved subsystems is the same since the dawn of time on NT systems. Thet "invented" the 27 and then the DE94BBA4-06D1-4D40-A16A-BFD50179D6AC (and conversely the 0x8000000000000001) and now they don't even respect it? jaclaz

Yep , exactly. Just in case the only somehow meaningful S.M.A.R.T. parameters that can actually (maybe and perhaps) predict an impending failure are: 5, 187, 188, 197, 198 http://reboot.pro/topic/21652-there-is-limited-lifetime-writes-on-seagate-hdds/?p=205079 And here is yet another simple tool by our friend erwan.l: http://reboot.pro/topic/21659-smart-hd/ jaclaz

In case you can try the other way round, i.e. first remove the drive letter with mountvol (this, unless the flag already starts with 0x80... will be only temporary until next reboot), then change the attribute flag with diskpart. jaclaz

Should be 0x8000000000000001, not 0x8000000000000000. https://superuser.com/questions/1108243/setting-winre-windows-recovery-environment-flag-on-partitions jaclaz

S.M.A.R.T. is a set of parameters that are monitored/recorded by the disk controller itself. You need a program to view them. The recommended tool is SmartMonTools: https://www.smartmontools.org/wiki/Download#InstalltheWindowspackage BUT for the intended use it will be easier for you to use this graphic interface to it: https://gsmartcontrol.sourceforge.io/home/index.php/Downloads S.M.A.R.T. (which I personally call "DUMB") data is usually of no use whatever, but in some, few and rare, cases it may help in understanding if a disk drive is actually going bad. I don't think this is the case, but checking it doesn't do any harm. The actual issue (the Delayed Writing) is usually one of those "misterious" issues that may come from a number of sources, likely it is some form of conflict with some driver (often graphic card drivers are mentioned as being part of the cause) or however programs that access memory directly, it is usually extremely difficult to find the culprit. More often than not this problem affects external (USB) disks, but in some cases it affects also internal (directly connected) ones, possible mitigations (if not solutions) may be different if the disk is an internal or an external (USB) one, you need to specify this. jaclaz

The partition ID "needed" to have NOT a drive letter assigned is "27" (when the disk is "MBR style"). The corresponding GPT ID should be the one used for the recovery environment, i.e. DE94BBA4-06D1-4D40-A16A-BFD50179D6AC But that partition is not (anymore) a "start partition", for whatever reason the "boot" (what MS calls "system") is the 99 MB sized one (which is FAT32, as it normally is the "boot" partition on EFI systems, unless the specific motherboard dirmware has a EFI NTFS driver). So, what exactrly is on that 450 Mb partition? (it is not used in booting) Maybe you had the machine earlier running as BIOS/MBR and then you converted it to UEFI/GPT? jaclaz

Are you trying to be funny? You are replying to someone that has something like 10000% of your knowledge on Windows and Author of several drivers. I would assume he already thought about that. jaclaz

Maybe it is subjective, you don't feel like being in the dust, but from dhjohns' point of view it may seem so. jaclaz

Yeah, sure. jaclaz

No, if the disk exposes 512 bytes sector the 2 TB limit is due to the 32 bytes field in the MBR (this cannot be fixed), though there is a workaround, using a particular partitoning scheme, to access up to 4 TB on MBR stryle disks on BIOS that works in 7. Some references: http://reboot.pro/topic/21788-auugh-i-think-i-screwed-up-easy2boot-on-a-4tb-usb-drive/?p=206968 jaclaz

The good MS guys made a mess. There is (was) three main types of product (both CD and License) that could end up in the hands of a "final" user: 1) FULL <- you can install it on *any* hardware (and change hardware any time you want, as long as you don't run concurrently more PC's than licenses) 2) OEM <- you can install it on *any* hardware (and then changing the hardware is not allowed - though technically possible - and usually MS would re-validate it on new hardware, provided that some reason is given, like replaced motherboard and similar) 3) Large OEM <- you can install it only on the hardware for which it is licensed (and then changing the hardware is not allowed - though technically possible, and usually having MS re-validate it was difficult or impossible) The last one later evolved in OEM SLP (used by very large OEM's like, say DELL, HP, Toshiba, etc.), where activation is not needed at all, as it is automated through a code embedded in the BIOS of the machine it is sold with. nlite is only a tool, to give you an example of a possible use (on a "same" computer) you may have bought a PC with a SATA controller but you would be forced to install XP in "IDE compatibility mode" (slightly slower than "pure" SATA) because the SATA driver is not included (slipstreamed) in the install CD and - for whatever reasons - you cannot go throught the "traditional" F6 floppy routine to install it. jaclaz

It is entirely possible that they took the servers down recently, tough I doubt they did that in march 2017 (as in the given link). The OP managed to connect with the automated phone activation servers just fine (so they still exist) the issue here is that - for some reason - the procedure didn't work. The MGADIAG however says: so, if I recall correctly, SLP cannot (and never could) be activated online, they are intended as self-activating IF they find the same hardware they were released for, But not really my (narrow) field of competence. So, if OP is using the same hardware, then the nlite *somehow* made the install not valid (changed/removed OEMBIOS and related files?), while if the hardware changed then technically the license is not valid. jaclaz

Maybe she was one of the common (usually outsorced) "first level responder" which often, not always but often enough, are clueless. The MGADIAG tool is something you need to download from MS, here: http://go.microsoft.com/fwlink/?linkid=52012 And here you can find some basic usage instructions: https://www.raymond.cc/blog/checking-genuine-windows-and-making-it-genuine/ jaclaz

Hmmm. Maybe it is a "specific" thing for the "specific" (you choose, it's a mess, version, release, SKU, whatever) "item" you have in your hands, but I still don't think that they (again, product code, activation number, whatever) can actually "expire", while it is possible that (again for whatever reasons) the thing was somehow "blacklisted". I mean, if the activation wasn't working in an absolute way (i.e. it was intentionally "retired" by MS) the telephone method wouldn't have even looked up for the number. I suspect that for one reason or the other you are in a situation similar to this reported one (circa 2008): https://askleo.com/why_cant_i_activate_windows_xp/ maybe triggered by some "aggressive" use of nlite. If you google a bit around you will find a number of ways to "force" activation, but if not directly to the "dark side", they belong to a "gray area", so, sorry but I can't provide you with a direct link to these resources jaclaz

How exactly MS expressed this? I mean, did you phone them and talked with a representative, or e-mailed them, or what? Latest news I recall were that normally both "online" and (in case that failed) "automated telephone" worked still just fine, maybe they just changed something recently? jaclaz

To recap, I offered what I had, and tested one of the possible solutions (wscript sendkeys as they are said everywhere to be able to do that) and found out that for *some reason* the method doesn't work specifically for sending an ALT SPACE LETTER specifically to cmd.exe. So the sendkeys method that generically works just fine specifically doesn't work (at least here), so it does not represent a possible solution (unless there is some trick to have it working for the specific task). jaclaz

I think I have to give up , but I will try yet another time, Sending *any* keys/text via sendkeys works just fine on cmd.exe here, including commands like dir, echo, etc. BUT the sequence (via Sendkeys) ALT+SPACE DOES NOT. If I issue a ALT SPACE I (italian equivalent for the english ALT SPACE N) I obtain a space an a I on the command line. Still here, the SAME sendkeys script to *another* window (I tried Notepad) works just fine with ALT+SPACE. FINAL recap: The OP may get away with his request by issuing a ALT SPACE N (or I, etc, as said this is language dependent), so the only interesting thing is to succeed in specifically sending to cmd,exe specifically ALT SPACE N, so anyting else (that is working just fine) doesn't matter. With "normal" keyboard keypresses just entering ALT and space opens the dropdown box, and then the following letter is the choice. With sendkeys (as said here at least) sending ALT and space does not, it simply adds a space on the command line. jaclaz

Did you try the actual sctipts? The ALT+Space (actual keys) do work on all windows, it is the wscript SendKeys method that doesn't work here, for CMD.EXE only. jaclaz

But seemingly you tested *everything* BUT the ALT+SPACE combo (i.e. the one needed and that doesn't seem to work on cmd.exe, it seemingly works just fine on - say - notepad). Maybe a wrapper *like* Conemu is needed (but not applicable to the OP situation) jaclaz

The "close" X can be disabled, but then again that would require *something* that you don't want, i.e.: http://www.uwe-sieber.de/files/consolenoclose.zip But if the (small) cmd.exe window falls "inside" a largish HTA Windows you should be able to bring that HTA window to the front via VBS, can't you? But is it a HTA now?, wasn't it before a second cmd window? @gunsmokingman Any idea why the sendkeys method that as said works just fine in Notepad doesn't work in the CMD.EXE window? :unsure: jaclaz