Category Archives: Windows 11

Lenovo Q3 Results Support Refresh Year Notions

The world’s biggest PC maker — Lenovo, that is — just reported results for the third quarter of its fiscal year (ended Dec 31). It shows approximate growth in revenues and profits over Q3 for the previous fiscal year. One phrase from the report (PDF) caught my eye: “Commercial sales benefited from the Windows 11 refresh, with premium workstation sales spearheading demand recovery…” Hmm, could it be possible that these Lenovo Q3 results support “refresh year” notions for 2025? You bet!

How Lenovo Q3 Results Support Refresh Year Notions

Back on January 6 I posted about the MS supposition that AI additions to Windows 11 plus Copilot+ PCs could turn 2025 into The Year of the Windows 11 Refresh (that’s a link to their blog on this topic as well as a good summary). As the biggest player in the PC market, Lenovo’s latest quarterly numbers certainly plays into this picture. And it does so in a way that speaks for the “refresh year” idea, rather than against it. Could MS actually have a clue?

I cribbed the lead-in graphic for this story from Paul Thurrott’s coverage of this topic: Lenovo Revenues Jump 20 Percent to $18.8 Billion. It shows how the number have fared over the past 5 quarters, with a dip from Q1 to Q2 in that series, but steady growth and recovery since then.

What Else Could Speak to Refresh?

It is interesting to see how next-ranked PC players numbers either further support this notion, or call it into possible question. Copilot says that means HP, Dell and Asus (Apple holds spot#4, but I’m pretty sure they’re not much into playing the Windows 11 refresh game).

HP’s Q4 24 results show a 1.7% jump YoY (nowhere near Lenovo’s ~20%), but they do cite “steady progress in Personal Systems and Print.” Dell’s overall revenues and earnings declined over 2024, as did the number of units it shipped that year (39.1M vs. 61.8M for Lenovo, 53M for HP, and 17.9M for Asus). Asus was up 8.8% YoY in PC sales, and their strong showing in PC sales helped contribute to their success.

Nothing Entirely Clear Yet, Yea or Nay

Lenovo’s results are the only ones that mention the refresh phenomenon explicitly. But if it pans out further, I expect we’ll hear more from other OEMs, too. Stay tuned: I’ll keep you posted.

 

Facebooklinkedin
Facebooklinkedin

MS Seemingly Drops Intel Gen7-10 24H2 Support

Whoa! Maybe even “Double Whoa!!” Look closely at the recently updated Microsoft Learn Windows Hardware Developer document Windows 11 Version 24H2 supported Intel processors. Careful examination shows that MS seemingly drops Intel Gen7-10 24H2 support. That’s right: everything from Gen 7 (Kaby Lake; 2016 mobile/2017 desktop) to Gen 10 (Comet Lake; 2017 for both mobile and desktop) is absent from that list. I’m concerned, and so are lots of other industry followers and reports (e.g. WinAero, Tom’s Hardware, Eleven Forum, and so forth). Can this be true?

Really!? MS Seemingly Drops Intel Gen7-10 24H2 Support

Initially, I wondered if this could be an error or oversight. But apparently, it’s a deliberate strategy aimed at OEMs. Indeed, a Windows Latest item dated today (2/17/2025) explicitly debunks this notion: No, Microsoft is NOT dropping Windows 11 support for Intel 8th, 9th, and 10th Gen chips. Though the absence of these items prompted plenty of speculation that Gen 7-10 were falling off the 24H2 table, here’s what that item states:

…first…Microsoft has renamed the document to mention the Windows 11 24H2 release. Second, the list of supported processors does not include “8th gen, 9th gen, and 10th gen Intel” chips. This led some people to believe that older Intel chips are no longer officially supported for “Windows 11 24H2.”

In response to this belief, Windows Latest asked MS directly and got this added clarification:

In a statement to Windows Latest, Microsoft confirmed that Windows 11 hardware requirements hadn’t changed since 2021.

I’ll also observe that the first paragraph of this Learn item states “…released and future generations of processors which meet the same principles will be considered as supported, even if not explicitly listed.” Guess what? That includes the “missing” Intel Gen7-10 CPUs, dear readers.

Windows 11 for AI vs. Other Flavors

Apparently MS is steering OEMs toward Intel CPUs that provide the necessary NPU and other items necessary to qualify for Copilot+ classification. It’s another logical, if vexing, consequence of the “Year of the Refresh” that MS is promoting for OEMs that want to support 24H2 fully and completely. Go figure: it seems to be something of a tempest in a teapot!

Facebooklinkedin
Facebooklinkedin

RDC vs. Remote Desktop

I make remote connections to Windows PCs all the time, every day. I often switch between the Remote Desktop  Connection (RDC, aka mstsc.exe) and the Remote Desktop app (9WZDNCRFJ3PS in the MS Store). Lately, I’ve noticed that the .exe is prey to a hiccup to which the app is not — namely, RDC will often hang at the lock screen with spinning balls frozen when I start a remote session. Remote Desktop never does this. Because I know RDC better than Remote Desktop I used to prefer it. Because I favor speedy in-and-out over redoing my link I’m now leaning toward the latter. Thus, in my recent estimation of RDC vs. Remote Desktop, the app is gaining favor.

More Differences in RDC vs. Remote Desktop

This got me to wondering about other differences between the older exe and the newer UWP app. Looks like Remote Desktop can do other stuff that RDC cannot, too, including:

  • Auto updates through the MS Store (Winget handles mstsc.exe)
  • Modern UWP app interface with thumbnails and minimal controls (Full-Screen and Disconnect only)
  • Access a complete remote desktop or access one remote app without running a complete remote desktop
  • Works across MacOS, iOS/iPadOS, Android, Chrome and Web browsers (IDKICDT)
  • Multi-monitor support lets Remote Desktop map multiple monitors from remote client to host desktop
  • Works with Azure Virtual Desktop and Windows 365 Cloud

In some situations, I can see where single-app remoting could be good. I also like support for multiple client OSes and monitors. I wish I had the ability to try out the cloud capabilities, too. Sounds like fun.

Maybe It’s Time to Join the 21st Century?

I’m thinking I should be using Remote Desktop more than RDC. I think I’ll try it for a while and see how it goes. It could be that some of my issues with VMs might also be MIA in the newer app. Let’s find out!

Facebooklinkedin
Facebooklinkedin

Apps > Resume Works Between WinPCs

In reading this morning about how Build 27788 enables an Apple Hand-off like experience, I looked around my mini-fleet of PCs for Apps > Resume. It’s not only present in that build, it’s also in the current production build (26100.3037), too. In fact, the only build I’m running where it’s MIA is Beta (26120.3073). I was also able to observe that Settings > Apps > Resume works between WinPCs, as well as from phones to PCs and vice-versa. Good stuff.

OneDrive Is Why Apps > Resume Works Between WinPCs

If the same MSA is open on both desktops for a pair of Windows 11 PCs, OneDrive and its synching behaviors make the same files available in the primary user account folders (e.g. Desktop, Documents and Pictures). That’s the mechanism that lets you ping-pong working on the same file across two or more PCs (and other devices as well). In my case, these files show up in a OneDrive (cloud icon) folder named “Ed – Personal” like so:

I used text for a reply to an AskWoody column (boxed item) as my example.

To me, this makes OneDrive file sharing more user-friendly. I don’t just want to be able to open and use files shared in the cloud. I want to be able to pick up where I left off. That’s what made Apple’s Hand-off initially compelling, and what explains the motivation for Microsoft’s implementation in the form of Apps > Resume. I can — and will — use this!

Facebooklinkedin
Facebooklinkedin

Long Hard 27788 Upgrade Road

Whoa! In the realm of Windows Insider Preview upgrades, sometimes you win and sometimes you lose. This time around — starting from Build 27783 — I found myself on a long, hard 27788 upgrade road for this latest Canary Channel version. When I tell you what happened, and how I surmounted the obstacles on that path, you may be able to save yourself some unnecessary time and effort.

To begin with, what I lost on this upgrade road was time. I spent most of yesterday afternoon going through various motions to try to get the Insider Preview for 27788 and a companion KB5053390 (CU for .NET Framework…) up and running. All such attempts, alas, proved fruitless.

Traversing That Long Hard 27788 Upgrade Road

Getting to the state depicted in the lead-in graphic — showing that the Lenovo ThinkPad X12 Hybrid Tablet is up-to-date in WU and running Build 27788 in Winver — took some doing and some time. In fact, it wasn’t until I read about a workaround in an ElevenForum post from Russian user @Dronix that I made any real headway. Along the way, each update/upgrade cycle took about 1:10 (70 minutes) to work through.

I’ll deliver a recitation of what I tried that didn’t help my problems. I am also speculating when I say this, but I believe one can’t upgrade to 27788 until KB5053390 for .NET completes successfully. There may be dependencies in the upgrade that need the previous CU to complete successfully. And indeed, once I did that, the upgrade went through without further issues.

Here’s my list of failed strategies:
1. Simply retry the failed KB or upgrade item.
2. Run Eleven Forum’s Reset_Reregister_Windows_
Update_Components.bat from this Reset WU tutorial
3. Run the built-in WU Troubleshooter

What Worked: DISM-GUI 1.3.1.02

Turns out there’s a German software tool named DISM-GUI that lets one install KB .cab files from failed installations. You have to know the name (a partial name will do) of that file to provide it as a target. The afore-linked Eleven Forum thread identifies it, and it includes the KB number as a sub-string. Using Voidtools Everything, I found it immediately (search string *KB5053390*.cab). For the record, the filename is:

Windows11.0-KB5053390-x64-NDP481.cab

Click on the box in DISM-GUI that reads “CAB Install” (lower left) and the program will prompt for the file location. You can get that from Everything, then left-shift click and use the “Copy as Path” option (you’ll have to delete opening and closing quote marks).

This opens a Command Prompt session and uses DISM to install the package for you. Unlike the WU driver install, this actually works. And it takes less than two minutes to complete. Then, when you’ve got the CU installed, the follow-up upgrade to 27788 works, too.

TLDR: Possible Problems with 27788 Are Fixable

If you read through the whole Eleven Forum thread about 27788, some posters were able to install KB5053390 and the 27788 upgrade without any difficulties. Numerous others — myself included– got exactly nowhere until they used DISM-GUI to get over the KB5053390 hump.

Should you find yourself in the same boat, you can go straight to the workaround using that tool, and avoid the hours and hours of thrashing about I went through yesterday. Why not learn from my experience, instead of repeating that misery?

Providing such info explains why I write this blog. It also explains why I expect lifetime employment doing that kind of thing here in Windows-World. It’s always something…

But Wait! There’s More… (Added Jan 7)

When I logged into the X380 and the X12 this morning, KB5053390 again showed up as needed. And again, a regular WU install failed. So this time, I fired off DISM-GUI taking the left-click “Run as administrator…” option. Apparently that did the trick. Here are some screencaps along the way:

Between the 2nd and 3rd screencap, I ran DISM-GUI again (as admin) and it showed a successful conclusion at the command line, then reboot with successful update there after). Once I rebooted the system and it worked through the rest of the process, I got the 3rd figure above from WU. Gadzooks! I hope it’s finally over…

 

Facebooklinkedin
Facebooklinkedin

Decoding Builds Requires Keen Attention

Ha! I have to laugh at myself. I just tried to update my Beta Channel Insider Preview test PC (one of my two aging X380 Yoga laptops) for no good reason. Or, perhaps it was for a bad reason — namely, I read about a new beta with a lesser build number of 4870. It wasn’t until I got further into the story that I figured out the update was for version 23H2. I’m running 24H2 so my minor build number is properly at 3073 right now (as you see in the lead-in screencap). Its higher major number: 26120 vs 22635 reminds me that decoding builds requires keen attention. Oops!

Truly, Decoding Builds Requires Keen Attention

What got me this time was that I looked only at the digits after the period, rather than checking both sides. If I’d really thought about what I was seeing, it would have instantly been clear. Because I’m running 24H2, perforce its major build number (26120) is greater than the same number for 23H2 (22635). Thus, even though the minor build number is higher (4870 vs. 3073) it doesn’t signify to my test PC because it’s not the same thing.

There’s never any shortage of confusion around here at Chez Tittel for all kinds of reasons. Alas, today’s ration was self-induced. But it did give me chuckle and remind me that it’s always important to put news of changes and updates into their complete context. Other-wise, who knows what one might expect or believe? Words to live by, not just here in Windows-World but in the wider world as well.

 

Facebooklinkedin
Facebooklinkedin

Windows.old Required For Uninstall Window Access

Here’s an interesting Windows gotcha that affects both Windows 10 and 11. There’s an interval setting value in these OSes that controls how long Windows.old stays on your system disk before it gets deleted. It’s called the “OS uninstall window” and it’s set to 10 days by default, though any value from 2 through 60 (days) is legal. That said, you can only see and manipulate this value if Windows.old is present on the target system. That’s what the title means when it says “Windows.old required for uninstall window access.”

Why Is Windows.old Required For Uninstall Window Access?

God only knows (and possibly a few Microsoft OS engineers). That’s just the way it works. Indeed the relevant MS Learn article doesn’t comment on the why; it only documents the how. I had to go to Google to get an explanation for what you see in the lead-in graphic — namely, that when you run the DISM command that tells you the current uninstall window value for Windows.old, it throws an error if there’s no Windows.old present on your system for it to inspect. Weird.

The best explanation I found is at SuperUser.com. The short answer to “Why an error and not a number?” reads simply “No, you are too late.” That is, once Windows.old is removed, the command no longer works the way one might presume it should. In short, if no Windows.old is present, the OSUninstallWindow value is not available, nor can it be reset. Again: Weird.

Even weirder: you’d think there would be a registry value to control this. But alas, as Copilot informs me and my truth-check research confirms “There isn’t a specific registry value in Windows 10 or 11 that directly controls the OSUninstallWindow value.” It’s just another Windows oddity for the ages. Now I know (and now, you do, too). Cheers!

Facebooklinkedin
Facebooklinkedin

DevHome App Faces May Retirement

It was both fascinating and a little disheartening to learn yesterday that the Microsoft DevHome app faces May retirement. I have come to really, really appreciate DevHome for two reasons — namely:

1. It supports easy creation and management of ReFS drives in both Windows 10 and 11.
2. It demonstrates that MS can indeed fully automate the creation of Windows Hyper-V VMs, even though Hyper-V Manager still includes glitches one must work around to bring up such VMs manually.

Initially, I learned about this yesterday from long-time Window developer and watchdog Rafael Rivera via X (@WithinRafael). But this morning, Sergey Tkachenko posted an item at WinAero that shows a DevHome notification to the same effect.

Decoding What DevHome App Faces May Retirement Means

I’ll be darned if I can find the notification that Sergey displays in the WinAero post (and which Rafael included in his initial X info). I made sure Microsoft.DevHome (the app’s WinGet ID) was up-to-date. As you can see in the lead-in graphic, I even uninstalled, then reinstalled DevHome using WinGet just to make sure I wasn’t missing something. No dice.

All this said, I’m guessing that the various extensions and utilities that DevHome makes available, and its ReFS and Hyper-V VM capabilities,  will show up in other parts of Windows 11 around May as well. Sounds like a pretty good platform for 25H1 updates, in fact. What I can’t say because I don’t know is if MS will decide to do likewise for Windows 10, which currently supports DevHome (via the MS Store; it’s pre-installed in Windows 11 starting with 23H1 and thereafter).

I guess it will be interesting to see what happens with these various bits and pieces, several of which have garnered my appreciation. Plea to MS: please, please, please fix Hyper-V Manager so that it will do what DevHome currently does with panache — that is, automate VM install with the added capability to point to on-disk images or ISOs. If you want to understand how things work now, and what workarounds are necessary to bring a VM in Hyper-V Manager, see my September 24, 2024 ComputerWorld story How to set up Windows 11 Hyper-V virtual machines. It’s kind of a mess, frankly…

Facebooklinkedin
Facebooklinkedin

Backing Off Intel Graphics Driver

Ok then: I was operating under the belief that no harm should come to Lenovo PCs after updating to Intel GPU drives via DSA. Apparently I was mistaken: I’ll show evidence that for the ThinkStation P3 Ultra at least, the DSA-supplied Arc & Iris Xe drivers pose problems. Hence, I’m backing off Intel graphics driver on that machine.

Why I’m Backing Off Intel Graphics Driver

Check out the lead-in graphic. It shows Reliability Monitor with 2 crashes on both 1/22 and 1/23 for the IntelGraphicsSoftware Service process. Not good! Indeed, it causes about a 5-point drop in the reliability index in two sharp dips.

To me, that makes it pretty clear that — at least for this PC — the Intel driver is not working properly in its runtime environment. The notion that I picked up was that updating Windows 11 graphics drivers would not necessarily overwrite OEM customizations. FWIW, Copilot confirms this. But the evidence from ReliMon on the P3 is pretty hard to contest. Methinks Intel is still right to post its warning in DSA where such drivers are concerned (with a checkbox for users to explicitly opt in anyway), to wit:

And indeed, now that I’ve uninstalled that driver and reverted to a Lenovo driver dated 10/29/2024, I’ve experienced no further issues with Intel graphics stuff. That said I do have an APPCRASH for the IntelSoftwareAssetManagerServer.exe process. But a quick hop to the Intel Support Community shows that this belongs to PROSet Wireless stuff not graphics. So there’s a problem for another day!

Here in Windows World it’s always something. Lately, those “somethings” have an interesting number of elements with Intel’s name involved. Go figure…

 

 

Facebooklinkedin
Facebooklinkedin

WinGet Boosts Chrome Update Capability

Here’s an interesting item. Previously, WinGet wouldn’t update Chrome on Windows PCs where it was running. Now it will, because WinGet boosts Chrome update capability. It now runs the installer with admin privileges to overcome the maxim “don’t mess with running processes.” You can see it working in the lead-in graphic, where the text reads (in yellow):

The installer will request to run as administrator, expect a prompt.

If WinGet Boosts Chrome Update Capability, Users Benefit

This means users must still Relaunch Chrome to get the update to take, though WinGet applies the update. Previously, WinGet would just skip the whole thing. Now, the next time users open that browser, the new update will take over (or, they can manually use the Relaunch button themselves).

After WinGet does its thing, Relaunch remains required to leave running processes undisturbed.

Will Other Browser Makers Follow Suit?

Here’s a shout out to the dev teams for Edge, Mozilla/Firefox (and variations), Opera, and others. Take heed of this Chrome action and do likewise. Your users — including your truly, most fervently — will thank you.

It’s just another small step for WinGet. But it translates into a big boost for the Windows user base. Keep up the good work, people!

New PowerShell Version Out, Too…

While I’ve got your eye, a new PowerShell version — v7.5.0 — is out. It’s still new enough that WinGet won’t install it yet. If you, like me, are OCD enough to want to run it before it gets into the pipeline, download it from the assets on the Release v7.5.0 page.

Note added 15 minutes later: Nevermind, it’s already showing up in WinGet. I should’ve known @Denelon and the team wouldn’t sit on their hands here. Another attaboy for that group and the PowerShell team. Good-oh.

Here, you can see the old 7.4.6 windows left, and a new 7.5.0 window right. God: I *LOVE* Windows Terminal.

Facebooklinkedin
Facebooklinkedin