“I turned my back. When I turned around again, the machine was already on the Windows desktop”
Is your dual-core laptop or 40-core workstation going slow? Steve explains one reason why this might happen, and how to solve it
Computers go slower the longer you keep them, says the folklore. I disagree. What affects computers’ speeds are the decisions made by Microsoft Update developers and managers.
This fact of life emerged while sprucing up a ThinkPad this month for a friend, as detailed over the page. It’s been something of a Lenovo month all round as a Lenovo C30 workstation was on the bench at the same time. There were a lot of bargains available in the aftermath of Christmas and
New Year, and this one seemed unmissable: 40 processor cores, 64GB RAM and a K-series Nvidia workstation graphics card for 200 quid? My hand was on the PayPal checkout almost without conscious thought.
It has, despite its luscious, early mega-core specification, been a royal pain in the backside. This isn’t the fault of the developers, nor of Lenovo, but because I tried to do something foolish on unboxing day. The sensible course for any second-hand PC purchase is to perform a quick clean of the case, fans and heatsinks and run an inventory of what’s there and what’s not. But I was in new toy mode and had a legitimate need to be sure the machine at least booted – part of the reason it was so cheap was the absence of a hard disk.
To get this monster on the bench, I first had to clear away an earlier workstation build: a Dell Precision T1600, which had just failed to go through an SSD update. Actually, I didn’t need to do much with it. Just admit the 256GB SSD I’d tried to use as the target of a partition copier should be removed and used somewhere else, as the copier package had been unable to cope with or report on its trials and tribulations while trying to complete a disk-cloning. I had sympathised because I was trying to go from a single drive mounted on a chipset in RAID mode to a much later-generation drive that was attached to the non-RAID port of the same chipset. Confusing enough for the human trying to divine the failure of the copy process, never mind for the BIOS of the machine and the drivers of the operating system being shunted about from pillar to post.
But! Being in a rush on unboxing day, I did things in the wrong order. In went the SSD, and I prepared to install Windows 10 from scratch from one of the drifts of USB storage devices piled up in every corner of the bench workroom. As always, it takes a while to find the right device, and I turned my back on the machine. When I turned around again, the thing was already on the Windows desktop.
The partition copy utility, despite agonising 15-minute timeouts, apparent brickings, and zero entries in logs or the event viewer, had actually copied the older SSD. This was what had booted up, in a machine with muddy gumboot marks still on it from a snowy delivery process.
I shouldn’t have been so surprised: Windows 10 can boot in almost any situation, if it’s been built on a fairly mainstream PC initially (that’s the
“Being in a rush on unboxing day, I did things in the wrong order”
Dell). The fact it had woken up in a machine with, incredibly, ten times the core count (and eight times the memory) wasn’t a problem. The actual problem was the awfulness of the partitioning copier: stuttering away asking for restarts in pre-OS mode and then claiming that nothing had been done is not what I want to see when I’ve actually paid for the full version.
So I turned everything off again, put the new SSD back in the T1600, and the older disk (from which the new SSD had been cloned) into the shiny new Lenovo C30. It too booted, if rather more slowly. I expected Windows Update to take a while to find drivers for all the new hardware, so while that was happening (or so I assumed), I went back to the aged ThinkPad.
Oh, look: a new link in the updates control panel, offering me some more optional updates. The revealed list was almost entirely device drivers, along with a comforting little note to say that these probably weren’t required unless I had “a problem”.
I ticked the lot, curious to see what might happen. It became abundantly clear that, after the optional downloads had arrived, this machine was in a completely different league when it came to performance.
ThinkPads are famous for some of the most extensive bloatware packages in the industry, and some of that bloatware says it monitors and updates your firmware and driver packages. So what had all the usual ThinkPad bloat utilities been doing for the many years I’d been toting this machine around the tech palaces of the world? Not downloading the usual mixture of performance-enhancing updates, that’s for sure.
Looking around on the ThinkPad’s boot disk, it exhibited some classic symptoms of a partial infection. In particular, big, unwieldy historic update directories, including some that were many hundreds of thousands of files.
Due to the strange behaviour of the partition copier software, I could look back in time on the other machine in front of me, too. Despite the monstrous horde of CPU cores, memory and storage bandwidth, this big old heavy hitter showed some of the same symptoms of slow running, and had not yet climbed far enough up the update monkey-puzzle tree to be offering the optional performanceenhancing updates.
Not even those updates were going to get away from the basic cause for these machines running slowly and strangely, that being the presence on the smaller machine of in excess of 300,000 update files (rather less on the big box, even though its copied-over SSD came from about the same period).
Let me emphasise: these files are not removed by housekeeping applications, be they third party or bundled in. Most people know about the software distribution folder inside the Windows directory, but there’s been far less discussion about the servicing/LCU folder (LCU stands for last cumulative update), or its nearby companion, servicing/Packages. These can be impressively vast: the LCU I found on the trackpadless laptop had as many files as the whole of the rest of the Windows subfolders put together.
Personally, I blame the master file table (MFT). This is the way that Windows keeps track of how files are represented on disk. Just in case, there are two copies of the MFT for every drive-letter partition on your Windows PC.
I am perfectly willing to believe that the code that reads, writes and upkeeps the MFT is a long way from being spanking new and freshly maintained. Why the cynicism? Because the culture within Microsoft always says the same things about MFT as a data structure: that they got it right to begin with and only a fool would cavalierly mess with such a vital function during updates that can be as diverse as processor firmware all the way through to a trackpad driver.
But that doesn’t actually tell us how the thing works. We know it gets copied into memory, but we don’t have a clear model or easy reporting of what happens when the initial amount of memory reserved for MFT functions is consumed. Then you start to think about “strategies” adopted long after the initial design of the storage access subsystem was finalised.
I’m thinking here about things such as prefetch and predictive scanning of nearby directories “in case” the user wants to look in them. All well and good while we’re talking about a few hundred holiday snaps, not so great when it’s 300,000 just-in-case backups of the old DLLs removed by the most recent Cumulative Update download. Those really ought to be excluded from pre-fetch activities but nobody has a mechanism for excluding them.
I used to think that I was just a tidy-up freak, and that my efforts to keep my machines lean and mean was why my systems continued to thrive and those of the “slowdown fanatics” went in the opposite direction. But the LCU problem shows that a deep clean is required. All I can report with certainty is that both machines – one so unfeasibly vast by the standards of the other that it should never display a slowdown detectable by a human – were plainly faster in every way after a good old-fashioned manual clear-out.
Security stupidity
The reason I had to rapidly exhume the ThinkPad mentioned above is that a friend lost literally everything in an apartment fire. Computers, passport, all sorts of personal filing such as domestic utility bills. All gone. Support from our circle of friends was rapid, heart-warming and almost entirely dependent on social media.
The first thing to draw attention to is the unnecessary tyranny of identity management. Naturally enough, the best way for a globally scattered peer group to provide immediate support is to send money.
“Both machines were faster after a good old-fashioned manual clear-out”
The first hint of trouble was the process required to replace a purse loaded with credit and other cards, which had been reduced to a charred pile of microchips in the conflagration. Call up the card issuer and explain that not only are the cards gone, but so is the letterbox.
Any self-respecting postie turning up to this address is not going to merrily deliver the (unmarked and anonymous) envelope they send cards out in these days, and while some card issuers will let you pick up from their high-street branches, these are closing at a rate of knots.
Absolutely none of them would agree to other issuers’ cards being sent to them as poste restante, even if the other issuers’ shipment systems would allow it, which they don’t. Then, in the near-perfect catch 22, those issuers who do allow deliveryto-branch want you to bring along the resolutely physical proofs of identity so they are guarded against scammers. You know, the proofs of identity such as your last gas bill, birth certificate and all the other stuff that’s presently a pile of ash in my friend’s case.
Bad news upon bad news then followed, because the online charity-collection website won’t novate the account filled with well-wishers’ donations to another person, without those self-same paper-based bona fides, or a “restart”, which helpfully includes the home address of the beneficiary. And we know that the home address in question looks like it was just hit by a HIMARS rocket, and the former inhabitant is being shuffled around various temporary, B&B-type accommodation in the locality.
Unless the local council announces the rehousing address in advance (not likely!), there are many steps in the various processes before the security requirements of the numerous institutions can be satisfied.
Several remedies are theoretically possible, but they require a lot of infrastructure to successfully complete. Think a decent Wi-Fi connection and a relatively recent computer or tablet to work through the various online procedures deemed necessary. I am told that emergency inner-city B&B accommodation is not the sort of place to be leaving expensive laptops loaded with personal information that is several grades higher than merely “sensitive”.
Which brings me back to the ThinkPad. It has been under a pile of books since the start of the pandemic, but it’s still half-decent by modern standards: an X1 Carbon with an SSD and a valid Windows 10 licence. I’d been looking at it while pursuing one of my current obsessions, that being the age of our storage and what we ought to be doing to keep things safe from data loss.
X1 ThinkPads represent a gap in my skillset, as unlike earlier ThinkPads they aren’t built for easy maintenance or upgrades. Seven screws keep you outside the casing, and you need to thoroughly understand the various designations and limitations of the Lenovo parts marking and ordering processes before you go diving into a refurbishment or expansion process. I suppose I ought not to gripe: at least it’s possible to reach the various parts of such a system.
Before I went sprucing up the machine, I gave it a quick test drive. The oddest behaviour was that the keyboard nipple thing worked fine, but the trackpad didn’t. I’d put it away in fresh condition, and had no prior experience as an owner of over 20 ThinkPads that pointed to dead trackpads as a result of a long hibernation.
The issue, in the end, was updates. I have a very fast internet connection; this is the first time it’s maxed out a machine over my Wi-Fi router, which is remarkably old and noticeably slow. It may be that the trackpad driver had some component that had been declared untrustworthy in the past few years of its incarceration, but I am convinced it was actually purely a problem with newly identified, not even slightly hidden, update process files.
If there is an immediate lesson to learn from the drawn-out trials and tribulations of my friend, it is that the recent more widespread adoption of immovable, immutable “security procedures” is putting the burden on the wrong part of the situation. For my friend, standing in the street clutching a set of house keys which at that moment represented the only possession she had that had not been burnt to a blackened crisp by a roaring inferno trapped inside an implacable, sealed concrete box, all the hours of being on hold and “referred to our security team” came to represent much the most agonisingly painful and downright stupid part of the whole sorry business.
Once I had sat down and thought about her situation, I took my Lumix and a bright desk lamp and took a whole lot of pictures of every vital document I could find, transferring them to a tiny little metal-clad USB key that nestles in the thicket of bike lock keys on my main keyring. Unlike the shenanigans with reviving laptops and handling the security issues she’s facing, this lesson doesn’t come from long ago: rather, it comes from just ten days before I sat down to write this column.
“I am convinced it was purely a problem with newly identified update process files”