> If you would like too you can do system restore to restore some settings on your PC.
In a similar manner, nobody ever suggests "just removing" interesting malware - since properly checking if a system is actually clean takes so much more time and effort than a reinstall, you have to have a really good reason to not simply nuke the system from orbit just to be sure. (possibly before taking an image for future forensics/attribution).
The other issue is that if you try to dive in deep and fix the problem by trying out various things and running diagnostics etc, you may in the end still need to reinstall.
E.g. I have an issue where Thunderbolt ports suddenly stop working -- the symptom is that I hear the device connected chime immediately followed by the device unconnected chime. Event log is empty. Impossible to debug -- there's nothing else to tinker with. System restore worked.
Linux -- there is a kernel flag that forces the BIOS to power on the controller and whatever. Ohmygosh I had to open a terminal, but at least I didn't had to reinstall.
And please don't come with "given the choice of opening a shell and digging in or just reinstall, I would choose reinstalling 100% of the time", because then it answers the question of the OP.
I'll grant, however, that modern Windows often manages to be even more convoluted than that.
Has it already been the year of Linux on the desktop, or is that "next" year - I forget?
I have also often had issues that turn out to be driver issues, where a bug was already opened for the issue on some bug tracker, and the driver developers have already provided solutions in the comments. That kind of thing doesn't really happen on Windows.
User configurations are only half of the total (with the method above, the system configurations are lost), however, it's considerably less work to do.
This doesn't only apply to system corruption scenarios - upgrades also can use the same workflow (of course, the compatibility of the configuration files with new package versions is a separate matter).
Any of the mainstream operating systems are tremendously complicated, so free support is probably worth what you pay for it.
Let's say you administer an Exchange server and need to make a configuration change to a mailbox. Normally, the Information Store will cache mailbox state for up to 20 minutes and you'll have to wait for your change to take effect. But let's say you really really need that change to happen right fucking now, then what?
Well, Microsoft support has your back: restart the Information Store service. While effective, this will also boot everyone's MAPI connections from the server and consequently pop up a giant scary warning dialog to all your Outlook users. Good job there guys.
Fortunately, there are knowledgeable wizards casually dropping in to these support threads every once in a while who can give you a real solution. In this case, it's running `Update-StoreMailboxState -Database <dbname> -Identity <mailbox GUID>`. Yeah, Microsoft actually made a fucking powershell commandlet that does exactly the thing you need, but support has no idea it exists and just throws up their hands and tells you to interrupt the workflow of the entire organization and generate a bunch of calls to the help desk.
If I ever meet the person who posted that answer, I owe them a few beers.
Also, when searching, it's usually possible to find better search keywords. Searching for event log entry source + event ID helps more often than searching symptoms in a natural language.
I wonder why companies even bother running these - it’s not like they attract any kind of useful knowledge. It would be best if they disappear and clean up search results so communities with real, knowledgeable enthusiasts can rank higher.
Disable all your addons and create a new profile...
In my case, I correctly removed EN-US, but it turns out that most times when I connected via RDP Windows automatically readded the layout since it was available on the connected station.
It's possible to a registry key to disable this behaviour:
Goto HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout and add a new DWORD Key "IgnoreRemoteKeyboardLayout" with value "1".
This solved the issue for me, Windows stopped adding EN-US.
As far as I know, RDP doesn't send the letters to the server, but the keyboard event. So if both sides are using incompatible layouts, you could send "A" from your client but see a "B" on the RDP server.
I switched en-US for another en layout so it's not a serious problem for me there, but on non-English languages it can be an issue when the other side doesn't match at all, and maybe it's a little easier when Windows installs the layout automatically for the user.
This behaviour would be defencible if only Windows had informed the user, and allowed the remote desktop client to control it in advance...
There's also the case when the other side has a layout which you do want to use but do not have installed. I guess that's rather a rare case - if it's a desired layout, why wasn't it installed in the first place?
Perhaps MS can't update RDP so trivially, and is stuck with the wrong architecture for a good while. But at least they could ask before adding a keyboard layout. Or allow enabling/disabling this as an option on the RDP client rather than a registry change.
Another source of such issues is settings for default user account. There's a GUI deep inside control panel to copy profile settings to both default accounts: https://www.ilovefreesoftware.com/26/windows-10/copy-current... Try to configure these languages, and copy to both.
Also, if you're on a corporate network, it can be a group policy, or some other enterprise feature. When a PC joined a domain, domain admins can change all settings from the central location.
I wonder if the EN-US keyboard is actually a fall-through to the non-localized version when the localized keyboard fails to load.
I had to look through the entire registry for the key mentioned there though, I had to delete about 4 or 5 before the hidden US keyboard finally disappeared.
Note that that thread is from 2015. Maybe US based Microsoft would find the issue more urgent if it was a different keyboard than a US one, so that they themselves notice it (I guess right now they would not?).
I had to disable upgrades and I don't really want to format my already configured OS soon.
I am quite happy about the layout though :).