Tag Archives: featured

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

OhMyPosh Upgrade Needs WinGet DB Reset

Something interesting just popped up in Windows Terminal. Literally. Upon starting Windows Terminal, I got a notification from OhMyPosh that it was updating to the latest version: 25.21.0. So I closed WinTerm and re-opened it to run WinGet upgrade –all — include-unknown. As you can see in the intro screenshot, WinGet went ahead and updated OMP again anyway. When I asked Copilot why this happened, it explained that an OhMyPosh upgrade needs WinGet DB reset so it is forced to rescan all currently installed packages. A restart makes that happen automatically, BTW.

Why OhMyPosh Upgrade Needs WinGet DB Reset

When Windows Terminal has been up and running already, WinGet doesn’t refresh its current package data through a simple open/close operation. Instead, users must run the following WinGet command to force that to occur (again, a restart has the same effect):

winget source reset --name winget --force

This tells WinGet to rebuild its list of local (that is, currently installed) packages. After that running an update check won’t show OhMyPosh in need of updating anymore. I checked this out on another test PC and indeed this approach works. Good to know!

ICMYI: A Quick Intro to OhMyPosh

Many readers will recognize OhMyPosh (OMP) as “the way” to snazz up the command line in Windows Terminal/PowerShell. For an inkling of what this looks like using developer Jan De Dobbeleer’s own unique theme, look at the top and bottom of the intro graphic. It shows glyphs for (from left to right):

  • the current login account (ed) and folder icon
  • execution time for most recent command (0 ms)
  • battery status (power connector against green means “good”)
  • current environment = PowerShell (pwsh)
  • current time = 10:33:08 (time of screen capture)

The last two items in the preceding list show up at right, the first three at left, on the command line. For all items shown, and a whole bunch more OMP offers users a plethora of themes. It also provides good documentation and “source code” (JSON markup, actually) for all of them. Users can even create their own custom themes. I’ve written an intro and how-to story about OMP for TekkiGurus, but that site is now defunct. Find it via this WayBack Machine link. Enjoy!

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

RDP Strangeness Requires Dogged Pursuit

There have been plenty of reports about weird Remote Desktop access issues and Windows 11 of late. Search Google for “RDP issues with Windows 11 updates” to see what I mean. Until this morning, I remained blissfully beyond that fracas. Then I had to jump through a bunch of hoops to RDP into my Lenovo ThinkStation P3 Ultra. Indeed, overcoming this RDP strangeness requires dogged pursuit, as I will now explain. By which I mean: I’m again able to use the Remote Desktop Connection (RDC, aka mstsc.exe) to get into that machine.

Overcoming RDP Strangeness Requires Dogged Pursuit

I considered this as a kind of real-time troubleshooting exercise. Here’s that I did to get my connection working:

1. Opened RDC using the plain vanilla machine name: TSP3Ultra. RDC couldn’t find it.
2. Used Advanced IP Scanner (AIS) to scan my LAN and show me the currently active machine names in use. Tried TSP3Ultra.lan instead, then also tried TSP3Ultra-4314.lan. RDC couldn’t find either one.
3. Used AIS with a right-click to run RDC directly against its IPv4 address (192.168.1.249). RDC still couldn’t find it — this almost always works, so I knew I had a real problem, not just a naming issue.
4. Rebooted the TSP3Ultra, and tried again. It came up with a different IPv4 address this time (192.168.1.99) and RDC worked via a new machine name AIS showed: TSP3Ultra-5815.lan.

I’m now successfully remoted into the previously inaccessible PC, and glad of it. My next move would have been to start uninstalling recent WU updates, one at a time, until things started working again. I’m glad I didn’t have to take things that far.

What’s Causing Remote Desktop Strangenesses?

I wish I could say definitively. All I can do is to point at the changing names for the target device that AIS shows me over time. That makes me thing something interesting is up with machine name resolution on my LAN. Copilot says machine names of the form <name>-nnnn.lan occur when NetBIOS name resolution seeks to resolve conflicts arising from duplicate names.

We can see the IP address changed upon reboot, so I’m thinking it relates to IP address leases that change over time. The machine name, of course, stays the same, but when the IP address changes the DHCP server has to give the same device a new auto-generated name to avoid conflicts from the still-present (but expired) address in the name table.

I’ve witnessed that such things age out after 24 hours or so. Then the plain machine name will work with the new IP address unadorned. It’s just another thing to love about Windows networking, and the occasionally strange behavior of network names and addresses. Thus, it’s wise to prepare for your own dogged pursuits when that happens!

Facebooklinkedin
Facebooklinkedin

Why Restart Guarantees WinGet Upgrade

OK, then. Yesterday I blogged about seeing no upgrade to WinGet until after a PC restart. It turns out that is indeed one way — but not the only way — to ensure that WinGet will upgrade itself from one version to the next. In this case it was moving from Version 1.25.340.0 to 1.25.390.0.  Why did I restart? Because I closed, then re-opened Windows Terminal several (3) times with no intervening change in WinGet versions. Thanks to feedback from WinGet team lead Demitrius Nelon and Senior Software Engineer John McPherson, I now know why restart guarantees WinGet upgrade. I also know why a restart may not be needed, and about possibilities for upgrade hangups. Let me explain…

Here’s Why Restart Guarantees WinGet Upgrade

Thanks to an invitation from the development team, I’m a member of an MS Teams chat called “WinGet Community.” I posted info about my observations and a link to yesterday’s blog there, and got some useful and interesting information from the aforementioned folks that provide a pretty detailed explanation of what I experienced, and why it happened.

First, here’s how Demitrius responded to my report and inquiry:

Hey Ed (Guest), when WinGet is updating “packaged” applications (MSIX Installer), it’s using deferred registration. It may take a few moments for the registration to complete before WinGet is updated (App Installer package) when WinGet is the thing currently running updates . That means WinGet essentially needs to completely finish what it’s doing before the delayed registration happens. A reboot which requires a user to log in (and that triggers the “registration” part of the MSIX lifecycle) will ensure all MSIX packages are up to date. In some cases there may be a few second delay when winget upgrade –all was used to update WinGet itself.

I’ll talk with the team to see if there is a reasonable way to diagnose this a bit better, and if the performance is suffering, we might need to look into some other “special” handling for this specific scenario.

We were hoping to avoid any logic in WinGet like “if package == foo” then do something special.

In some cases, a user may be actively running an MSIX package GUI based application. WinGet could upgrade the package to a newer version, but it wouldn’t be applied until the currently running instance was restarted.

That’s why the message is “Restart the application to complete the upgrade.”. We just don’t know if the application is running or not. In the case of App Installer / WinGet, a user could be in the middle of installing a sideloaded application which also could have it “tied up” from having the latest version registered for the user.

Restart application should not mean “reboot”. Some applications specify a reboot is required, and that’s when WinGet would display “reboot required”.

So essentially, what Demitrius is saying is that WinGet waits until all other pending package updates finish before allowing its own registration to change and its own update to complete. I was probably not waiting long enough for all the pending items to complete. That said, he also explains cases where such completions might not happen until (or rather, after) a restart occurred.

And Then, There’s a COMplication possible…

John McPherson observes further that:

Note that all packaged processes must terminate for the next process launch to then register the new version.  So any outstanding COM objects keeping the server alive will block that.  This could be due to PowerShell cmdlets and the GC not running due to no memory pressure.  Or it could be other services on the machine using COM.

So it appears there could be stuff running in the background that might stymie WinGet’s own auto-upgrade. Thus, it sounds like a restart is a reasonable workaround if and when WinGet attempts to upgrade itself, reports success, but the version number doesn’t increase. Waiting isn’t an unreasonable thing to do, but if the wait gets too long, a restart will force the WinGet upgrade to go through.

Thanks, guys, for the great information and explanations. It’s good to know what’s going on behind the scenes when WinGet handles multiple updates in a single go. In yesterday’s case, 5 items were upgraded, including WinGet itself, but also OhMyPosh, Teams, WinScript, and more. Of that batch, I’m pretty sure WinScript has interesting COM connections. Thus, I can speculate that the old three-fingered-salute (a restart, in this usage) resolved a stuck situation. As the old saw goes: “There’s no school like the old school.”

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

Explorer AppHangB1 AppHang81 Gotcha

Whoa! Things are getting pretty esoteric. Via Reliability Monitor, I just got caught in a File Explorer AppHangB1 AppHang81 gotcha. But first, let me explain that following last Fall’s cataract surgery, I can’t see the fine print without my reading glasses anymore. I cheerfully confess I can’t see the difference between the “B1” and the “81” parts of those Problem Event Names in ReliMon unless I put my glasses on. So I have to laugh.

Overcoming Explorer AppHangB1 AppHang81 Gotcha

I looked up the error code — which I initially read with the “81” suffix — using Copilot. I immediately wondered why it had two paragraphs about the same topic (see below). Then it hit me: I needed better visual acuity to see and understand what Relimon and Copilot were trying to tell me.

Upon closer examination “8” and “B” are close, but NOT the same!

Once IDed, It’s Neither Scary nor Well-Lit

Further research into these AppHangB1 and AppHang81 errors isn’t terribly helpful. From what I can tell, this happens sometimes and may or may not be fixable using standard troubleshooting techniques:

  • Apply pending updates
  • Run System File Checker (sfc/scannow)
  • Disable Third-Party extensions (NirSoft ShellExView is a common culprit)
  • Try a clean boot
  • Check Event Viewer for more details

If the error kept recurring, I might be inclined to go to such lengths. But over the entire ReliMon window (30 days) it’s happened exactly once, 10 days ago. I’ll keep an eye out. If it happens again, or starts to repeat, I work my way through that standard sequence. Right now, I’ll treat it as a one-off and scratch my head.

Looks like I need to remember to don the old reading glasses when trying to decode fine-print info like ReliMon’s error details. I’ve got the screen jacked up to 125% magnification but sometimes, that’s not enough. Is this the OS’s way of telling me that Windows 10/11 is “no country for old men?” I hope not…

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