Category Archives: Troubleshooting

Power Outages Mung LAN Addressing

With clear skies yesterday, our house nevertheless took two power hits yesterday. The first lasted 15 minutes, the second 11 (had to reset certain appliance clocks both times). When I tried to remote into the ThinkStation P3 Ultra this morning, RDP wouldn’t connect. So I tried pinging the host name (Tsp3Ultra2) and got “destination host unreachable.” Pretty conclusive proof that power outages mung LAN addressing, since that very string worked fine yesterday.

If Power Outages Mung LAN Addressing, Then?

For the time being I’ve got Advanced IP Scanner open, and am using the “Tools” option for each network node to call Remote Desktop Connection. That tells me which PC I’m trying to get at, and uses its IP address to make things work. Good enough for now, I guess.

I’ve observed that the name table will gradually correct itself over a 24-hour period. Since our last outage happened just before 5 PM yesterday, that means I can return to using machine names for remote access later this evening. In the meantime, I have a decent workaround.

A quick check tells me that only some PCs were affected by the outage. Not surprisingly, the laptops (kept alive by batteries durng the outage) retain their machine name-to-address relationships. The desktops and mini-PCs (except Flo6, which is on a UPS) have all been renumbered.

Here in Windows-World, it’s always something. Yesterday, it was a quick pair of power glitches. Who knows what’ll hit me today?

Note Added Next Day

As I had suspected (or hoped), the machine names are now all working again. As is typical here at Chez Tittel, a 24-hour period is long enough for DHCP to work itself into usable shape. Now I know that a power glitch (or two) can upset that delicate balance. I’ll probably be reminded again sometime soon, now that thunderstorm season here in Central Texas is getting started. This time, I think the glitch came from construction work at the edge of our neighborhood where power goes from overhead to underground lines.

 

Facebooklinkedin
Facebooklinkedin

X12 Tablet Gets Clean Install

Something cratered the Lenovo ThinkPad X12 Detachable Tablet this weekend. I’d been screwing around with Secure Boot, recent updates, and more. When I sat at my desk Sunday morning, it was refusing to boot, and throwing error code 0xc0000428, which signals a winload.efi signature mismatch with what’s in firmware (see lead-in graphic). I did get the machine booted to recovery media on a UFD. I could’ve repaired and recovered the previous installation. But I decided that X12 Tablet gets clean install instead, so I could check a bunch of things out about a fresh, clean Windows 11 install. Here goes…

After X12 Tablet Gets Clean Install, Some Initial Checks

Having wrestled so much with Secure Boot lately, my first check was on that security layer. Indeed, Garlin’s check script revealed it was present, and more-or-less up-to-date. With minimal effort I was able to bring the X12 into full compliance with modern Secure Boot settings.

Next, I checked Smart App Control in Windows Security. It is currently set to Evaluation mode. I’m supposed to be able to switch between the On and Off states now. I need to finish configuring this PC and get an image backup tool in place, before I start fooling around with things. But the signs are promising. Right now SAC is working, and behaving just the way it’s supposed to work.

More About OOBE

After the post-GUI installation in Windows 11, the Out-of-Box Experience (OOBE) appears to guide users through final steps of the process. This time, I did get to choose the machine name I wanted (kept it at X12Hybrid) where it works properly. The network setup found my WAP right away, and I was off and running right away, too. It was also amusing to see how many, many backups I could’ve used when installing this PC (including an older X12 version dating back to 2022). But since I wanted a clean install experience, I skipped all that stuff.

Now Comes the Rest of the Job…

I’ve got to set up and customize the X12 to my usual liking. That’s probably going to mean an hour or two a day for the next few days. This afternoon I think I’m going to try using WinGet to export most of my app set from Flo6 to X12, and see how that works.

Stay tuned! It’s possible that things in my little corner of Windows-World are about to get interesting. If so, you’ll get more follow-up from  your humble correspondent. So far, so good, though.

Facebooklinkedin
Facebooklinkedin

Device Zombies Roam Among Us

Every so often, Windows throws you a curveball that feels less like a bug and more like a ghost story. One of the stranger ones I’ve run into lately is what I’ve started calling “device zombies.” This is a state where Windows believes a device is still alive, or the Microsoft Store insists it’s still alive and kicking. Here at Chez Tittel, I know I sent these devices back to Lenovo, Dynabook or Panasonic up to 5 months ago. That’s why I declaim, in shock and horror: “Device zombies roam among us!” Let me explain…

Proving Device Zombies Roam Among Us

In my case, I often get and return as many as a dozen computers a year on loan from their makers. You’ve read my unboxing, intake, and other stories about them. Right now, through the lens of https://account.microsoft.com/devices (that’s where you login to check devices registered to some specific MSA) I can see four Zombies plain as day:

  • T14Snap: A ThinkPad T14s Snapdragon based laptop I returned to Lenovo in November, 2025.
  • X13G6: A ThinkPad X13 Gen 6 intel based laptop I returned to Lenovo in January, 2026.
  • Flo6: The previous incarnation of my current production desktop based on the flaky and frustrating ASRock B550 Extreme4 mobo. I just decommissioned this over the weekend.
  • X40M2: A Dynabook (formerly Toshiba) Portege X40-M laptop that I returned to Dynabook in January, 2026

When I first checked this out over the weekend, I had 3 more such items showing, but I used the “Remove your device” pane shown for the X40M2 in the lead-in graphic to drive another stake in their hearts. Some of these appear to have caused them to shuffle off the device list, if not the mortal plane.

Sames Goes For Store, But…

The same page in the account. microsoft.com hierarchy has an entry for Microsoft Store device management. It purports to show a list of devices linked to that online asset. But mine keeps coming up empty, even though right now some attempts to install new software tell me I’ve exceeded my device limit. Note the text at lower left in the screencap that reads “Device limit 0 of 10” (no more new ones will be accepted).

It’s even harder to kill zombies when you can’t point an interface at them to order their removal. Thus, these might be considered zombie ghosts because they’re there, but you can’t seem ’em.

Time Cures All Ills, Even Zombies

Turns out that the Store and the MSA Device Log use telemetry to maintain the list of supposedly live items. Thus, when I sent the units back to their makers, they reset their “life timers” by up to 90 days when they fired them up (and opened my MSA login, even if they didn’t use it) before resetting and reimaging them for their next reviewer. At some as-yet-unknown future point in time, though, these machines should vanish from the device list for my MSA. I can only hope the MS Store will treat them the same way…

In the future, here’s what I need to do to prevent Zombies from remaining in my lists:

    1. Remove them from the list while they’re still under my control
    2. Reset the Microsoft Store (wsreset -i) to kill lingering cache associations
    3. Reset the PC so it can’t generate another login to my MSA

As with so much else in Windows-World, the best way to stay out of “Zombie trouble” is never to get into it in the first place. Going forward, I’ll be sure to keep that in mind.

Facebooklinkedin
Facebooklinkedin

Flo6 Mobo Switchover Succeeds

On Thursday and Friday of last week, I continued to fight with warm boot issues on my primary Flo6 desktop. The ASRock UEFI stubbornly refused to synch up the MS updates for Secure Boot with its own internal, stored values. Net result: I couldn’t restart Flo6. I could only traverse the shutdown/startup cycle through a deep, cold boot that sometimes required a CMOS reset. After lunch Friday, I took the plunge and tore the PC apart to switch out the ASRock B550 Extreme4 for an MSI Mag Tomahawk B550 WiFi Max. To my great relief and delight, that Flo6 mobo switchover succeeds admirably. That said, I started after lunch Friday and finished after 9M Saturday nite. Phew!

Lessons Learned, as Flo6 Mobo Switchover Succeeds

I made a couple of interesting mis-steps along the way that slowed things down, but the overall process was pretty straightforward. The teardown was easy, but it reminded me how much I now depend on reading glasses for close-up work, since last fall’s cataract surgery.

In putting the new build together, I saw that I’d failed to remove the clear plastic sticker on the CPU cooler during the previous build. Have to laugh, but the results are amazing: no sticker plus a fresh coat of thermal paste took CPU temps down from mid-50s to low-60s to a steady 31°C (Source: Speccy; HWiNFO shows various temps ranging from 32 to 42°C). All show serious improvements over the old build!

Putting the old parts onto the MSI Tomahawk board is where things got interesting. That board offers only LEDs for CPU. DRAM. VGA and BOOT.  I missed the two-digit POST code display on the ASRock mobo, which was more intelligible and easier to read. My first mis-step was mispositioning the 5800x CPU. I was 180 degrees off on the first try. Easily fixed, but took time.

My second mis-step was to put the GPU in the secondary PCIe slot. For some reason I was scared of the metal clad primary. But the PC wouldn’t POST that way, so eventually got that straightened out (the VGA LED did its job). The third stumbling block wasn’t a mis-step, it was more of a design flaw in the MSI board. It wouldn’t start up with more than 2 of the 4 orignal RAM modules (32 GB each) in place. That was a pure trial-and-error exercise.

All the Stops along the Way…

I also had to flash the UEFI (though they still call it BIOS flashing) before I could get past recognizing the CPU. This works with neither CPU nor GPU installed, from a specially formatted USB 2 flash drive. It’s like magic that the board can DIY this process, but it worked like a champ. From that point on, I moved from one proper set-up step to the next. CPU first, GPU second, and proper RAM configuration last.

Note: getting the RGB connector to seat properly on the mobo pins was the most physically challenging part of the build. Close second was working with RAM modules right up against the massive ThermalWright Assassin CPU cooler. But it all got sorted, by guess and by gosh.

Eventually (around 6:30 PM Saturday), I got the setup to boot and it took me straight into Windows, running the same image I’d been using on the old ASRock mobo. Boy, was I relieved to see that happen. And now, for some clean-up notes and good news. Read on…

Booting into Windows, and Beyond…

Once I got into Windows, I had to adjust for the mobo change. To activate Windows 11 Pro, I had to re-enter the same MAK it had already been running on (who knew?). To switchover from the old ASRock to the new MSI drivers, the system loaded an MSI Center app. It cheerfully offered to load “all” necessary drivers, but gave me control over which ones I chose. Needless to say, I skipped the fluff and stuck to device drivers and useful utilities only.

Then I ran Settings > Windows Update, which caught up other key drivers. A fresh run of the Logi app brought back my wireless mouse (I’d been forced to plug in a wired mouse during set-up because I mistakenly grabbed an MS wireless mouse instead of the Logi model, LOL).

Checking Secure Boot and CA-2023

The following image triumphantly confirms that with the current UEFI and recent MS updates in place, Secure Boot and certificates took care of themselves. I didn’t have to do anything!!!

The first PowerShell (PS) command [confirm-SecureBootUEFI] shows it’s in place and working. The second PS command tells me that CA-2023 is in place and in use. That was really the whole reason for the mobo switch, so I’m tickled to death it worked like it was supposed. Added bonus: I can restart, shutdown, and even use “shift+(Settings > Power Button > Restart) to get into the Windows Recovery (WinRE) environment. In short, Windows boot now works just like it should, and Secure Boot is properly doing its thing.

It was a long time coming, and cost me US$150 for the MSI mobo. But God: it was worth it. Case finally, finally closed. I’m thrilled!!!

Facebooklinkedin
Facebooklinkedin

Ongoing Reboot Issues Affect RDP

I’m still struggling with reboot issues on Flo6. Lately, I have to go through the infamous “new CPU detection” alert, then deny it, before I get into Windows 11. After multiple such reboots just now, I elected to stay logged in and get some work done. No such luck: my ongoing reboot issues affect RDP. On the way to a working session, I got the mysterious error window you see as the lead-in graphic.

Why Do Ongoing Reboot Issues Affect RDP?

It seems that multiple successive reboots in Windows 11 can impact RDP. This can lead to stale RDP capability caches, stale virtual device handles, TPM/Hello falling shy of full initialization, mismatched channel GUIDs, and more. In short, things get shook up and need to settle down.

What’s interesting — and amusing — about this error is that it’s not really an error. Closer inspection reveals it carries error and extended error codes that are null (0x0) in value. And indeed, right after the error window popped up, an RDP session into P16  opened up and worked like a champ.

What Happened Here?

Though it’s reported as an authentication error, it actually occurred during virtual channel negotiation between Flo6 and P16. Naturally, that indicates both devices were working just fine, thanks, and trying to get together. Copilot speculates — and I concur — that the most likely culprit is a Windows Hello redirection problem. (That’s mostly guaranteed by my turning fTPM off on one boot to kick start that process, then turning it back on.)

Boy howdy, things do sometimes get strange here in Windows-World, though. On the whole, I’d rather have a bogus error that fixes itself (or isn’t really an error) than have a serious glitch that requires further troubleshooting. I’ve had enough of that already today, thanks very much!

Facebooklinkedin
Facebooklinkedin

Clearing X-Rite Error Proves Interesting

I’ve got a terrific new loaner unit from Lenovo, a P16 Gen 3 Mobile Workstation. I’m still learning my way around this powerful beast of a laptop, as I discovered this morning. After login, I couldn’t help but notice that the built-in X-Rite Color Assistant failed — namely it opened a dialog box that told me the app couldn’t run because of an “unexpected error.” Mildly disturbing, and not terribly informative. Indeed clearing X-rite error proves interesting, as I first try–and fail–to fix the app through a basic uninstall/reinstall maneuver. Then I notice something…

Why Clearing X-Rite Error Proves Interesting

While I was checking over the P16 Gen 3 for clues, I noticed that Lenovo Vantage had a new firmware update pending. “Hmmm,” I wondered: “Maybe a firmware update (and reset) will also make X-Rite happy?” I quickly installed same (and then waited for the usual update process to grind to completion, and the post-install reboot to finish).

Guess what? The firmware update did the trick! After the reboot, I was able to launch the X-Rite Color Assistant. And it turns out it’s a “background app” on that Lenovo model (which uses a software or virtual color control, because the unit lacks a built-in color sensor). So I had to go through the Notification area, and right-click on the app to get it to open.

Below, you can see the About info from the app itself. According to Copilot, the UEFI/firmware refresh helped to bring X-Rite back to life because it resets the basic runtime environment, including the GPU to system connection. Good to know!

After a quick UEFI reset, X-Rite Color Assistant ran without error.

Here in Windows-World, the right ingredients for a happy and working laptop include the underlying firmware and drivers, as well as the OS and its software. Luckily for me, by fixing the lowest level stuff, the higher-level app came back to life. I’ll count this one as a win.

Facebooklinkedin
Facebooklinkedin

DDU Fixes GPU Driver Disasters

Today’s blog post is a paean to a tool named Display Driver Uninstaller, popularly known as DDU. It’s long been part of most Windows admin and power user toolboxes. DDU comes from Wagnardsoft, but well-known 3rd-party mirrors also include Guru3D and TechPowerUp. DDU remains a useful tool at completely replacing GPU drivers and their Windows infrastructure when graphics go wrong. It’s also a great way to switch from one GPU type to another. Say, from NVIDIA to AMD, or vice-versa, or even from one of them to Intel ARC. TL;DR version: DDU fixes GPU driver disasters and lets you switch types with little muss or fuss.

Why Say: DDU Fixes GPU Driver Disasters?

Over the past 9 days, we’ve seen an unusually fast series of NVIDIA Game-Ready GPU drivers (with one evanescent Studio driver on February 26). That Thursday saw both versions make an appearance that provoked immediate issues and outcry; version 595.59 was withdrawn less than two hours after its release.

Then on Monday, March 2, NVIDIA fired off Game-Ready version 595.71. Users soon began reporting diminished performance from this driver (especially for certain, GPU-intensive games). Further inspection (using tools like GPU-Z) observed that it imposed voltage caps on RTX 50-series GPUs to limit damage potential. At the time, I wondered if this wasn’t like putting “chewing gum on top of baling wire” to fix things.

On March 4, 2026 (Wednesday), NVIDIA dropped a hotfix to address these issues, in the form of 595.76. It addressed the voltage capping, and a variety of other game-specific glitches and gotchas. Since then, things on the NVIDIA Game-Ready driver front are steady, if somewhat uneasy. This is the first time in YEARS that the company has had two unstable Windows Hardware Quality Labs (WHQL) designated drivers follow in quick succcession.

Rollback Versus Deep Cleanup

So far, users have been able to recover from these updates without lingering issues. In the past, GPU driver glitches have resulted in black or stuttering screens, serious and ongoing display disturbances (aka “screen artifacts”), driver store damage, or bothersome system or GPU installer instability or crashing. When those things happen, that’s when DDU comes into its own. It cleans up all of the old GPU driver stuff and gets rid of whatever’s causing problems, then lays down a brand-new, clean and (hopefully) reliable replacement runtime to get your GPU(s) working properly once again. Hopefully, it’s obvious this capability also makes DDU excel at “out with the old, in with the new” actions when switching from one GPU type to another.

Did the recent NVIDIA debacle call for DDU? No it did not. I personally observed that the rollback facility in Device Manager took my system back from 595.59 to 591.74 (Studio). Other users have consistently reported that Game-Ready drivers also rolled back successfully as well (591.86 in most cases).

Even though this latest spate of Game-Ready drivers has caused some commotion, it hasn’t seemed to cause much need for DDU. Not this time around, anyway. But it’s good to know that DDU is out there should you need it. Or should you be switching from one GPU type to another. Here in Windows-World it’s better to have such tools and not need them, than to need them and not have them!

Facebooklinkedin
Facebooklinkedin

Web Extensions Stymie Input

While trying to conduct a cash transfer online yesterday, I ran into an interesting — and new (to me, anyway) — problem. In attempting to provide account and identity information I found myself unable to enter data into the very input form that was soliciting same. “Hmmm,” I wondered to myself, “Why is this not working?” So I decided to ask Copilot. It immediately informed me that things such as auto-fill. password managers, and related “conveniences” can step all over input fields inside certain web pages. The TL;DR diagnosis, put succinctly, is some Web extensions stymie input.

Copilot recommended that I open an incognito window, and try again. Guess what? That worked like a champ!

Why Web Extensions Stymie Input — In Some Cases

In my case it looked like a combination of Chrome auto-fill and the Norton Password Manager were conspiring against the input page to prevent it from seeing and handling my input as it should. As soon as I got those things out of the way, the input problems disappeared.

I’ve been building websites and writing about markup languages for over 30 years now, and this is the first time I’ve run into this phenom. Apparently I’ve been incredibly lucky, because it happens on a lot of websites, especially those built to handle multiple languages and character sets. It just so happens this particular gotcha never bit me until yesterday, when it bit hard (and drove me just a  tad bonkers).

KISS Remains a Valuable Approach to New/Unfamiliar APIs

KISS is, of course, the acronym for “Keep It Simple, Stupid!” It’s a good approach to keep in mind when working with new and unfamiliar apps, user interfaces, and the code beneath those skins. By simplifying the text handling the browser performed when providing input, I allowed the target web page to do its job without lots of other stuff going on in the background.

A simple, straightforward text entry environment let the web page accept input straight from my keyboard, with no extra processing or data delivery. Apparently, that was just what it wanted or needed to get the job done.

Here in Windows-World, not stepping on yourself is often the key to a successful user experience. Once my browser got itself out of the way, the web page was able to take it from there. I’ll count that as an unqualified success, and an interesting learning experience.

Facebooklinkedin
Facebooklinkedin

CPU Changed Boot Warning Nightmare

This morning I noticed external audio wasn’t working on my Flo6 desktop. I quickly went down a rabbit hole with audio drivers and such. Along the way, through a series of a half-dozen reboots, I noticed the fTPM “CPU changed” message kept popping up. At first, it was mildly annoying. But when it kept repeating I found myself stuck in a “CPU Changed” boot warning nightmare. How to escape?

Note on an AMD mobo fTPM is a firmware Trusted Platform Module, which resides inside a Platform Security Processor on the mobo. It provides the same functions as a discrete hardware TPM. It’s been bugging me lately, as I will relate…

Ending the “CPU Changed” Boot Warning Nightmare

Interestingly, the fTPM “CPU changed” message can appear even when the CPU has not been replaced. It shows up when the firmware detects a mismatch between the stored fTPM data and the state reported by the Platform Security Processor. This mismatch can happen during normal use. It can also happen after a firmware stall or a power loss. The message is confusing because it suggests a hardware change. In most cases, nothing is wrong with the CPU. The system is only trying to protect the integrity of the TPM state.

To say that Flo6 shows this message more often than other systems is an understatement. It happens a lot, and the reason is simple. Flo6 has a sensitive trust chain. It depends on the Platform Security Processor (PSP), the Embedded Controller (EC), and the BIOS staying in sync. If any part of that chain resets at the wrong time, the fTPM state can fall out of alignment. When that happens, the firmware cannot confirm that the stored TPM data belongs to the current system state. It then shows the prompt and waits for user input.

What Makes Flo6 My Problem Child?

This message appears most often after a forced shutdown. It can also appear after a firmware stall or a long power loss. If the system loses power while the PSP is active, the fTPM state may not save cleanly. On the next boot, the firmware sees the mismatch and stops to ask for confirmation. This is a safety feature. It prevents the system from using TPM data that may not match the current hardware state.

Flo6 also shows the message after a failed warm boot. A warm boot will not fully reset the PSP. If the PSP is left in a partially updated state, the next boot may not match the stored fTPM data. The firmware then shows the prompt again. This is why the message sometimes appears after a simple restart. The system is not failing. It is only trying to confirm the trust state.

Responding to “CPU Changed” with Yes

Choosing Y tells the firmware to restore the stored fTPM state. Choosing N tells it to discard the stored state. On Flo6, Y is usually the correct choice. It keeps the system stable and avoids repeated prompts. N is only valid when the CPU has changed. If the CPU has not changed, N can cause more trust state mismatches. It can also trigger BitLocker recovery if BitLocker is enabled.

The “CPU changed” message does not mean the CPU is faulty. It does not mean the BIOS is corrupted. Nor is the system unsafe. It only means the firmware wants to confirm the TPM state before it continues. Flo6 is more sensitive to this check because of the way its firmware handles power loss and warm boots.

That’s why I’m getting ready to swap the ASRock B550 Extreme4 mobo for an MSI MAG Tomahawk model. I read that its UEFI is more stable, robust, and less prone to fTPM mismatches. Here in Windows-World, an escape from the frying pan can lead into the fire. Fingers crossed that the upcoming rebuild ends this nightmare.

Facebooklinkedin
Facebooklinkedin

Spectrum Router Roadblock Diagnosed

Sometimes, the biggest obstacles in tech aren’t the bugs in your code. Rather, they’re the invisible hands meddling with your network traffic. I recently ran into one such gremlin while trying to install the .NET Core 3.1 Desktop Runtime on a Windows machine. What should have been a simple download turned into a multi-device diagnostic rabbit hole, all thanks to a Spectrum-supplied SAC2V1A router and its overzealous filtering behavior. After I looked intently at its behavior, this spectrum router roadblock diagnosed itself through its (lack of) formatting. It was weird, though…

Once Spotted, This Spectrum Router Roadblock Diagnosed

Things started innocently enough. I needed the .NET Core 3.1 Desktop Runtime for a legacy app. I grabbed the download URL from Microsoft’s official archive and pasted it into Chrome. Instead of a download prompt, I got a blank page with a single, cryptic line of text:

GatewayExceptionResponse

This was odd: it included no HTTP error code, no branding or sourcing, and no explanation. Just that one-liner. I tried again in Edge. Same result. Then I fired up PowerShell and used Invoke-WebRequest. Still the same string. At this point, I suspected something was intercepting the request — but what?

The Plot (or Confusion) Thickens…

I tried the same URL on a second Windows machine. Same result. Then on an iPad. Still blocked. That’s when the lightbulb went off: this wasn’t a device issue. It was a network issue. To test the theory, I pulled out my iPhone, disabled Wi-Fi, and switched to 5G cellular. Then came the real test: typing a 60-character URL — a delightful mix of letters, numbers, and dashes — into Safari by hand. No copy-paste. No QR code. Just raw thumb labor. After a few typos and some muttered curses, I finally got it right. And lo and behold, the file loaded just fine.

Now I knew for sure whence this anomaly issues. The file wasn’t broken or MIA. Microsoft’s Content Delivery Network wasn’t off the air. Clearly, this was a problem coming from the LAN, right at the boundary.

A Ray of Light Shines on the Culprit

With a bit of digging, I discovered the culprit: Spectrum’s Security Shield. This cloud-managed feature is baked into the SAC2V1A router. It’s designed to protect users by blocking malicious or suspicious content. Unfortunately, it seems to think that downloading an out-of-support Microsoft runtime from a legacy CDN is suspicious enough to warrant a silent block.

Let me explain what “silent block” means here. Instead of an HTTP error code or an explanatory “I can’t do that, Dave” message, Security Shield simply emits the string:

GatewayExceptionResponse

No HTML document, no context, no wrapper of any kind. It looks like some kind of escaped error message, in fact. Here’s the real gotcha: one can’t manage this router’s behavior from the web interface anymore. One has to do it through an Android or iPhone mobile app. For the nonce, I’ll forgo that dubious privilege (though I could tackle it on the iPad, where I can at least run an external Bluetooth keyboard). Now that I know what I’m seeing, and why, I can live with this once-in-a-while weirdness.

If This Happens to You…

Should you ever see GatewayExceptionResponse pop up in tiny print at the upper left-hand corner of an otherwise blank browser, you’ll know what it means. The router is gatekeeping what it thinks is a dangerous resource from entering your LAN. I found a different download source (dotnet.microsoft.com) and grabbed what I  needed. You should be able to sniff out an alternative if you really need it. If you don’t this could be your clue to leave it alone.

And boy, howdy, is that ever the way things occasionally go in Windows-World. You ask for something, and get a cryptic response in return. Then, you figure out what it means and go forward from there. Case closed!

Facebooklinkedin
Facebooklinkedin