Category Archives: Troubleshooting

Insider stuff, Recent Activity, Remote Desktop (RDP), Troubleshooting, WED Blog, Windows 11

Ongoing Reboot Issues Affect RDP

Leave a comment

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
Device drivers, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

Clearing X-Rite Error Proves Interesting

Leave a comment

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
Cool Tools, Device drivers, Insider stuff, Recent Activity, Troubleshooting, WED Blog

DDU Fixes GPU Driver Disasters

Leave a comment

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
Cool Tools, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

Web Extensions Stymie Input

Leave a comment

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
Device drivers, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

CPU Changed Boot Warning Nightmare

Leave a comment

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
Insider stuff, Networking, Recent Activity, Troubleshooting, WED Blog, Windows 11

Spectrum Router Roadblock Diagnosed

2 Comments

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
Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 10, Windows 11

Resetting CMOS Has Its Hurdles

Leave a comment

You’d think it would be dead easy. And to be fair, on some motherboards it is. But popping (or replacing) a CR2032 3V coin battery — especially when resetting CMOS — has its hurdles to overcome. At my age, clear visibility can get interesting. Then, there’s often limited space inside the PC case to reach the darn thing. In dealing with recent Secure Boot (and related CA 2023 boot certificates) recently, I’ve been reaching for the CMOS battery rather more often than not.

OK, Resetting CMOS Has Its Hurdles: Name Some…

Beyond the two already noted (visibility and space), I also bumped into various other impedimenta, including:

  • Removal techniques: new sockets may not yield to a fingernail, so I found a small flat-head jeweler’s screwdriver helpful
  • Timing: most guides say to leave the PC alone after popping the battery for anywhere from 10 seconds to 5 minutes. I made sure I had something else to do before removing the battery and erred on the “too long” side of things. Seemed to work.
  • Reinsert the old or replace with a new: If it’s been more than 3 years since I replaced the battery (or I can’t remember) I’ll replace rather than reinsert a CR2032. They typically cost US$5 or less, so if I have to remove it anyway, why not replace it, too?
  • Making room: On at least a couple of desktops, I have to remove the GPU just so I can SEE the CMOS battery holder. On any given laptop at least one deck has to be removed; sometimes other assemblies (e.g. keyboards or storage modules) must also go.

But when a PC goes truly off the rails — especially when BIOS or UEFI becomes inaccessible or non-responsive — a CMOS reset can often set things back to rights. That’s why I find myself digging for my replacement stash from time to time, so I can put a fresh one in to replace the older one at the same time.

Nothing says resetting CMOS has to be easy, here in Windows-World. But lots of times, it’s a necessary step in the troubleshooting process. So it goes…

Facebooklinkedin
Facebooklinkedin
Device drivers, Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

AMD Gets New Chipset Driver

Leave a comment

Here I go again. I read this morning on Neowin that AMD had dropped a new version of its chipset drivers, including the B550 in my Flo6 and RyzenOfc desktops. Time for an upgrade! I found what I needed at the Chipset Driver Release Notes 8.01.20.513 page (a 62.5MB download named amd_chipset_software_8.01.20.513.exe). After applying that file, AMD gets new chipset driver upon reboot. What happened on my ASRock system was a little more vexing…and complicated. Let me explain…

After AMD Gets New Chipset Driver, Comes a Reboot

The UEFI on my ASRock B550 Extreme4 motherboard is a little tetchy. Whenever the firmware or drivers get touched (updated or replaced), it tends to hang on a black screen after a reboot intended to flush out old stuff and bring in new. Sure enough, that’s what happened after the AMD chipset installer fired off a restart with my express permission.

I had to do a deep cold start to bring the motherboard back to life. That meant:
1. Hold the power button down until the system turns off
2. Turn off the PSU
3. Hold the power button down another 10-15 seconds to discharge any capacative devices
4. Turn off, then unplug the power cord from the PSU
5. Wait 2-5 minutes for everything to turn itself completely off
6. Plug the PSU back in, turn on its power switch
7. Use the front power switch to start the PC back up
Fortunately, that worked and the unit came back to life.

Checking the Install

I’m learning to make doubly-darned sure that an update actually gets applied, thanks to some recent misadventures with Secure Boot. I visited Device Manager and made sure no yellow triangle warnings popped up, nor did anything appear under the always-annoying “Other Devices” heading.

At Copilot’s urging, I also checked the install dates for all of my AMD drivers. Copilot also confirmed that those dates matched the latest ones in the afore-linked release note (and hence, should be current).

I used this handy PowerShell one-liner to elicit the data shown in the next screencap:

Get-WmiObject Win32_PnPSignedDriver |   Where-Object { $_.DeviceName -like “*AMD*” } |  Select-Object DeviceName, DriverVersion, DriverDate

Here’s the resulting output:

After checking these against the release notes, reported dates = current dates.

It looks like the chipset update got properly applied. Copilot tells me other UEFIs will reboot after a chipset update without the 7-step polka the ASRock board needed. I wish I had another AMD system around here to verify that claim. But here in Windows-World we don’t always get what we want. Good enough for now, I guess!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11, Windows Update

CU Aftermath: One TPM Update Elicits WTF?

1 Comment

Microsoft’s February 2026 cumulative update, KB5077181, brought most Windows 11 25H2 systems up to build 26200.7840. At least, that’s what I was expecting. But as I rolled out the update across a mix of systems here at Chez Tittel, I noticed something odd. My Lenovo ThinkPads and an ASUS Zenbook A14 quietly updated and rebooted into 26200.7840. The DIY desktop (built on an ASRock motherboard with a Ryzen 5800X) threw a TPM warning and required multiple reboots after a forced cold startup. You guessed it: that one TPM elicits WTF as I must respond to “Update Y/N” for things to proceed.

One TPM Update Elicits WTF, Others Don’t

Let’s unpack what happened. First, the update itself. KB5077181 is a standard cumulative update, but it also includes boot-chain changes that affect Secure Boot and TPM values. On systems with stable firmware and well-behaved TPM implementations, these changes get absorbed quietly. That’s what happened on my Lenovo and ASUS laptops. They rebooted twice and landed on build 26200.7840 without a peep. Copilot tells me that the first reboot is for a servicing stack update, the second for the aforementioned CU.

The ASRock-based Ryzen system, aka “Flo6,” had a different reaction. Upon reboot it froze on a black screen. After I cycled power and forced a cold boot, it presented a UEFI-level prompt. That prompt  warned about changes to the TPM and Secure Boot configuration, and asked me to enter “Y” to confirm, or “N” to deny. This signals that the Platform Configuration Register 7 (PCR 7) that tracks Secure Boot components has detected a change. The system requires manual confirmation to proceed and reseal the TPM, followed with an additional reboot. But man, is that a cryptic message or what? (It appears as the lead-in graphic above.)

Why this discrepancy? It comes down to platform differences. OEM systems like Lenovo and ASUS laptops benefit from tightly integrated firmware, drivers, and update pipelines. Their UEFI implementations are mature. Also, their TPM and Secure Boot configurations get validated against Microsoft’s updates. Thus, they handle PCR changes gracefully and typically reseal the TPM silently with no user intervention.

The ASRock Difference

ASRock, on the other hand, does things differently. Though their firmware is functional and generally reliable, but it’s not as polished or tightly integrated as enterprise-grade or premium OEM systems. ASRock tends to use more standard, out-of-the-box AMI firmware. It offers only minimal validation for Secure Boot and TPM changes. Combine that with AMD’s fTP (known to be more sensitive to boot-chain changes than Intel’s PTT), and you get a prompt for TPM confirmation after updates like KB5077181.

You Get What You Pay For

That’s not to say ASRock is bad. For enthusiasts and DIY builders, their boards offer decent value and performance. But when it comes to firmware maturity and seamless integration with Windows security features, they’re noticeably behind the big OEMs.

The takeaway? Platform matters. As Windows continues to evolve its security posture, particularly around Secure Boot, TPM, and boot checks, users should expect some variation in how different systems respond to updates. OEM systems generally offer a smoother ride. DIY builds like my ASRock-based Flo6, appear to need more attention and manual intervention.

For those who live in the trenches of Windows-World, it’s just another reminder of how things sometimes work, or not. The best antidote is to know your hardware, expect the unexpected, and keep recovery media handy, just in case something goes awry. I’m glad I didn’t need recovery for this update. Indeed, I started wondering when I had to cycle power for a cold start, and an extra reboot to get to the desktop.

Facebooklinkedin
Facebooklinkedin
Hardware Reviews, Insider stuff, Recent Activity, Troubleshooting, WED Blog

Zotac 4070 Shows Up Munged

Leave a comment

Got an email last night from the USPS, informing me that the Zotac 4070 card I ordered would be delivered by 6:30 PM. This morning I walked to the mailbox to retrieve that item. As you can see in the edge-on photo, the 800-lb gorilla had his way with the card during shipment. The front plate is badly bent. Worse, the right-hand fan (from the top) doesn’t spin freely, as it properly should. I’m asking for a refund, as the Zotac 4070 shows up munged.

If Zotac 4070 Shows Up Munged, Now What?

I’m ordering a replacement card. Given the issues finding a performance GPU that’s also compact, I’m “trading down” to get a 5060 model for my next try. I just ordered a Gigabyte RTX 5060 Mini from Amazon, for delivery tomorrow. In the meantime, I’m fighting with the vendor platform — Mercari, in this case — for a refund. Somehow, the sale shows as completed even though I hadn’t even had the card in my hands for 18 hours when that status made itself known. I’m hoping I’ll get the purchase price back, but I have a bad feeling…

As I opened the package, in fact, I saw the front plate had been savaged in transit. “That can’t be good,” I thought. It wasn’t. Gosh only knows what hit this unit, but it literally looks stepped on. I can only hope I’ll get a refund: we’ll see about that.

Tomorrow Is Another Day

Amazon will put the next candidate in my hands tomorrow morning. I’ve never had trouble with their delivery resulting in damage of any kind, let alone the mauling that the Zotac card took en route. Fingers crossed that I can get it installed, and Secure Boot working, on the upstairs B550/5800X PC. These things happen here in Windows-World. Several lessons learned from this encounter, none of them good. Sigh, and sigh again…

 

Facebooklinkedin
Facebooklinkedin