Category Archives: Recent Activity

Windows Start Soliloquy Gets Fanciful

MS has started a new design blog under the general heading of “Behind the Surface.” It’s entitled “Start, Fresh –Redesigning the Windows Start menu for you.” The “Windows Design Team” is named as the author, rather than one or more specific individuals. It’s an interesting read, if a bit too breathless and wonder-struck for me. Indeed although this Windows Start soliloquy gets fanciful and overdone, IMO, it’s still worth your perusal.

Where (and How) Windows Start Soliloquy Gets Fanciful

In a list of so-called “guiding stars” the blog states four key principles driving Start Menu design. These serve as the lead-in graphic above, so I don’t repeat them. MS makes much of the work it took to rework the Start Menu. Those efforts presumably fit into the upcoming release of Windows 11 25H2 later this year. Here’s a representative quote from the post, likely from a user interaction during that process (note the tone and diction, please):

Help me find my apps faster. Let me bend Start to fit the way I work. And please—keep the magic, don’t lose the soul.

You’ve got to read the post and check out its images, tables, and language to really make sense of what it says. The key conclusions (and design changes) should include (each bolded item below is quoted verbatim from the blog post, sans quotation marks):

  • Dynamic recommendations: “files and apps” that “surface exactly when they matter.”
  • More and better views for all apps: Repositioned at the top of the Start Menu, you can choose “between logical categories, a neat grid, or the familiar A-Z list.”
  • Mobile content, gently blended: Integration with mobile devices mentions both Android and iPhone and stresses how you can reach out from the desktop to a mobile device.
  • Personalization, elevated: Stresses user’s abilities to zoom in on, or ignore, individual Start Menu sections, and to size it to match available screen real estate (bigger on big monitors, smaller on littler ones).
  • Under-the-hood speed: A commitment to making Start an “accelerator of your day” that loads “in a snap” not “dragged by lag.:

Generally MS makes an ongoing commitment to keep listening to user input and adjusting to what users have to say. Overall their goal is to meet their mantra for what the Start Menu should be:

Everything you need, right here, ready when you are.

This Should Be Interesting…

The rah-rah nature of the blog post and its overall tone and language aside, MS is putting itself out there. In the broadest of strokes they’re promising to improve the Start Menu, and to keep making it better. It will be interesting to see how that plays out in upcoming Insider Preview releases — and ultimately, in 25H2 itself. I’ll be watching — and sharing my observations — along that path. So will lots of other Insiders and other users. Stay tuned!

Note: here’s a shout out to Sergey Tkachenko at WinAero.com, whose story this morning pointed me at the MS blog post. Thanks! For a vastly different take on what’s going on here, see what Paul Thurrott has to say about this blog post.

Facebooklinkedin
Facebooklinkedin

Copilot PowerShell Scripting Improves

Hopefully, the observation that Copilot PowerShell scripting improves — and keeps improving over time — is noteworthy. And I mean outside a small circle of Windows nerds. From September through November of 2023, I wrote a series of stories about customizing Windows Terminal and PowerShell for TekkiGurus. As part of my research I used Copilot to help me build a raft of PS scripts. They served to read and write files, including JSON for profiles and configurations, counting text items, and more. That provides my basis for comparison between then and now. That experience grounds my assertion that Copilot has indeed gotten better at this. Let me explain…

What Copilot PowerShell Scripting Improves Means

In 2023, most of Copilot’s scripts of more than 2 or 3 lines of Powershell failed out of the box. All  suffered from minor syntax errors. Some included outright mistakes or errors. That said, they were close enough to the marks I was trying to hit to be helpful. I could debug and get them running properly, doing what I wanted them to, in an hour or two. That’s good, but by no means as magical as I might like.

Things are different now. Yesterday, for example, I learned that UniGetUI can save a complete list of all installed packages on a PC in file format. Upon examination, that format proves to be plain-text JSON, designed to be both compact and easy for humans and PCs to parse and ingest. “Great,” I thought, “If I can count the number of packages in that file, it will also tell me how many packages I have installed on the PC whence it’s generated.”

Indeed, I asked Copilot to generate a PS script to count the number of instances of “Name” in that file (each package has one such field). I took the resulting PowerShell and ran it, and it worked on the first try. You can see those results in the lead-in graphic for this blog post, at the top of the output (a whopping 454 of them, in fact). I’m tickled to death that I got the info I wanted without having to debug anything.

Where (and How) Copilot Still Falls Short

Ideally, an AI amanuensis could take this effort a step further. I should be able to ask Copilot: “How many packages are installed on my PC?” and get the same answer. Right now, it tells me how to get that answer via various PowerShell sources that include WinGet, the MS Store, and Win32 applications. We’re not quite where I want AI to be just yet.

One more thing: I asked Copilot to tell me when I wrote the TekkiGurus series of stories about Windows Terminal and it couldn’t tell me. For AI to work the way I want it to — and I think most readers could agree that it would be immensely helpful for that to happen — it would look up the initial Wayback Machine link, read the pub date, then follow the links in that story to other four elements in that 5-part series. It could then compile the full list of dates and titles and tell me what  I needed to know. Alas, not yet.

IMO, humans should drive AI to set tasks for it to handle and complete. AI should use its smarts to figure out how to get this done, and then to do it. Right now, it seems ready to tell me how to do it, and then do it for myself. But that’s not really the way it should work. Hopefully, we’ll be able to take that next step sooner, rather than later, in turning AI into a real assistant and amanuensis, and less of an advisor or source of guidance. In the months and years ahead, we will surely find that out!

 

Facebooklinkedin
Facebooklinkedin

Interesting UniGetUI Update Shenanigans

I have to laugh. I read yesterday on NeoWin that UniGetUI — Marti Climent’s excellent UI skin for WinGet, Scoop, Chocolatey and other package managers — had gotten a big update. So naturally, I wanted to try it out. Instead, I got tangled up in some  interesting UniGetUI update shenanigans. They were almost entirely of my own making, but worth explaining. Here goes…

Revealing Interesting UniGetUI Update Shenanigans

I’ve actually had UniGetUI installed on my PC since the days when it was named WinGetUI. And indeed, I’d gone through several beta versions of UniGetUI. Amusingly, some launched from the old name (WinGetUI) but showed up with the new one (UniGetUI).

Somewhere in that skein of releases, the package names or IDs got tangled up. When I ran the new version of UniGetUI, it showed me an older beta version needed updating. Thus, I used the newest UniGetUI to uninstall that same older beta. Imagine my surprise when the PC came back with no version(s) of either WinGetUI or UniGetUI installed. Somehow, the beta uninstaller ended up doing away with everything WinGet or UniGet UI related on that PC and I was left with nothing.

Sometimes, Nothing Is Good

Neither Settings > Apps > Installed apps, nor Revo Uninstaller showed me anything related to WinGetUI or UniGetUI on my PC. So at least, I had a clean slate left behind. That made my job easy: I went to the Latest Release (v3.2.0) on the UniGetUI GitHub page, downloaded UniGetUIInstaller.exe and had at it.

Everything is now working, and the newest version — as you can see from the About info in the lead-in graphic — is working. It even managed to update TeamViewer for me, despite the older WinGetUI failing at that task before I started this adventure.

Sure enough, it’s always something, here in Windows-World. I’m just glad when a fix or workaround presents itself to me with little effort. This was one of those rare and happy times … I’m grateful.

 

Facebooklinkedin
Facebooklinkedin

Chasing Intel esrv_svc.exe

Looking over my various Windows PCs and Reliability Monitor reports after a week away, I stumbled across an interesting — but not unexpected — APPCRASH. It’s got me chasing Intel esrv_svc.exe, to learn what it does, and see whether or not it’s serious. TLDR version: runs various Intel update facilities; no, it’s not.

Where Chasing Intel esrv_svc.exe Takes Me

According to MS Answers,  esrv_svc.exe is related to a bunch of different Intel update checks, including:

  • Intel Driver Update Utility
  • Intel System Usage Report
  • Intel Energy Checker
  • Some of the Intel PROSet Wireless Software
  • Sony VaioCare

The error itself is tied to item number 2 (but that shows up only on the initial ReliMon report page as “Intel(R) System Usage Report”). That said, I also use the drive update utility (as part of Intel Driver and Support Assistant, aka Intel DSA) and the PROSet Wireless software (on most of my Lenovo laptops, in fact). I couldn’t have run  DSA on or around the error date of 5/2/2025, because we were out of town. So it was some kind of scheduled task, running on its own.

FWIW, Reddit also ties this kind of error to the Intel telemetry program (aka Intel Computing Improvement Program, which scrapes and sends Intel-related event info back to the company for capture and analysis).

Is There Cause for Concern?

AFAIK, despite this APPCRASH error, there’s no cause for concern around this executable. It’s involved in managing communications with Intel. Such to-and-fro appears to be either update- or event-related and not critical to proper PC operation. I’m going to follow Elsa’s lead from Frozen  and just “let it go” into the great bit bucket beyond the confines of the cozy little world here at Chez Tittel.

Here in Windows-World, it’s good to let go when you can. I’ll concentrate on stuff that poses real problems or indicates actual trouble of some kind. This one looks like just another hiccup to me. Plenty of those around here, for sure!

 

Facebooklinkedin
Facebooklinkedin

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

Can Restart Application Mean Reboot?

I found myself asking the query posed in this blog post title after updating WinGet (aka Microsoft.AppInstaller) inside Windows Terminal this morning. Why? Because a routine WinGet Upgrade fielded an update to its own self (see lead-in graphic). Then it advised in yellow to “Restart the application to complete the upgrade” as shown. I did so, but it didn’t help. Indeed the upgraded version (see next screencap) didn’t appear in Windows Terminal until I rebooted the test PC. That’s why I pose the query: “Can restart application mean reboot the PC?” Mebbe so…

Can Restart Application Mean Reboot?
Can Restart Application Mean Reboot?

Why Say: Can Restart Application Mean Reboot?

I raise the question because restarting Windows Terminal did not advance the version for Microsoft.AppInstaller from 1.25.340.0 to 1.25.390.0. But a reboot of the test PC, and a subsequent check of that app’s version number did produce the desired result (see above). What else should I wonder after such a turn of events?

Just to make sure I checked the App info for Windows Terminal after running WinGet to see if it somehow stays active after it’s been run. Nope: here’s what I see:

No evidence of lingering WinGet/MSAppInstaller here.

For the moment it looks like the WinGet team has fixed the issue with strange self-update behavior. It now sends a message to restart the application instead as shown at the head of this blog post. The only way I could switch from the old to the new version was through a reboot, though. I’ll have to ask Demitrius Nelon if that’s the way it’s really supposed to work. Stay tuned!

Facebooklinkedin
Facebooklinkedin

Correlating KB Items and DISM Package IDs

Here’s an interesting situation. I was reading on Neowin this morning that MS has fixed a Windows 10 issue that caused BSODs on some systems (not mine, thankfully). To find or uninstall such an item, one must use DISM. But DISM deals in “Package Identity” strings, not in KB article numbers (e.g. KB5057589, as in this case). Surprisingly, correlating KB items and DISM package IDs turns out to be vexing and tricky. Indeed, this SuperUser thread more or less confirms what I quickly figured out. That is: the only datum both items have in common (using Update History for KB items and DISM Get-Packages for PkgIDs) is their install date/time.

Fortunately, what I was seeking showed up dead last in the Get-Packages output in PowerShell/Windows Terminal. As you can see in the lead-in graphic, it’s the only item whose install date matches that for KB5057589. But there’s no inherent correspondence with its PkgID: Package_for_WinREServicing~31bf3856ad364e35
~amd64~~19041.5728.1.1. What to do?

More On Correlating KB Items and DISM Package IDs

I figured there might be a PowerShell script (or something similar) already available to establish this correlation. AFAIK, nope! I thought that Copilot might be able to write me such a script. Nope again: it wants to look for the KB item ID inside the PkgID. You can see from the foregoing item (or by looking at installed updates using DISM Get-Packages) that this just ain’t so.

It looks like the only way to put all this together is to install the PSWindowsUpdate module, then use its built-in Get-WuHistory cmdlet. By writing that to a file, and then doing likewise with output for DISM Get-Packages, it should be possible to use matching date strings for KBs from the former with the “Install Time” attribute value from the latter to find and document matches.

Another Project for My List

Now that I know what I must do, I need to figure out how to do it. That will make excellent fodder for another blog post. As soon as I find the proverbial “round tuit” I’ll put that together and post it here. In the meantime, it’s nice to see that the obvious path to success (looking for the KB item ID inside the DISM PkgID) isn’t the actual path to success. Here in Windows-World, that’s all too often the case. I’m glad it keeps me entertained. I hope you feel likewise.

Facebooklinkedin
Facebooklinkedin

E-mail Link Cynicism Is Well-Considered

I’ll admit it: I’m a cynic when it comes to emails that ask me to follow a link to verify something. If somebody asks for verification unsolicited, I believe by default that request is malign. So when an email showed up asking me to verify my account to keep my email server going, my first instinct was “Heck NO!” And, as the NordVPN link-checker immediately confirmed , my instincts are good. It pops up instantly as a phishing site. Skepticism is spot on, and e-mail link cynicism is well-considered — at least IMO.

Check to See if E-mail Link Cynicism Is Well-Considered

If in doubt, check the link at a third-party site. NEVER click a link from an unknown sender. If you’re incurably curious, do it from a sandbox or VM you can blow away if something bad happens. The important thing is to think about what’s in your inbox, how it got there, and how it might bite you.

Here’s what the NordVPN site says. It’s great advice so I’ll repeat it verbatim:

Got a suspicious email or text? Check the link before clicking — it will significantly reduce the chances of you falling for a phishing attack.

When in doubt, check. If you can’t check, don’t click: wait until you can (or delete the email). If it’s really important and legit, the sender will resend and you’ll get another opportunity to recheck what’s going on.

Reverse Lookup Mojo

Indeed, if you are concerned about a reported issue or account problem, it’s much safer for YOU to visit a known, good, working vendor site to check on status. Amazon is a good example: I can’t tell you how many bogus SMS text messages I’ve gotten on my cell that ask for Amazon account details to confirm things, because I delete them as soon as they appear. As a matter of policy Amazon does not request sensitive info (passwords, credit card data, etc.) via SMS, though they do report  order and delivery status that way.

Be smart when you respond to emails. If there’s any doubt, open your own link to a trusted vendor and check things from your end. If you don’t recognize a sender asking for sensitive info, don’t respond. This is a case where doing nothing is exactly what’s right — and safest.

Facebooklinkedin
Facebooklinkedin

Climbing Slack’s Login Learning Curve

Hurry is the enemy of proper problem solving. I had that thought only later yesterday, after initially struggling to get logged into Slack to chat and huddle with a client. Now, I understand I’m learning a new way of collaborating. At the time, I was frantic because I couldn’t initially get myself logged in for a meeting NOW. Alas, I  should’ve started climbing Slack’s login learning curve sooner than a minute prior to meeting kickoff. Lesson learned…

Climbing Slack’s Login Learning Curve to Success

Both my problem and its solution were staring me in the face on the lead graphic. It’s the Slack login page. I didn’t take the time to read the entire screen, and simply tried clicking continue when Norton Password Manager failed to load the login info. Of course, that meant I couldn’t get anywhere fast … and I was in a hurry. So I jumped into the URL entry bar in Chrome, typed Slack, and used a prior successful login screen to get to the project pages I was seeking.

Soon the crunch passed, and the meeting ended likewise (with a happy enough outcome, thankfully). Looking again at the Slack login screen, I realized I should have read down to the bottom. There, an Open button would have taken me right to the project I was seeking. Nothing to it, in fact.

Festina Lente…

That’s Latin for “Hurry slowly.” Sure, it’s OK to rush to get things done. But you don’t want to go so fast you leave common sense and simple observational skills behind. I’m chastened, and a little embarrassed. Hopefully, I won’t rush headlong into OMG the next time something like this happens. I’d rather take a little more time and use it to get where I’m going rather than flailing about.

And for sure, for sure, that is the way things go in Windows-World sometimes. I hope they don’t go that way again for at least a few more days. Cheers!

Facebooklinkedin
Facebooklinkedin

Incase Relaunches DBM Line

We knew it was coming. 15 months ago (January 2024) I blogged about how Incase was taking over the old Microsoft desktop products for ongoing resale. That line is named “Designed by Microsoft” (DBM, get it?) and is now for sale in the marketplace. Featured on the incase.com home page, you can get a good taste of that stuff from the lead-in graphic. And it explains why I aver that “Incase relaunches DBM line.”

Why Say: Incase Relaunches DBM Line?

DBM means Incase has a line of mice and keyboards, plus other accessories (e.g. headphones) that MS used to build until late 2023 and then abandoned for Surface-branded items. Lots of people took exception, including yours truly. Indeed, I was delighted that Incase wisely chose to license those designs and re-issue them . Prices are a bit higher than I remember them in 2023. That’s when I purchased these last Microsoft-branded items:

  • 2  Comfort Curve 4000 keyboards
  • 2 Basic Optical Wired Mouse v2.0
  • 2 Mobile Mouse 4000

I still have one of each left in its original box, ready to use when the current avatar starts to fade or fail.

A New Day for MS-Branded Peripherals

But now, there’s no need to hoard — nor pay outrageous eBay prices — to obtain these old familiar and (IMO at least) beloved desktop appurtenances. You can just visit the Incase site and buy them direct. I assume they’ll partner up with other typical sales channels (e.g. Best Buy, Walmart, Target and so forth) to get them out there in large numbers at competitive prices.

I’m glad to see them back. And here’s a shout-out to Paul Thurrott himself, whose blog post yesterday brought Incase DBM device availability to my attention. Thanks, Paul! I’ll also cheerfully admit that I’m completely hooked on my Comfort Curve 4000 keyboard and haven’t found another that comes close to matching its fit for my flying, or sometimes fumbling, fingers. Long may it wave!!!

Facebooklinkedin
Facebooklinkedin