Category Archives: Troubleshooting

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.


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.


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


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!


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!


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.


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: 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…



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.


USB-C Port Choice Really Matters

Here’s an interesting discovery. Or maybe it should be called a “realization.” Yesterday, upon trying out my new Belkin and CalDigit Thunderbolt 4 docks, I learned that USB-C port choice really matters. In fact, my reported GbE issues with the Belkin Thunderbolt 3 port are probably related. Please: let me explain…

Why USB-C Port Choice Really Matters

Simply put, if you plug a dock into the upper USB-C port in the Lenovo X12 hybrid laptop it works as it should. Plug it into the lower USB-C port and the GbE connection disappears. Also, the device does not show up in the Thunderbolt Control Center app, either.

More details:

  • The Ethernet controller built into the CalDigit unit depicted in the lead in graphic is an Intel I225-LMvP. When the unit is plugged into the upper USB-C port it appears in Device Manager. If plugged into the lower USB-C port it does not.

  • When I plug the dock into the lower USB-C port, it vanishes from Thunderbolt Control Center, which then shows no attached devices. Interestingly, Windows still finds attached storage devices. But wired networking through the dock no longer works.

Extremely interesting!

What Does It All Mean, Mr. Wizard?

What it means is that on this Lenovo model, only one of its two USB-C ports also supports Thunderbolt (and it’s version 4, interestingly enough). Here’s my clue from the product family specifications page, which reads as follows under “Ports/Slots”:

    • USB 4 Type-C with Thunderbolt™ 4 (DisplayPort, Power Delivery and Data Transfer)
    • USB 3.2 Gen 2 Type-C

The reason why storage keeps working, but why networking and video — and presumably  other high-bandwidth connections — do not, is because Thunderbolt support is required for such things. If I’d still had a monitor attached to the X12 (I sent it off to school with my son) I might have figured this out faster. But now I know . . . and so do you! And it goes to show that sometimes, where you plug in really matters, even if the “gozintas” look the same.


Realtek Audio Console Goes MIA

There are two flavors of Realtek Audio drivers for Windows 10 and 11. The most prevalent are the High Definition Audio (or HDA) drivers. The less prevalent but slightly more capable are the Universal Audio Drivers (UAD). Confusingly, these show up in Device Manager as Realtek(R) Audio. More properly that would be Realtek® Audio, but DevMgr apparently doesn’t do metacharacters like the registered trademark symbol (®). Whatever you call it, the Realtek Audio Console Goes MIA in the MS Store.

Knowing When Realtek Audio Console Goes MIA

One used to be able to access this app through the Microsoft Store. No longer. Confusingly, the app says Realtek Audio Console in its title bar, but the Store listed it as Realtek Audio Control. Thus, for example, if you visit it at (a usually safe and reliable download source), its Microsoft Store download link is broken. Likewise, a direct search at the Store produces no results. Ditto for a search at the Realtek downloads page.

Thus it looks to me that it’s at least possible that Realtek is de-emphasizing the UAD side of its audio drivers. In the absence of statements of direction or intent, it’s only possible to speculate. But it looks to me like UAD drivers and the app console may be orphaned, and no longer supported.

A Driver Search May Tell…

In looking at UAD drivers for Realtek, I see only Nahimic variants for the last half-dozen versions at None of these work with the plain vanilla FF00 audio codecs on my now-aging Z170 Skylake motherboard. I do have a B500 AMD rig that supports this Nahimic stuff, though.  In a couple of weeks, I’ll probe this mystery further and see if the Audio Console is available (and working) for that set-up.

Right now, I have a working UAD set-up with drivers that are now about a year old (version 9215.1, dated 8/3/2021). I have been unable to find any newer variants that work. Ditto for a newer version of the Realtek Audio Console (or Control). Very interesting!