Category Archives: Windows 10

Dev Home Leaving Soon

I’ve been away on a family trip to Boston. Upon returning to my desk this morning, WinGet brought a Dev Home update to the Lenovo P16 Mobile Workstation (see lead-in graphic). “Hmmmm,” I thought, “Isn’t Dev Home leaving soon?” Indeed it is, as per MS Learn as you can see in the next screencap.

With Dev Home Leaving Soon, What’s Next?

Good question! In the afore-linked MS Learn item, MS announced last January that Dev Home would be discontinued in May, 2025. I’ve been “staying tuned” for more info since then, but so far such info has not been forthcoming.

Well: May is here and I still can’t find anything new about Dev Home’s impending retirement. Ditto for which features will be preserved and where within Windows they’ll show up. Of the tools that Dev Home brings to the Windows party, these are the ones about which I’m most curious:

1. Support for ReFS volume creation in Windows 10 and 11.
2. GitHub connection with repos for access to tools and packages.
3. The Hosts File Editor and Registry File Editor utilities.
4. Consolidated view of development projects via its dashboard.

In January, MS dropped the first shoe to warn developers (and other interested parties) that Dev Home would be yanked in May 2025. Now that it’s May, the silence while waiting for that next shoe is nearly deafening. All I can say is: “Please give us a clue or two, Microsoft: where are the best bits of Dev Home going to wind up?”

Facebooklinkedin
Facebooklinkedin

Mapping Windows Memory Usage

I like to keep an eye on how Windows is using system resources. To that end, I still use Helmut Buhler’s excellent 8GadgetPack utilities. They don’t really tell you anything that Task Manager can’t but you can keep them in view all the time, and they don’t exact much system overhead, either. For a rough and ready picture of what’s up with Windows memory (RAM), those tools (e.g. Task Manager and the CPU Monitor gadget) can tell you how much RAM is on your PC, how much is in use, and how much is free. The gadget also reports page file info: total, free, used as well. But when it comes to digging deeper into how Windows uses memory, the Sysinternals tool for mapping Windows memory usage –namely, RamMap – is what you need. Let me explain…

For Mapping Windows Memory Usage, Try RamMap

If you look at the lead-in graphic, I’ve superimposed the CPU Usage gadget (aka CPU Monitor) at center far right, with the Sysinternals RamMap tool beneath it. This pretty much shows things as they work and contrasts the minimal level of detail available from Task Manager and the Corresponding CPU gadget to the more detailed and nuanced RamMap.

TLDR version: Use Task Manager or the CPU Gadget to get a gross overview of memory and paging file stuff; use RamMap to get more details about what’s consuming memory and what state that memory is in.

In large part differences are a matter of details. Task Manager and the CPU Gadget tell you how much RAM is used (blue numbers under the Used, Free, Total column heads in white: 23.6GB) and free (~8GB). It also tells you that the page file is not in use (yellow numbers right underneath RAM entries). That’s pretty much it.

RamMap, OTOH, provides a lot more memory status categories: Active, Standby, Modified, Modified No Wire, Transition, Zeroed, Free, and Bad (you want to see THAT one in a memory map). You get a much more informed and detailed view here (and under other tabs besides “Use Counts” in the leftmost position, shows by default).

How “Used” and “Free” Fit RamMap Categories

Here’s something worth knowing: Used Memory in Task Manager/CPU Gadget combines the RamMap totals under Active, Standby and Modified. Free memory in Task Manager/CPU Gagdet combines the RamMap totals under the Zero and Free headings.

But when RamMap runs you can also see how those numbers change as processes execute, tasks get handled, services do their thing and so forth. It’s much more detailed and useful if you want that level of detail, especially if you’re hunting a memory leak of some kind.

Good stuff! Grab yourself a copy today (or you can simply run the web-based executable, to make sure you’re always using the latest and greatest version).

Facebooklinkedin
Facebooklinkedin

KB5053643 Kills Mouse, Keyboard

Last Thursday, I downloaded and installed a new Preview CU for Windows 10 — namely KB55053634. After lunch Friday, I finally got around to rebooting to complete that process. Eventually, it succeeded. But first, just to make things incredibly exciting KB5053634 kills mouse, keyboard — my vital USB peripherals — dead. Here’s the story of what I had to do to bring those devices back to life, and actually log in to Windows 10.

KB5053643 Kills Mouse, Keyboard: Now What?

Because I couldn’t get past the lock screen without a valid input device, that turned out to be a little more vexing than one might guess. So first, of course, I rebooted again. Still no joy: the keyboard didn’t respond to keypresses (a good test on my Comfort Curve 4000 is to toggle the Function Lock or Scroll Lock keys because those also toggle handy little green indicator LEDs). Nor did a mouse click open the PIN input box as usual.

So I tried again. Still no dice. Then I thought: “maybe the device needs a cold, hard boot?” That means powering off the PSU, waiting 1-2 minutes, powering back up, and pressing the power button. And indeed, that did the trick. Once I went through that maneuver, the hardware got completely reset, reinitialized and enumerated. It was enough to restore my key USB peripherals to working order.

What (Would Have Been) Next?

If the cold boot or hard boot didn’t work, I’d have had to jump into UEFI, turn off Secure Boot, and then target bootable repair media to get something running on that PC. I’ve done it many times before and will no doubt do it again. But hey: I was glad not to have to do it this time. Cold, hard boot did the trick.

Makes me feel like I dodged a bullet. Remember to give that a try if you find yourself bereft of mouse and/or keyboard after installing a Windows update or upgrade. If you’re lucky like I was, that will bring the USB drivers back into play, and let your PC get back to work. Cheers!

Facebooklinkedin
Facebooklinkedin

Skype Attains Oblivion in May 2025

First it was a swelling rumor, based on some  eagle-eyed code scanning (reported at XDA.com on Feb 27). Today, it’s established fact, as Zac Bowden at WindowsCentral updates his story with “Microsoft has confirmed that Skype is shutting down in May, with warnings now appearing within Skype apps.” MS wants everybody to move to Teams instead, and offers tools to move chats as needed. If all goes according to plan, that means Skype attains oblivion in May 2025.

Note: I’ve morphed the screencap from the afore-cited XDA story that shows the warning “Starting in May, Skype will no longer be available. Continue your calls and chats in Teams.” in text form. Reading the code can occasionally provide insights (and reveal future plans, as in this case).

After Skype Attains Oblivion in May 2025, Teams Takes Over

With a much broader range of capabilities, and options to scale audiences into the thousands, Teams can do everything Skype can, and quite a lot more. The transition is already over for some — including your humble author. Hopefully, it won’t be too difficult for those hold-outs still using Skype to switch over to Teams, too.

A Skype Timeline and Some Recollections

Skype started out on the Internet back in 2003 as a standalone service. Mostly it required establishing credit to offset upcoming charges, with occasional replenishment to keep a positive balance after that. For a while, my wife used it to interact with members of her family (who live in Germany) via voice and video on her PC. Microsoft acquired the company in 2011, and made a half-hearted attempt to build it into Windows 10 in 2015.

If memory serves, we all quit using it around that time. FaceTime on the iPhone was free and easier to use. Plus phones are better suited as communications devices than bigger laptops or deskbound desktops. I’d argue that Skype’s demise has been foreshadowed for a long, long time, and that it’s planned end-of-life-and-service date is no big surprise to anyone.

So long Skype. For my purposes, Teams already works better, and does more, than you ever did.

Note Added 2 Hrs Later

See Tom Warren’s Verge story Microsoft is shutting down Skype in favor of Teams for more useful details. The drop-dead date is reported as May 5, and further info on options open to current Skype users is provided. Apparently, he got an MS spokesperson to provide additional tidbits to help prepare the userbase for this change.

 

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

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

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

UniGetUI Beta Previews Advanced Features

Yesterday, Marti Climent — the lead developer for UniGetUI (formerly known as WinGetUI) — dropped a new beta version (3.1.6-Beta2) of the program into GitHub. This UniGetUI Beta previews advanced features planned for the next official release, when it transitions into production. Right now, it may be worth downloading and playing with to see what it can do (IMO). But the developer’s “Caution” on this release reads “Prerelease builds can be unstable and should not be used on a production environment.” There: you’ve been warned.

Exploring UniGetUI Beta Previews Advanced Features

A good way to understand what’s in 3.1.6-beta2 is to visit its release page at GitHub. There you’ll see that info listed under “General Changes.” Minutae appear in the detailed changelog (summarized under “What’s Changed” on the GitHub page). Highlights:

  • Downloads provide more detailed status info, including download and install phases
  • Multiple downloads can now proceed in parallel
  • Immediate package download triggers upon right-click of any item in the update list

I’m especially intrigued to see that UniGetUI will soon gain parallel download capability. It already launches a separate process for each download/install session but does them in series. In the next release, it will do them in bunches, instead of one at a time. Good-oh!

Production Release 3.1.5 Also Worth Trying

For those seeking a good alternative to WinGet (and 9 other package managers, including Scoop, Chocolatey, NPM, PIP, and more) UniGetUI is worth checking out in its own right. The lead-in graphic shows a recent download session on my production Windows 10 PC. There, it’s ready to download and install 6 packages (Dropbox, Chrome, Java SE SDK, PS 5.x and 7.x PSGalleries, and Snagit 2024). The whole process takes less than 10 minutes to complete.

UniGetUI should be of especial interest to organizations and development teams that use sources not available to WinGet but readily available to some or all of the other package managers mentioned in the preceding paragraph). Indeed, UniGetUI finds and updates items that WinGet at the command line does not, because of that wider range of available update sources, even on plain-vanilla Windows 10 or 11 PCs.

If you like what you see in version 3.1.15, keep your eyes out for the final cut of 3.1.16. It promises to be faster and more capable than the current production version. One more thing: if you’d rather let UniGetUI do its thing without bothering you try this super-silent command line invocation:

UniGetUI.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /NoAutoStart

This suppresses interactions and messages, and puts off any restarts that might otherwise be initiated if working UniGetUI through its actual UI. Works like a charm, in total stealth mode. Good stuff!

 

Facebooklinkedin
Facebooklinkedin

Weird Win10 Insider Mismatch

When I report a Windows puzzle, I usually like to provide a solution. But I just noticed something odd I may not have time to solve today. It looks to me like a weird Win10 Insider mismatch. Let me explain: my production PC is signed up for the Beta Channel, as you can see in the lead-in graphic. But a quick Winver run shows that PC running version 19045.5371 (see below). Alas, the current Beta Channel Insider Preview Build is 19045.5194. And there’s the mismatch in plain sight!

The Build number on this supposed Beta Channel PC corresponds to the current public/production release.

Fixing Weird Win10 Insider Mismatch

Upon closer examination, the Beta build is lower than the current production build. Looks like I want to switch to the Release Preview channel at Build 19045.5435 instead. Let me try that… No joy.

So then, I do some more poking around online, turns out I need to re-select the Beta Channel item (see lead-in graphic) and open its subsidiary window. That lets me switch to the Release Preview channel. Then when I pop back up two levels to re-run an update check, I get what I want:

Turns out my problem is an error in understanding how to switch from Beta to Insider Preview channel: problem solved!

Looks like the download and install are working. I’ll be rebooting soon: installing has reached 100% but not yet flipped over to “Restart pending…” Now it’s installing again … 20% … taking much longer … 45% … 73% … 88% … done. Restarting now… AAAAND winver now shows 19045.5435.

Turns out it wasn’t a channel mismatch: I was on the wrong channel FWIW, Copilot tells me that MS is shutting down Beta Channel, but is continuing to release into the RP (Release Preview) Channel. Hence, my need to change channels to get to the right build level. Apparently, I missed that memo. All fixed now!

As always here in Windows-World, fixing things is easy when one knows what to do. This time, it took me a while — and some new info — to figure out what that was. Go figure!

Facebooklinkedin
Facebooklinkedin