All posts by Ed Tittel

Full-time freelance writer, researcher and occasional expert witness, I specialize in Windows operating systems, information security, markup languages, and Web development tools and environments. I blog for numerous Websites, still write (or revise) the occasional book, and write lots of articles, white papers, tech briefs, and so forth.

Cool Tools, Insider stuff, Networking, Troubleshooting, WED Blog

RDP Strangeness Requires Dogged Pursuit

April 28, 2025 Ed Tittel Leave a comment

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!

Uncategorized

Why Restart Guarantees WinGet Upgrade

April 25, 2025 Ed Tittel Leave a comment

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.”

Cool Tools, Insider stuff, Recent Activity, WED Blog

Can Restart Application Mean Reboot?

April 24, 2025 Ed Tittel Leave a comment

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…

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!

Uncategorized

Explorer AppHangB1 AppHang81 Gotcha

April 23, 2025 Ed Tittel Leave a comment

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…

Insider stuff, PowerShell, Recent Activity, WED Blog, Windows Update

Correlating KB Items and DISM Package IDs

April 22, 2025 Ed Tittel Leave a comment

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.

Insider stuff, Recent Activity, Security, Thoughts & concerns, WED Blog

E-mail Link Cynicism Is Well-Considered

April 21, 2025 Ed Tittel Leave a comment

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.

Cool Tools, Insider stuff, Recent Activity, WED Blog, Windows tools

Climbing Slack’s Login Learning Curve

April 18, 2025 Ed Tittel Leave a comment

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!

Cool Tools, Insider stuff, Recent Activity, WED Blog

Incase Relaunches DBM Line

April 17, 2025 Ed Tittel Leave a comment

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!!!

Cool Tools, Insider stuff, Recent Activity, WED Blog, Windows 11

Snipping Tool Text Extractor Rollout

April 16, 2025 Ed Tittel Leave a comment

Windows certainly has its weird and wonderful ways. I was forcibly reminded just now, when looking on a Canary test PC to see if the next Text Extractor tool was on my Snipping Tool toolbar. While you can see it in the lead-in graphic for this story, I couldn’t see it on my PC right away. At first, understanding that MS is conducting a new Snipping Tool Text Extractor rollout, I thought I might be on the outside, looking in. Not so: let me explain…

Working Thru Snipping Tool Text Extractor Rollout

When I first checked the app and saw the toolbar unchanged, I jumped to the assumption that my PC wasn’t in the first rollout cohort. Then I remembered: Snipping Tool is a Windows Store app. So I went to the store and clicked on the Downloads button. Nothing had been updated since 4/14 (two days ago), so I clicked the “Check for updates” button.

Guess what? There was indeed a new version of Snipping Tool ready for download. Once that step was complete, and a quick install later I saw what MS announced in its April 15 blurb. Yes, Virginia: there is now a text item in the Snipping Tool toolbar. Again you can see it in the second from right position in the intro image. MS even provides an intro blurb to tell you what this toolbar element does.

I checked it, and it works as advertised. Makes the steps involved in grabbing text from an image and dropping it into a file ever so much easier and faster. Thanks, MS for giving us something many of us can use and enjoy (your humble author included). Visit the MS Store on Canary and Dev Windows 11 PCs and you, too, can partake of this neat new feature. Cheers!

Device drivers, Insider stuff, Recent Activity, Thoughts & concerns, WED Blog

Why Run NVIDIA Studio Driver?

April 15, 2025 Ed Tittel Leave a comment

The question in the blog post title — namely: “Why run NVIDIA Studio driver?” — means considering the alternative. That’s the Game Ready Driver, which gets updates 2 or more times every month. Look at what new Game Ready Drivers bring to the party. New games (and game versions) keep coming out, and GPU drivers need matching tweaks. Thus, the answer is “To play (new or updated) games.”

I just saw news that NVIDIA had released new cards (and drivers, presumably). Checking the NVIDIA app, I quickly saw no new Studio version available. But a new version of the NVIDIA app installed itself when I went to check. Indeed, its “About “banner headlines this blog post.

Why Run NVIDIA Studio Driver — Not?

If you don’t game, you don’t need to track the game-focused updates. Game Ready Driver users get new bells and whistles (NVIDIA calls them “optimizations and performance enhancements”) and a faster update cadence. Studio driver users get more stability and reliability, including more “extensive testing with professional software to ensure consistent performance.”

Interestingly enough, PCs can switch between the two drivers at will to exploit those trade-offs as they see fit. Because I don’t game (at least, not the kinds of games a GPU can impede or assist), I choose stability and reliability over optimizations and performance enhancements.

Indeed, I’ve been bitten when I’ve succumbed to the temptation to switch from Studio to Game Ready drivers upon various occasions. If you run this Google Search, you’ll see that I’ve blogged about NVIDIA stuff (drivers mostly, though occasionally about the app and its GeForce Experience predecessor) 9 times in the past year. That makes it a pretty regular thing for me to watch and report about.