Category Archives: Troubleshooting

Visual Studio Build Tools 2017 Mystery Masticated

This was a weird one. The lead-in graphic shows that although I plainly installed version 15.9.51 of the Visual Studio Tools 2017, it reports in as version 15.8.9. No amount of uninstall/reinstall (aka R&R for “remove & replace”) made any difference. I finally solved my Visual Studio Build Tools 2017 mystery by installing the latest version of Visual Studio Enterprise. (That came free, thanks to my WIMVP privileges and its attendant VS subscription.)

Workaround Solves Visual Studio Build Tools 2017 Mystery

Take another look at the lead-in screencap. It shows me uninstalling version 15.8.9 using Winget. Then I force-install version 15.9.51 explicitly. But even so, Winget list still reports version 15.8.9 as clear and present. Sigh.

Thus, I resorted to a total workaround. Because I have access to a VS subscription — thanks to my 2022 WIMVP status (I’ll be finding out next week if it gets extended for 2023) — I installed a full-blown VS version. This was enough to kill the VS.2017.BuildTools update messages in Winget (at least, after I uninstalled same).

What Gives?

Because I can’t find any definitive explanation, I can only speculate. I’m guessing it’s either (a) a  mistaken version tag  for what is really version 15.9.51 or (b) a unreported install failure that leaves the Build Tools at version 15.8.9. Whatever that case might be, I switched from the free version to the for-a-fee version. That made my apparent problems disappear. I’m grateful!

Sometimes, solving Windows problems requires resorting to creative workarounds. I would definitely include today’s odd situation, and its equally odd solution, in that category.

Happy New Year 2023 to one and all. May the coming year bring you joy, prosperity, good health and plenty of interesting Windows issues to solve (or read about here). Best wishes!

 

Facebooklinkedin
Facebooklinkedin

Curious Reliability Monitor Incident Occurs

Sometimes, no news is itself news. One of my favorite Sherlock Holmes stories, The Adventure of Silver Blaze describes a “curious incident of the dog in the night-time” wherein “the dog did nothing…” Lately, as the lead-in graphic from Reliability Monitor shows, my production PS is such a dog. Over a 19-day period, it shows exactly one critical event. And that one is easily explained, thanks to an aging UPS battery.

Good News When a Curious Reliability Monitor Incident Occurs

According to WinFetch, I have 308 packages installed on my production desktop, of which Winget recognizes 226. Those numbers provide ample opportunities for things to go sideways. I confess: I check in on Reliability Monitor when seeking blog topics. It seldom fails to point toward interesting troubleshooting or clean-up exercises.

I use the heck out of my production PC: 8-10 hours a day, 6-7 days a week. Consequently, I’ve seen many less happy Reliability Monitor traces than the one at the head of this story. It is, in fact, something of an anomaly in my 6-plus years of working this PC as a daily driver. And that, to mangle Mr. Holmes, is what makes for a “curious incident” — namely that I could work both hard and long on this PC while maintaining a nearly perfect reliability score.

Windows 10 Gains a Ringing Endorsement

When nothing shows up in Reliability Monitor, the presumption is that the PC is behaving itself well. For example, I’m currently logged into 4 RDP sessions: 3 on various Windows 11 versions, 1 on Windows 10. Only one of them shows one critical error event like the lead-in graphic. It’s from a Dev Channel build that’s been running for 11 days, and the critical error it shows resolves into 4 events that occurred just after the new build installed on November 29.

The other 3 PCs show 3 or more critical events over the default 19-day interval typical for Reliability Monitor displays. And these, too, devolve into a half-dozen error events of one kind or another. My point is: the production PC is manifesting unusual calm and stability, especially as the other machines are less heavily used (though subject to beta software and primarily test or experimental situations).

I see this as another explanation for the relatively slow changeover from Windows 10 to 11 I wrote about yesterday (Where Windows 11 Business Use Stands). If the OS ain’t broke, there truly is no need to fix (or replace) it. I find it comforting, in a weird way; MS undoubtedly has more mixed feelings on this subject. But it offers a pretty compelling explanation as to why businesses aren’t yet taking the Windows 11 plunge in significant numbers.

Facebooklinkedin
Facebooklinkedin

Transient Mysterious GeForce Experience Error

It’s great that I love a good mystery, because I have one on my hands. Yesterday (November 30) I ran GeForce Experience to update the Lenovo P16 Mobile Workstation’s Quadro RTX A5500 GPU. An odd error message showed up at the tail end of the process. It read “Unable to install driver” but didn’t identify which one. Immediately thereafter, GeForce Experience announced a successful driver update (see lead-in graphic). I can only describe this phenom as a transient mysterious GeForce Experience error. As usual running things down means learning and figuring more things out.

Chasing A Transient Mysterious GeForce Experience Error

I did some searching around to see where GeForce Experience keeps its installer logs. It’s a long file-spec, like so:

C:\Users\<acct-name>\AppData\Local\NVIDIA Corporation\NVIDIA GeForce Experience

My source for this insight came from an Nvidia Support article entitled “How to enable NVIDIA Graphics Driver and GeForce Experience installer logging.” The log files, obviously enough, end in the “.log” extension. There were plenty of them to look through, too:

Transient Mysterious GeForce Experience Error.logs

Four different readable log files, no joy in any of them.

I couldn’t find any errors in any of those logs, though, which is why I’m calling this a transient mystery. If I read the afore-cited NVIDIA Support note correctly, I probably needed to enable logging before installing the latest GeForce driver. But it’s kind of a Catch-22: I didn’t know I had an error until the error already happened. If I really, really wanted to get to the bottom of this, I’d roll back to my preceding OS image, enable installer logging, and then reinstall the driver. But because it’s working as it should be and is throwing no errors I can see (Event Viewer and Reliability Monitor) I’ll live with the status quo.

But that’s the way things go sometimes, here in Windows World. I’m just glad things are working as they should be.

Facebooklinkedin
Facebooklinkedin

Minimum Battery Charge Required Blocks BIOS Upgrade

I have to laugh. I’m putting my office back together following not just the big holiday yesterday, but windows washed on Tuesday. I’m talking real, physical windows on the house, not the eponymous OS that is the focus of this blog. I had to disconnect the Lenovo Thunderbolt 4 dock, the wired GbE LAN. That meant my X12 was untethered and uncharged for several days. When I tried to log in to that machine today, I learned that the minimum battery charge required blocks BIOS upgrade. Sigh.

WTF: Minimum Battery Charge Required Blocks BIOS Upgrade

The funny thing is, I had some interesting foreshadowing on this topic just last night. I had to upgrade my now-aging iPad Air 2 to the latest iPad OS. At first, the Install button didn’t light up. Apple helpfully provided a error message by way of explanation, saying that a “minimum charge level of 20%” was required for the OS update install to go forward.

Thus, after leaving the X12 untethered for four-plus days, I found myself wondering. “Gee,” I thought to myself “What do you bet that the X12 BIOS update can’t go forward without a minimum charge level, either?” Sure enough: I checked online and indeed, the battery must be at 25% charge or higher, even if the PC is on AC power, for the BIOS upgrade to proceed.

Easily fixed! It only takes time (about 20 minutes in my case) to get past that 25% threshhold. As I write these words, the BIOS flash is underway at the UEFI command line. It’s just over 80% complete, in fact. Good thing the iPad forewarned me about this possible impediment, eh? Otherwise, I might have jumped into major troubleshooting mode, built a bootable BIOS installer, and done a manual BIOS upgrade instead.

If It’s Not One Thing, It’s Another…

It’s rare when I feel like the universe is looking out for me. Most of the time when trouble strikes, I have to roll up my sleeves and fix things the hard way. This time, time — and the related upping of battery charge levels — fixed things more  or less on its own. As you can see in the lead-in graphic, the same Lenovo Vantage utility that told me I needed a BIOS upgrade now shows me installation success for same.

I’m glad that’s over. I learned about Lenovo’s “self-healing BIOS” along the way to this resolution. I’m just glad serious troubleshooting and repair was unneeded in this happy case.

Facebooklinkedin
Facebooklinkedin

MS KIR Equals Known Issue Rollback

In reading about fallout from recent Windows 10 updates this morning, I learned something new. MS KIR equals Known Issue Rollback. It’s a group policy technique to reverse effects introduced by buggy updates. You can read about how to implement such policy in Microsoft Documentation.

This morning (November 17) news is out that some Windows 10 users may face a missing or non-responsive Taskbar — or even a black screen (depicted in the lead-in graphic). These come as “known issues” from recent updates. A responsive rollback is, in fact, already on its way to users.

Are GPOs Required for MS KIR Equals Known Issue Rollback?

That is an interesting question! Of course, GPOs only work in environments where centralized Group Policy management is in place, or where some means to deploy per-machine policies exists. So then: sometimes yes, sometimes no.

All this said, my source for this info (Neowin.net) makes some interesting observations about these potential Windows 10 gotchas:

Although the problem sounds scary, Microsoft has already implemented the necessary fixes and rolled back the troublemaking code to undo the damage. Affected devices should restore to normal operating mode within 24 hours. However, users can speed up the process by restarting their systems or applying a special Group Policy (only on enterprise-managed devices).

The bold emphasis in the preceding quote, of course, refers to a KIR GPO for those who wish to head trouble off pre-emptively and quickly. Those who don’t mind waiting should see the problem take care of itself within 24 hours of the offending update’s arrival. Sounds like a restart might also repair the issue, depending on timing.

According to that same Neowin story, MS has recently used KIR to fix problems related to Direct Access for remote network access without requiring a VPN connection. Seems like a handy technique for MS to correct its own missteps.

When KIR Could Help

The kind of undo capability inherent in KIR is likely to be most beneficial to small to mid-size operations. These may sometimes push Windows updates reasonably soon after they are released. Most larger organizations will batch updates for release during planned deployment windows (often, over holiday weekends). They tend to hold off on non-urgent updates and test them thoroughly before deploying anyway. Thus, they are less likely to need KIR than other, smaller and less sophisticated outfits.

Facebooklinkedin
Facebooklinkedin

Windows 10 Phone Link Eliminated

Dang! After messing about with PowerShell unsuccessfully, I turned to long-time fave 3rd-party tool Revo Uninstaller Free. Seems that Windows 10 doesn’t allow the Phone Link app to be uninstalled anymore. Sadly, the Uninstall option is greyed out in Settings. Likewise, I couldn’t get PowerShell Get-AppxPackage | Remove-AppxPackage to work, either. But if you turn to Revo Uninstaller, it delivers the goods: Windows 10 Phone Link eliminated.

Why I Want Windows 10 Phone Link Eliminated

Two reasons:

1. Phone Link only works with Android phones and I have iOS. Don’t use it, ever.
2. Update failed, then app “stopped working, around recent Store revisions.

If I can’t use an app AND it causes errors, I don’t need it. Thus, I want it gone!

Look at the lead-in graphic. I’ve put a red box around the listing item for the Phone Link app on my Windows 10 production desktop. Right-click on that item, and the first menu option is “Uninstall.” Pick that. Revo asks you to confirm that choice, as follows:

Windows 10 Phone Link Eliminated.confirm

Alas, PS does NOT show the command details it uses to pull this off. Sigh.

Revo Unsintaller works some PowerShell magic around the following text I copied:

Deployment operation progress: Microsoft.YourPhone_1.22092.211.0_x64__8wekyb3d8bbwe

After removing the app, I used the Revo Uninstaller Scan functions to remove all leftovers from the Registry. It no longer shows up on my Windows 10 PCs — all both of them. I will be on the lookout for reappearances after CUs and feature upgrades, based on what I read online about how Phone Link keeps showing back up.

When it comes to “Windows pest removal” sometimes, repeated treatments may be required. LOL!

Facebooklinkedin
Facebooklinkedin

Winerror versus Err: Enough, or Too Much?

Here’s an interesting dilemma. In the past, I’ve advocated use of the Windows Error Lookup Tool, currently Err_6.4.5.exe The other day, I had cause to rue my recommendation. I actually found a different, more focused tool named Winerror.exe. It’s part of the Windows Assessment and Deployment Kit, aka Windows ADK. But then, you might also need to grab the older Windows 10 version to get the tool I’m about to discuss. It seems to be missing in the Windows 11 version.

Winerror versus Err: Focused and General

You can see the issue in the lead-in graphic for this article. Notice that winerror provides two different expansions, one of which mentions normalization. Err_6.4.5, OTOH, provides 6. These come from a variety of error code source files: bugcodes.h, netmon.h, winerror.h, and ntstatus.h.

In simpler terms, winerror looks only at winerror.h; err… looks at a bunch of error code source files, including winerror.h. My point is that winerror may be worth consulting when you’re troubleshooting Windows 10 or 11. That goes double when the error reporting tool (err_6.4.5.exe) produces more output than you know how — or really want — to use.

Wm Blake Still Has a Point

The end half of the title for this story comes from William Blake’s Proverbs of Heaven and Hell. It makes the excellent point that you really don’t know you have enough until you have more than you need. That’s why I recommend using the older, but less general, Winerror.exe when you find that the latest error reporting tool (err_6.4.5.exe) has more to say than you really need to know.

‘Nuff said!

Facebooklinkedin
Facebooklinkedin

WU Reset Fixes Weird Windows 11 Upgrade Freeze

With Dev and Beta Channel releases, it’s always “just a matter of time” before something gets wonky. Yesterday, in fact, I ran into difficulties upgrading one of my X380 Yoga laptops to Build 25227. In November 2021, I wrote a blog post here entitled WU Reset Tool Works on Windows 11. Good thing, because WU reset fixes weird Windows 11 upgrade freeze, too. Let me explain…

I’m Glad WU Reset Fixes Weird Windows 11 Upgrade Freeze

Here’s what’s weird about this failure. The laptop hung during the post-GUI update phase, after the old OS hands over control to the installer’s WindowsPE-based runtime environment. Indeed, it got all the way to 98% complete before it hung interminably.

Yet, as you can see, the hex code speaks to a “download error.” I have to guess there was some essential bit of data that the installer needed to read right at the end of the post-GUI installation process. When that failed, the whole shooting match went south. Stuck forever!

The Charm Came on the 2nd Try

I probably got lucky. I ran the invaluable reset/reregister batch file cited in the WU Reset Tutorial at ElevenForum, Then I tried the 25227 upgrade again: it worked this time! That said, this one took 30-40 minutes to complete (a fair while longer than previous but recent Dev Channel upgrades). But it sailed through to completion and is now working properly on the X380 laptop.

On the plus side, the login issues I’d been having with RDP on the same laptop also disappeared with the upgrade. That’s a relief. But on the minus side, my other Dev Channel test machine acted a bit wonky during the upgrade, too. It shut down after the reboot from the GUI phase into the post-GUI phase of the install. I had to manually power back on to finish the job. That hasn’t happened for a while with Dev Channel releases, either.

But hey! The purpose of Insider participation is to help catch — and hopefully kill — bugs and weirdnesses before they get into general release. We’re all just doing our jobs by finding and reporting this kind of stuff.

And that’s how it goes sometimes, here in Windows World. Good thing I enjoy it, and relish my appetite for problem solving and troubleshooting.

Facebooklinkedin
Facebooklinkedin

Advanced Sharing All Fixes PING

Apocryphally, PING stands for “Packet InterNet Groper” (or perhaps, “Packet Inter-Network Groper”). Actually, I think it comes from submarine-speak. There, a PING denotes the return sound that sonar makes when reflected. I’ve been troubleshooting a persistent RDP issue with the Lenovo P360 Ultra SFF PC. En route, I just fixed an inability to PING that node. Changing Advanced Sharing All fixes PING, as far as I can tell. Deets follow…along with an RDP fix.

Why Say: Advanced Sharing All Fixes PING?

First off, I relaxed all entries under the “All Networks” heading in Advanced sharing settings (Control Panel). Then, PING started working on the P360 Ultra. Easy-peasey, but not terribly safe.

Interestingly, I then went back and changed the settings to their defaults. That’s “the other option” in all thee cases shown. PING kept working, but the sharing was tightened back up.

Comparing P16 and P360 Ultra

What’s even more interesting is that the other “new machine” here does RDP and PING just fine. That’s the latest Lenovo Loaner here at Chez Tittel: the P16 Mobile Workstation. I’ve had no issues with networking and RDP on that other machine. But I was still unable to remote into the P360 Ultra.

I switched to the Remote Desktop app, and got a more informative error code: 0x4. In researching possible fixes, I found a reghack under that heading at TechDirectArchive. Since I’d already tried everything else recommended in that story, I tried that too.

Here’s the Remote Desktop app with the P360 Ultra under its wired IP address: 192.168.1.192. Problem solved!

It had me create a new Regkey named MaxOutstandingConnections in HKLM\CurrentControlSet\Control\Terminal Server. As suggested, I set its value to 0x10000. And guess what? Both the Remote Desktop Connection application (mstsc.exe) and the Remote Desktop app (show above) now work!

Go figure. All I can say is “What a relief!” It’s been driving me bananas…

 

Facebooklinkedin
Facebooklinkedin

Old School Driver Repair Still Works

Whoa! I’ve had the Lenovo P360 Ultra SFF PC for a week now, and I FINALLY got the discrete Nvidia RTX A2000 GPU working. It showed only a black screen with the Acer XR382CQK monitor. With a Dell 2717 from my wife’s PC as a stand-in, it would run (briefly) then fall over (AppCrash on NvidiaContainer.exe). My suspicion of driver issues were confirmed by the ace Lenovo engineering team. And I was happy to learn that an old school driver repair still works.

What Old School Driver Repair Still Works?

Good question! Having just written a story for TechTarget about fixing black screens, this was chapter and verse for me. If the current GPU driver falls over, received wisdom goes “roll back a version. Keep going till it works…” I’m actually not sure how far that would have gotten me.

But what the Lenovo engineering folks told me falls in line with that approach. They simply said “install version 511.65” and furnished me with a Lenovo download link for same.

Long story short: I installed the older driver. When I rebooted the machine, the previously non-functional XR382CQK monitor worked like a champ in the miniDP port. I didn’t even have to lug my wife’s Dell 2717 into position instead.

A Further Bulletin from Engineering…

Here’s what one of the engineering team emailed to the group assembled to help me over this hump:

 I checked with our lab and there is a known recent issue with Nvidia’s latest driver 513.12 and later. There will be a P360 Ultra BIOS release by end of month to address the issue. However, the workaround in the meantime is to use driver 511.65.  The symptoms are similar to what Ed is seeing – driver crashes.

Given that insight, a quick confirmation that I was running 516.94, and a link to the download for that older driver version, I got straight to work. Problem solved! Nice to know the old school repair still works. Even nicer to get pointed at the last known working version by the Lenovo team.

Facebooklinkedin
Facebooklinkedin