A little over two weeks ago, Lenovo sent me a couple of loaner laptops. To be more specific, their largesse included one each X1 Carbon Extreme and an X380 Yoga. Today, I’m going to explain some recent experiences with the X1. And when I say this X1 Carbon Extreme 6-core really flies, I’m not kidding. But first, some speeds and feeds, courtesy of Piriform’s (free) Speccy tool:
For those in the know, these are some pretty impressive components. Let me explain…
Killer Components Explain Why X1 Carbon Extreme 6-Core Really Flies
The X1 Carbon I received is very well equipped. It’s got a 6-core i7-8550H (Coffee Lake/8th generation) CPU, 32 GB of DDR4-2666 RAM, Intel UHD 630 and Nvidia GTX-1050 Ti graphics, and two fast (960-equivalent) Samsung OEM NVMe drivers (1 TB and 512 GB units). Simply put, it runs faster than my current production PC. For the record, that desktop features an Asrock Z170 Extreme 7+ motherboard, an i7-6700 (Skylake/6th generation) CPU, 32 GB DDR4-2132 RAM, and a Samsung 950 Pro 512 GB SSD.
I’ve tested a lot of laptops. Most notably I chewed my way through many dozens of machines writing reviews for Tom’s Hardware during the 2000s. This is my first time to encounter a compact, high-end current-generation laptop that outperforms my production PC. Lenovo will release 9th-generation models later this year. They should improve upon the already-impressive stats and behavior of the X1 Carbon.
I’m not ready to abandon desktop technology in favor of laptops, though. I need the extra storage (I’ve got 10 drives currently connected to my production desktop, ranging in size from 128 MB SSDs to 4 TB conventional HDs, and a total of 13.5 TB). I also use a higher-end graphics card — an MSI Nvidia GTX 1070 with 8 GB of DDR5 VRAM — to drive a couple of 4K 27″ monitors to give me a lot of screen real estate while I’m working.
This Time, Spending More Means Getting More
But wow! The X1 Carbon Extreme with the high-end CPU and the next-to-highest-RAM configuration (it will actually accommodate 64 GB max) is a great performer. My son is using it as his preferred homework PC, and I’ve taken it on the road for a couple of legal engagements during which it has both shone and flown. If you’re looking for a higher-end work laptop to take on the road, and don’t mind spending up to $2,700-2,800, this machine will do you proud. If it lasts like my previous Lenovo laptop duo has done — I bought a T520 and an X220 Tablet back in 2013 and they’re both still solidly in service — that substantial investment will repay itself several times over before you need to move up to a newer model.
It’s amazing. Highly recommended!
Last September, I reported here that MS had announced plans to “deprecate” the venerable Disk Cleanup utility. That post was aptly named “Bye Bye Disk Cleanup?” Among the issues I raised therein was the threat of loss of command-line access to disk cleanup capabilities. This morning, I saw a recent post from Martin Brinkmann at Ghacks.net that helped to allay that very concern. It is entitled “Comet is an open source Windows Disk Cleanup clone.” This item tells a nice story about a potential stand-in that works with equal facility in the Windows GUI and at the command line. That program is named Comet, and it seems that Comet offers interesting Disk Cleanup alternative.
If Comet Offers Interesting Disk Cleanup Alternative, Then What?
To download this program, when you visit the project’s Github page, click that page’s Releases tab. Then, download a Release-<date>.zip file. Be sure to grab the latest release, and unzip it into a directory of your choosing. If you download the ZIP from the home page, you’ll get a source code hierarchy instead (which you could compile, if you wanted to, but why bother when the .exe itself is readily available?)
Comet is portable, so you can run it from anywhere, including a USB stick, if you like.
[Click image for full-sized view.]
Working with Comet right now is exactly like working with Disk Cleanup. It seems to be a nearly indistinguishable facsimile of cleanmgr.exe (aka Disk Cleanup). The developer does allow the app window to be resized, unlike the original, so I’ve already tweeted him the suggestion that he show more checkbox items by default when that window is expanded. Right now, the “Description” pane grows with the expansion. This doesn’t really do much for users, which is why suggested showing more checkbox items instead. To wit:
If I can grow the app window, as this screencap shows, why not grow the checkbox item display pane instead of the Description pane?
Nevertheless, this is a great little tool. And now, should Microsoft retire Disk Cleanup, looks like there’ll be a worthwhile replacement. I’m pleased and relieved. You should be, too.
AMAZING NOTE Added 4/20/2019: Feature Provided
I tweeted the developer of the Comet program yesterday with the foregoing suggestion. It’s already implemented. The program name has also changed to Managed Disk Cleanup, and the exe file is now named mdiskclean.exe. Check out this screencap!
Now THAT’s what I call a quick and very helpful developer response. Yowza!
Recently, working on a legal project I found myself having to explain timestamps for computer files. That’s when I stumbled across Joakim Shicht’s excellent but cryptic Master File Table (MFT) Record decoding tool. And while my particular focus was on file timestamps, a quick look at the help file for this command shows that it can do a lot more than display file metadata. In addition, it can dig into and display many aspects of the MFT itself for any NTFS volume. If this is something of interest to you, download this tool from Github at jschict/MftRcrd. Here’s what it shows about timestamps when I look at an older install.wim file in a temp directory, for example:
In addition to the more usual create and modifed timestamps, you also get MFT entry modified and file last access timestamps, too. Sometimes, when proving dates, all of this info is important.
MFTRCRD64 Shows More NTFS Timestamps … Plus!
Shicht built a very nice interrogation tool for NTFS file metadata (or its equivalent as stored in the MFT), and for on-disk MFT structures themselves. The best way to learn about the command (its readme.txt file is empty: 0 length, that is) is to use the help command — namely:
Here’s what that output looks like:
The help file has lots of good examples to guide you into the program’s inner workings. It’s the best way to explore what it can tod for you.
[Click image for full-sized view.]
More MFT Information
To start learning more about the Master File Table (MFT), check out this MS Windows Dev Center article entitled “Master File Table.” NFTS.com is another great source of information, too. Their MFT section is definitely worth reading as well. The NTFS section in Part 2 of Windows Internals (by Mark Russinovich and others) is also worth a look-see (I’ve got the 6th edition, but the 7th edition is out now, too).
In perusing my usual newsfeeds this morning, I saw what looked like an interesting story. It says something like “Use the MCT to Get Win10 May 2019 Update without Insider signup.” (Check that link to get the full title, please.) But the story promises more than it actually delivers. Yes, it turns out there’s a download link to a file named MediaCreationTool1903.exe. But if you actually grab that file, and start looking at what’s inside, you’ll see that MS hasn’t yet made the right behind-the-scenes connections. It’s actually the same ISO you’ll get if you visit the Download Windows 10 page at Microsoft (17763.379, to be more precise).
The filename looks tantalizing, but there’s nothing new under that hood . . . yet!
Why Say MCT1903 Misnomer Not Available?
More than mildly curious, I downloaded the MediaCreationTool1903.exe file. I took the option of saving the files it proffers in ISO form. I named that ISO Windows1903MCT.iso just to make it easy to identify. But after mounting that ISO to drive N:, I ran DISM against the install.esd it includes in its /Sources folder. Index 6 covers Windows 10 Pro, and here’s what I got in response to the DISM command shown:
The MCT may be labeled 1903, but the contents are indisputably 1809. Sigh.
Is this a Put-up Job?
I imagine some enterprising Windows-head found this file by presuming it existed, supplying the URL (the same one linked in paragraph 1), and grabbing same. But MS has obviously not yet made the right connections for this tool to grab the 1903 release. The obvious reason why is because it’s not released yet, so those connections haven’t yet been made. So no, it’s not a put-up job. It’s just not ready for prime-time/real use just yet. The existence of the file is simply indicative that someday in the near future (before the end of May) it will actually work the way it’s should. But in the meantime, steer clear.
A funny thing happened when I upgraded my Surface Pro 3 to the latest Release Preview. I’m talking Build 18362.53, otherwise known as 1903 aka May 2019 Update. Before the upgrade, the PC saw its SDXC card and contents without issue. After the upgrade, nada. Before the upgrade, DevMgr saw something named “Richoh SD Disk Device.” After the upgrade only a generic “SD Disk Device” appears there, and it doesn’t work. I didn’t see this myself though. I got a private message from TenForums user StanP50 that asked if I could access my SDXC card under the latest build. His wasn’t working. So I checked mine, and sure enough: it wasn’t working either. And that’s what led me to the immortal question “Dude, where is my SDXC drive?”
Before the upgrade, SDXC worked fine; after the upgrade, its was invisible in Explorer and inaccessible in Disk Management.
Where is my SDXC drive, and how do I get it back?
Looks like we’ve got a specific issue here on my Surface Pro 3 (SP3). My other Release Preview laptop, a Lenovo X220 Tablet, also upgraded to 18362.53, sees its SDXC card just fine. I rolled back to the preceding version 17763.404 on the SP3, and presto! Now it sees and accesses its SDXC media correctly, too. Sigh.
I’ve reported this to the Feedback Hub as “1903 knocks out SDXC card.” If you’ve got a Surface Pro 3 with an SDXC card installed that’s running 1903, you might want to check to see if you have the same problem, too. If so, please upvote that thread.
Demonstrating the Value of Release Preview
This is just the kind of thing that a Release Preview is supposed to flush out of the woodwork. And with the actual, full-blown public release still perhaps as many as seven weeks out, MS has time to find and fix what testers report. Though it’s vexing to lose access to a device, it’s better that people who volunteer to test the software prior to public release do it, instead of the unwashed masses. Most of us testers expect a few rough spots to show themselves, and know how to report and deal with them. I have a feeling this is just one glitch among many that will be found and fixed before the end of May comes around. Relax! The system is working as intended. To me, that’s actually reassuring.
Last Friday, a couple of Lenovo loaner laptops showed up at my office. Both include 8th Generation (formerly, Coffee Lake) CPUs and Samsung OEM NVMe SSDs. As I was perusing the TenForums threads yesterday, I noticed a new version of the Samsung NVMe drivers. But my drive’s model number is MZVLB1T0HALR. It doesn’t appear in the list of supported drives on the Samsung site, either (see screencap below). That raised this very interesting question: are Samsung consumer drivers OEM friendly? I decided to find out.
Lots of familiar product names here, but they’re all consumer/retail products. Will they work for my OEM products, too?
[Click image for full-sized view; Source.]
The drives named on the preceding snip from the Samsung SSD downloads page are NVMe 970 Pro, 970 EVO, 970 EVO Plus, 960 Pro, 960 EVO and 950 Pro. My OEM NMVe SSDs are best described as “recent vintage, but none of the preceding.” This adds a certain air of mystery, or perhaps confusion, to finding out if they’ll work on those new Lenovo laptops I’ve recently been loaned.
Finding Out if Samsung Consumer Drivers OEM Friendly
Given that on both machines, I was monkeying with device drivers for their boot/system disks, I decided to take some precautions. Fortunately they turned out to be unnecessary. But here’s what I did to prepare for possible trouble, up to and including a non-bootable system:
1. I made an image backup on an external USB drive using Macrium Reflect (MR).
2. I used MR to create “Rescue Media” for each PC (a standalone bootable WinPE runtime that can read and restore MR backups).
3. I made sure I could boot to the Rescue Media on each machine, and was able to “see” the image backup device in its MR runtime.
3. I installed the new driver on my first loaner (X1 Carbon Extreme), crossed my fingers, and rebooted.
If the machine had failed to boot, I would have resorted to the Rescue Media and used it to put things back the way they were before I started messing with them. Fortunately for me (and for others who may have laptops with newish Samsung OEM drives) it worked like a champ. Here’s what I see in DevMgr on the X380 (the X1 Carbon has two NVMe drives, so it has two driver entries instead of just one as shown here):
I was mighty relieved when the X1 Carbon rebooted successfully.
Alas because there are so many (and poorly documented) Samsung NVMe SSDs out there, you can’t know if this driver will work for you unless you try. And if you do, you’d better take precautions beforehand, just like I did. That way, if you get bitten, you will still be able to restore your PC to working condition. Note also, the 950 Pro released in September 2015 (equivalent OEM model SM951). I wouldn’t try installing this driver on anything older than that, either, if I were you. ‘Nuff said!
With the release of 1903, aka Windows 10 May 2019 Update, coming soon the Insider Preview program is going through some changes. A bit of “special maneuvering” lies ahead. That is, upcoming Insider Preview changes 2020 release access methods . Those who want to stick with a true Fast Ring release — which becomes 19H2 as soon as the Windows 10 May 2019 Update arrrives — should switch to the Slow ring this week. (That means sometime between today, April 8, and Friday, April 12.) Those who want to stay one additional increment in the release cycle — namely, 20H1 — should stay in the Fast or Skipahead rings. These will merge into a single group once the next feature update becomes available.
For the next couple of weeks, and possibly longer, the Slow Ring is for checking the Release Preview, and the Fast and Skip ahead Rings are for target 20H1 builds.
Why Make Upcoming Insider Preview Changes 2020 Release Access Anyway?
I guess this is how Microsoft is reintroducing a meaningful Release Preview mechanism just before the May 2019 Update builds a full head of steam. This strategy does seem to ensure that lots of Insiders will be giving that release a serious once-over before it starts trickling into wider distribution. Given the results of skipping this phase for 1809 and the troubles that followed, I’d say MS is working diligently to implement hard lessons learned. They’re definitely NOT skipping Release Preview for this next Feature Upgrade, and this temporary changeover appears designed to make sure that the near-final bits get a maximum once-over.
FWIW, I’ve set those test machines I want to keep on leading/bleeding edge builds to Skip, and those on which I want to check the Release Preview and then go back to Fast Ring later, to Slow. You can do as you please, but hopefully, you now have some idea what that might be!
Those who want to see what Brandon LeBlanc had to say on this topic last Friday (April 5) should check out this Windows Insider blog post. According to that same post, MS “will begin releasing 19H2 bits to Insiders later this spring.” That means the Fast Ring is taking a bit of a break for a while, and will probably start back up sometime after the May 2019 Update gets going. That’s my best guess right now anyway. So, for the time being, staying Fast means going slow. And staying Fast, really means Skipahead. But this is just temporary until the dust settles from the upcoming Feature upgrade. Stay tuned and I’ll tell you when Fast really means Fast, Slow means Slow, and a difference between Fast and Skipahead is re-established. Got that? I sure hope so!
The last two Win10 feature updates (1803 and 1809) have had problems. There’s been lots of grousing from business users about updates, too. Finally, Microsoft is changing its stance on pushing updates. Hooray! In a post to Windows Blogs today (April 4), Mike Fortin (Corporate VP, Windows) announced a new approach. I take from this material the idea that MS backs off forcing updates through WU. Here’s the relevant paragraph, in all its glory:
In previous Windows 10 feature update rollouts, the update installation was automatically initiated on a device once our data gave us confidence that device would have a great update experience. Beginning with the Windows 10 May 2019 Update, users will be more in control of initiating the feature OS update. We will provide notification that an update is available and recommended based on our data, but it will be largely up to the user to initiate when the update occurs. When Windows 10 devices are at, or will soon reach, end of service, Windows update will continue to automatically initiate a feature update; keeping machines supported and receiving monthly updates is critical to device security and ecosystem health. We are adding new features that will empower users with control and transparency around when updates are installed. In fact, all customers will now have the ability to explicitly choose if they want to update their device when they “check for updates” or to pause updates for up to 35 days.
Separate controls for Feature Updates may help those who want security and quality updates, but no upgrade yet, get what they want.
[Click image for full-sized view. Source: Fortin Blog post.]
Why Say: MS Backs Off Forcing Updates?
One single line above gets my attention. It reads: “We will provide notification that an update is available and recommended based on our data, but it will be largely up to the user to initiate when the update occurs.” Two other items are also noteworthy. First, there’s a statement that “all customers” can explicitly choose to update or not. Second, they can pause updates for up to 35 days. According to Paul Thurrott, 35 days means deferring updates 7 days at a time, 5 times in a row.
What About the Next Feature Update?
It’s been renamed to the May 2019 Update in Mr. Fortin’s post. He also asserts that MS “will increase the amount of time the May 2019 Update spends in the Release Preview phase. . .” MS plans to “proactively obtain more early feedback about this release.” Good idea, especially after they skipped this step with the much-maligned 1809 Feature Update. Those in the Insider Preview/Release Preview group will get an advance look at this release starting next week. Others will be able to use “check for updates” in WU to request the new release sooner. Interestingly, customers running Windows versions at or near end of support will also get the new release pushed to them.
More Update Controls, Yes Sir!
When the new release hits it will have new and improved update controls. A new “Download and install now” option for Feature Updates will appear in versions 1803 and 1809. No doubt, that change will come through a cumulative update or a servicing stack update by late May as well. The screen cap for this blog post (clipped from the original MS post) shows what this will look like. Users will be able to use “Check for updates” without causing the Feature Update to be forced upon them. Good move, MS.
Just yesterday, MS released a new cumulative update (CU) — namely, KB4490481. For the first time in my experience, Win10 KB4490481 leaves 6 reclaimable packages behind. What does this mean? After you install this update, run
DISM /online /cleanup-image /analyzecomponentstore You’ll see something that looks like this (captured inside a PowerShell administrator session):
Notice the line in the command output near the bottom that reads “Number of reclaimable packages: 6.” In my experience, this sets a new record for detritus in the wake of a Windows 10 CU.
Win10 KB4490481 Leaves 6 Reclaimable Packages Behind. So What?
As I recite in my previous blog post, cleanup using
DISM /online /cleanup-image /startcomponentcleanup after this CU can pay big dividends. Notice the size of the item in the preceding screen capture: Backups and Disable Features. At 8.94 GB, all that goes bye-bye after the cleanup. My typical cleanup results came in around 9.5 GB, so there’s another 0.54 GB that gets whisked away from other component store nooks and crannies, too.
As post-CU clean-ups go, this one’s a biggie. In fact, it’s the biggest one I can ever remember seeing. Especially for those running Win10 1809 on small-footprint devices (tablets or laptops with limited storage of 32 or 64 GB) this maneuver seems more mandatory than optional. But even for those with system/boot SSDs of 512 GB or larger, a 9+ GB cleanup still remains significant. And, should you run into the same error I encountered when working this through on the Release Preview before it hit general distribution, my previous blog post explains how to fix that, too. Alas, though, if you’re updating only from 17763.379 to 17763.404, you’ll find only 1 reclaimable package when you run /AnalyzeComponentStore. This will recover upwards of 1.6 GB instead (because there are many fewer packages involved). YMMV, as they say on the Internet.
If all this talk about component store cleanup piques your interest — and I hope it does — here’s a great resource for further exploration. Shawn Brink over at TenForums offers a great tutorial on this stuff. Prosaically enough, it’s entitled “Clean Up Component Store (WinSxS folder) in Windows 10.” It goes into and illustrates all the relevant DISM commands in detail. It’s worth a read-through. You can even use it as a step-by-step guide to work through these commands on your own Win10 PCs. Check it out!
Generally speaking, whenever one installs a Win10 cumulative update (CU), it raises the possibility that component store cleanup should follow. How do you find out if cleanup is needed? The command
DISM /Online /Cleanup-Image /AnalyzeComponentStore when run, will recommend for or against cleanup. Lately, I’ve observed that trying to run that cleanup immediately after the restart that CU install requires doesn’t always work. Generally, a second reboot fixes DISM StartComponentCleanup nicely.
In fact, I’ll show a sequence of PowerShell screencaps that show this in action. [WARNING! Completing this cleanup often takes a long time — over a half hour on my Surface Pro 3, for example.]
How to Tell If a Second Reboot Fixes DISM StartComponentCleanup
You’ll know if you need to try a second reboot because of the error message that DISM produces for that particular command. It appears in the following screenshot:
Notice the 6824 error at bottom: “The operation cannot be performed because another transaction is depending on that fact that this property will not change.”
[Click image for full-sized view.]
Apparently, a Reboot Clears the Pending Mystery Transaction
MS Docs labels the 6824 error code as ERROR_CANT_BREAK_TRANSACTIONAL_DEPENDENCY. As far as I can tell, it means that some other OS transaction is pending. Before DISM StartComponentCleanup can do its thing, that transaction must complete. I can’t yet identify that other pending transaction. But it’s pretty clear that a second reboot handles and clears it. The second reboot lets the previously failed DISM command run unimpeded.
If you ever find yourself in this boat after installing a CU, try another reboot. It’s worked for me every time I’ve gotten the 6824 error code instead of package cleanup. It should probably work for you, too.
Here’s where I wound up with my successful cleanup, after the second reboot. Please note that after the DISM command ran for 30 minutes it got stuck on 94% complete. So I closed the PowerShell window, opened it again, and re-ran the same command. What you see below shows the strange results that ended in success almost immediately. I ran another /AnalyzeComponentStore command to get “post-cleanup” sizes. The component store dropped from 15.93 GB to 6.52 GB (HUGE: 9.42 GB), with attendant size reductions in actual size, primarily from backups and disabled features. It’s pretty unusual to see six (6) reclaimable packages after a CU, so I expected — and got — significant cleanup. Good stuff!
[Click image for full-sized view.]