Saw a fascinating question on TenForums this morning, as I was making my “morning run” though the new threads there. It appeared in a thread named “ntuser.dat” and read “Why do I have so many ntuser.dat files?” Being one to look for evidence any time Windows quirks or behaviors are described, I immediately fired up voidtools’ (Search) Everything to look for that string in my file system. Right now, it turns up 60 objects, of which many are logs or pending registry transmissions (files of type .regtrans-ms). But there is also one file named ntuser.dat and eight more files named NTUSER.DAT. Obviously, there’s something interesting and useful going on with all these copies. And, as it turns out understanding NTUser.dat in Windows 10 hinges on understanding user profiles and typical accounts on a Win10 systems.
Of the 60 items with “ntuser.dat” in their names, these nine items shown take that name precisely on my production PC. What gives?
Why Bother Understanding NTUser.dat in Windows 10?
As it happens, each and every user profile created on a particular running instance of Windows 10 has its own NTUser.dat file. This file contains personal files and preference settings particular to each such user. As you can tell from looking at those files on my production PC (depicted in the preceding screenshot), this includes default and “behind-the-scenes” accounts as well as user accounts. That’s why we see a system account (…System32\Config\systemprofile), various service accounts (… NetworkService and …LocalService), and dot-NET accounts (dot-NET v4.5 Classic and dot-NET v.5), plus Administrator, Default and DefaultAppPool accounts. The only real user account is C:\Users\etitt. It reflects my Microsoft Account, which starts with the 5 characters “etitt”.
As it also turns out, messing with files with this name is NOT a good idea. Deleting an NTUser.dat file destroys the associated account’s preferences and settings and may even corrupt the associated user profile. Each such file has one or more backups, which appears as a file named NTUser.dat.log. If an error occurs in the master copy of NTuser.dat, Windows can use one or more log files to correct it. NTUser.ini files describe roaming profiles used in networked environments. You can rename this file NTUser.man. But that changes the user profile from a user-controlled profile to a locked-down profile that users can alter only temporarily (changes are not saved when the user logs out).
Writing the NTUser.dat happens during login; essentially, it’s a copy of the Windows Registry’s HKEY_CURRENT_USER hive. The contents of the user profile changes constantly over time: it reflects changes that occur while Windows is running. Windows size and position, for example, changes each time you open, move, or resize an application window. And that’s just the tip of a very large iceberg of data that goes into keeping constant track of user activity.
How NTUser.dat Changes
Though user settings, preferences, and so forth change at runtime, NTUser.dat stays static. Rather, those changes go into a raft of .regtrans-ms files that Windows 10 creates. Windows 10 processes these files whenever a user logs out, or the system shuts down or restarts. This controls and manages Registry writes, much like a “database commit” operation. (Note: database commit is a complex and interesting concept with many wrinkles, with much thought and effort required for proper implementation. For now, this means “changes either happen completely, or they don’t happen at all”. That keeps databases — including the Registry, in this case — consistent at all times.)
Thus, even when an uncontrolled shutdown or a BSOD occurs, NTUser.dat remains OK. User settings and preferences changes from the preceding session are lost. But user profiles remain intact and consistent.
I completely agree with long-time TenForums VIP and Guru member Bree (identified in the “ntuser.dat” thread mentioned at the outset of this blog post). Here’s his take on messing with or deleting files named NTUser.dat: “Best leave them alone then.” Well said, and advice worth following!
Just yesterday, I had an article go live on ComputerWorld. Its title explains its focus: “How to fix Windows 10 with an in-place upgrade install.” I’ve already gotten a couple of emails from readers informing me they tried this, and get only a clean install as an option when they fire off setup.exe. There are many reasons why this can happen, all of which are enumerated in that selfsame story. (See the section labeled “Sounds to good to be true; what’s the catch?”) But there are ways to check current Win10 for in-place upgrade repair to make sure the ISO you use will work with the running image. I’ll enumerate them here, to help would-be repair-persons succeed in their repair attempts.
How to Check Current Win10 for In-place Upgrade Repair
The conditions that must be met include specific items for the image that’s running and the image from which repairs are made. I’ll march through most of these one at a time in the sub-sections that follow, but will dispatch a couple of them here immediately. First, to run setup.exe in Windows 10, you must be logged into an administrative account. But because you must be able to run cmd.exe or PowerShell as an administrator to execute most of the following commands, I take that as a given for anyone who attempts an in-place upgrade for repairs. Second, to attempt an in-place upgrade for repair purposes, the OS must be running well enough for setup.exe to run to the point where the system reboots for the first time. After that, the installer takes over and the old OS is no longer in charge of the PC.
Third, the system drive (the SSD or hard disk on which Windows resides) must have enough free space for repairs to complete. How much free space is that? It’s about 9GB more than the space that Windows itself consumes on disk. According to WinDirStat for my production PC, for example, that comes to 28GB (18.9 GB for Windows 10 and another 9GB for workspace, rounded up).
Determine Win10 “Bittedness”
Windows 10 comes in 32-bit (x86) and 64-bit (x64) architectures. You can check this at the command line by typing wmic os get osarchitecture. Here’s what comes back in response on my production PC using PowerShell:
The output clearly states that this PC is running a 64-bit architecture. That means the chosen repair image must match. The ISO one grabs to use for repair will always include its bittedness. You’ll be asked to explicitly choose either a 32- or a 64-bit download.
Get Win10 Version/Build Info
You can use the built-in Win10 utility winver.exe to obtain this information. You can run this from the start menu or type the program name into the administrative command prompt or PowerShell window. Either way, it’s going to open in its own Window on screen, like this:
As you can see, the version is identified as 1709, and the build number is 16299.309. Don’t close this window just yet, it also provides information for the next sub-heading as well. When you grab an ISO for repair it will be identified primarily by its version (build) number. That means you’d have to download an ISO numbered 16299 or higher, for the build identified in the preceding screen capture. Right now the current Win10 Enterprise Insider Preview build is 17115, as I write this post.
Get Win10 Edition Info
Notice the line in the preceding window immediately following the © Copyright notice. It reads “The Windows 10 Enterprise operating system…” The fourth word in the sentence identifies the edition. Thus, a Windows 10 Home install would say “The Windows 10 Home operating system…” instead. Likewise for Pro and Education editions. You can also type wmic os get caption to produce this information as well. Here’s what that looks like from PowerShell:
As you can see, this identifies the edition as “Microsoft Windows 10 Enterprise.” This is the selfsame edition that must be used in any attempted in-place upgrade repair install. The name of the ISO usually includes this information when grabbing one to use for repairs. The edition is also identified explicitly when downloading an ISO for Windows 10, so pick one that matches what’s running.
Get Win10 Language Info
The deployment image servicing and management (DISM) command can report on language information for Windows images, on and offline. Checking the language information for the running image is easy, but the output is verbose. The DISM command to use on a running image is DISM /online /get-intl. Here’s the command and its output from PowerShell:
The value for “Default system UI language” is “en-US.” This means the running OS’s language is English as spoken/written in the United States. Thus, the corresponding ISO to download is labeled “English” online. Other languages (or English versions) are labeled more explicitly.
Grabbing an ISO for Repairs
To obtain Current Branch ISOs, please visit the Download Windows 10 page. For Insider Preview ISOs, please visit the Windows Insider Preview Downloads page. For older ISOs, I find HeiDoc.net and its Windows ISO Downloader absolutely invaluable. (It grabs only official Windows ISOs from Microsoft.com despite its apparently dodgy appearance and Asian location). I could download and use this ISO for repairs on my production PC:
Notice it includes the edition (“Enterprise”), bittedness (“x64”), language (“en-us”), and build (“17115”) in the filename. Good stuff! It tells me enough to let me know if I have a workable match or not. Your chosen ISO’s filename should do the same for you.
Late yesterday, another post on the Windows Blogs for Windows 10 appeared. It offers additional news and insight, and something of a progress report, on Spectre and Meltdown issues. It’s from John Cable, MS Director of Program Management, Windows Servicing and Delivery. The title reads “March 2018 Windows security update — Expanding our efforts to protect customers.” But it isn’t until you get to the second heading that things get interesting. Labeled “Expanding … coverage … to address Spectre and Meltdown vulnerabilities” it tells us MS offers new Spectre updates. A bit of digging is required to understand what’s going on here, though.
Understanding How MS Offers New Spectre Updates
Bottom line: coverage for microcode updates through the Microsoft Catalog is expanding. For a full list of covered items, one is advised to consult KB4093836. The short list is Skylake, Kaby Lake and Coffee Lake processors. You actually must visit KB409007 to see that list or a download link from the Microsoft Update Catalog. All that said, I applied that update to my Skylake production desktop without difficulty. I didn’t notice any perceptible performance delays added thereby, but my day is still young!
Where does this leave the world in terms of Windows coverage for Intel processors, one might wonder? According to Wikipedia’s “List of Intel Processors,” not very far. Most of those processors came out some time after the start of 2015. The list of major CPUs by family name has the following timeline:
Sandy Bridge (2007) → Ivy Bridge (2012) → Haswell (2013) →
Broadwell (2014) → Skylake (2015) → Kaby Lake (2016) → Cannonlake\Coffee Lake (2017)
Only the items in red are covered for this vulnerability. My two Lenovo laptops have Sandy Bridge (i7-2640M) CPUs. The Surface Pro 3 has a Haswell (i7-4650U). The Dell Venue Pro 11 7130 likewise Haswell (i5-4210Y), and my Dell XPS 2720 again Haswell (i7-4770S). My production desktop is Skylake (i7-6700). The boss’s mini-ITX has an Ivy Bridge (i7-3630QM), and the boy’s desktop has a Haswell (i7-4770K). That means that here where I live and work, only 1 in 8 machines is currently covered. Covering Haswell takes care of half the population. Lenovo promises to cover Sandy Bridge as soon as it can. But if MS doesn’t issue an Ivy Bridge update, that machine may never get coverage: Jetway, the mobo maker for that unit, shows little or no inclination to join the dance.
I sincerely hope that Microsoft will dig back at least two more steps on the preceding timeline. That means providing coverage for at least Haswell and Broadwell processor families. Ideally, I’d like to see them go all the way back to Sandy Bridge. But, as always, only time we’ll tell. We’ll see!
Now we’ve got proof of the next version name and build number for Windows 10. It’s now showing up in the so-called Skip Ahead release (Build 17618). If you run the Get-VMHostSupportedVersion PowerShell cmdlet on that build, it confirms that terminology and equivalence quite visibly. Of course, that’s why I entitle this post 1803 equals Spring Creators Update. Here ’tis:
The final line equates 1803 and Spring Creators Update with version 8.3.
If 1803 Equals Spring Creators Update, Does That Really Mean March 2018?
Probably not. In fact, the last few releases have gone public the month after their four-digit version identifiers. Thus, for example, 1709 appeared in October 2017, and 1703 in April of that year. Likewise, 1607 showed up in August 2016. To be fair, though, 1511 did appear in November 2015, and 1507 just barely squeaked out in late July of that same year.
All this chewed over, I’d pretty much assumed that 1803 would appear in April rather than March. But I’m hearing rumors that the actual public release date for 1803 could be as soon as March (or what the number says it should be: 3rd month of 2018) to as late as June (3 months behind). As usual when a feature upgrade is approaching “real soon now,” MS isn’t saying just yet. We will have to find out soon, though, as time marches ever forward.
I upgraded my Dell Venue Pro 11 to Insider Preview 17115 recently. This morning, when I got into my office I tried to remote into that PC. It didn’t come up either in Remote Desktop Connection or when using NirSoft’s FastResolver to scan my LAN. “Oho!” I thought to myself, “I bet the network got reset from Private to Public.” And indeed, that was true. But the Dell 1537 a/g/n adapter was also showing an exclamation point in DevMgr, with status “Device could not be started.” So I knew something was out of whack, and driver repairs were needed. And that’s how I can confirm that the post build 17115 driver fix routine still works.
Digging into the Post Build 17115 Driver Fix Routine
First, I simply tried the right-click “Update driver” menu option for the device. No joy. Next, I visited the Dell Drivers & Downloads page, where the built-in scanner (Dell Detect) used my service tag to look up machine specifics. There I found exactly what I was after:
This Dell installer launches the Qualcomm/Atheros driver update facility. This comes with several options to
- Update the installed driver
- Uninstall the current driver
- Install a new driver
As fate would have it, I ended up exercising all three options before I succeeded in restoring the 1537 to working status. First, I tried update the installed driver (which required a reboot). But even after a reboot, the exclamation point and the same error message persisted in DevMgr. So I opted to uninstall the current driver (which required another reboot). Then, I performed the analog to a “clean install” from the driver download package. And yes, that meant a third reboot.
But when the machine came back up, and I got back onto the Windows 10 desktop, I was prompted to supply wireless login credentials. And indeed, the driver and its associated device were working once again.
Working through the Driver Fix Routine
This multi-step approach to fixing driver issues has worked for me on dozens of Insider Preview builds since I got going with Windows 10 in October, 2014. That’s so long ago, in fact, that they called it the Technical Preview back then. You can memorize the sequence of steps as “Repair-Remove-Reinstall” if you like, to summarize what you must go through to fix most driver difficulties.
Sometimes, Step 1 is the only step that’s needed. Other times, you might even have to find and use a third-party utility to uninstall (like guru3d’s display driver uninstaller for graphics cards) a busted driver in Step 2. And when Step 2 is necessary, that normally makes Step 3 mandatory, too. However, you can try the “Scan for hardware changes” Action menu item in DevMgr after Step 2, if you’re feeling adventurous.
However you slice it, the driver fix routine should see you to a working driver most of the time. When the routine fails, it may just be because the underlying device has hardware issues, so don’t discount that possibility.
OK, then. I’m back from the Microsoft MVP Summit, and still catching up from all the buzz and running around. One recurring theme from the conference that is unclassified is the enduring value of telemetry. That’s the data that Windows 10 constantly ships back to HQ, to report on what systems and applications are doing. Various Microsoft mavens made the point that telemetry provides useful and important information. I heard this same message from numerous OS developers, applications folks, and security types. When MS foils coin mining in a big way, it’s obvious that telemetry can be a real system-saver.
The darker the country, the higher the Dofoil impact.
[Source: Microsoft; Click Image for Full-Sized View]
How Telemetry Translates into MS Foils Coin Mining
As reported at Infosecurity Magazine on March 8, MS detected a “massive and widespread” campaign that might have compromised half a million PCs or more. When the company detected — through telemetry from Windows Defender — a large number of sophisticated Trojans on March 6, it knew something was up. Over the next 12 hours, in fact, Defender fended off more than 400K new instances of those same Trojans. 73% of the reports came from Russia, 18% from Turkey, and 4% from Ukraine. They all pointed to a new strain of DoFoil (also called “Smoke Loader”) in the wild. DoFoil is popular because it uses the NiceHash function. This allows it to mine for a variety of cryptographic currencies. These particular samples mined Electroneum coins, but it could have been Bitcoin, Ethereum, or others.
The story quotes a March 6 Microsoft Secure blog post entitled “Behavior monitoring combined with machine learning spoils a massive Dofoil coin mining campaign.” Please read that story for all the interesting and intricate details of this clever and intricate attack. My point is that MS was able to use telemetry data to identify this outbreak, and to make sure its defense mechanisms could handle it and fend it off. If that telemetry data hadn’t been available, MS would have had to react to the attack after the fact. And because clean-up and repair are so much harder, more time-consuming, and expensive, that would have not been good at all. The following chart shows how telemetry drives recognition and response through machine learning:
The MS caption for this figure reads “Layered machine learning defenses in Windows Defender AV.”
[Click image for full-sized view.]
Again, if it weren’t for telemetry providing the data to feed the analysis and power those defenses, AI and machine learning would have nothing to work on — especially not in anything close to real time. And that, dear readers, is a compelling illlustration of why telemetry is valuable and important stuff!
I’ve been here in the Seattle area since Saturday afternoon, to attend this year’s Global Summit for Microsoft MVPs. As a recently-awarded Windows Insider MVP for 2018, it’s my pleasure and privilege to hang with a truly stellar group of technophiles and ubernerds, each of whom specializes in one or more Windows platforms and technologies. We’re here to learn more about where the colossus of Redmond is heading, and to provide feedback about the company’s many products, services, and programs. I’m not allowed to talk details about technical stuff because of a draconian but entirely understandable NDA to which I had to agree so I could attend this shindig.
Talk about a wake-up call! Microsoft says it in cappuccino foam this morning.
What I Learned During Day 1: Global Microsoft MVP Summit
Even so, there’s a lot to talk about anyway. I’ve learned that the real impetus of the Insider program is to obtain feedback from the 2M+ members of that program. Indeed, user input through the Feedback Hub is just as important as the telemetry that Microsoft collects. However, user feedback usually talks about the symptoms that tell them that an issue or problem exists. Fortunately, telemetry helps document (or at least point to) causes, problems, or events that help to diagnose such things. Thus, telemetry often leads developers to possible solutions, fixes, or workarounds.
Among other things, this means that turning telemetry off in Windows simply deprives Microsoft of the data it needs to find and fix problems. I’m pretty sure the company doesn’t care about this data except in the aggregate. Thus, those who choose to turn telemetry off — as is their inalienable right — must recognize that they’re also limiting the chances that MS will find and fix problems that bedevil their PCs. That’s because the company prioritizes faults and issues to fix by the numbers. When telemetry is turned off, those PCs cannot add to those numbers, and reduces the counts that drive fault and issues prioritization.
How to Boost the Value of Your Feedback
So please, leave telemetry turned on. Use the Feedback Hub, too, and if you do, follow these simple guidelines:
- Give your feedback item a descriptive title that identifies or points to a problem or issue
- Provide as much detail in describing problems or issues as you can
- One feedback report per individual problem or item, please. Different problems or items go to different groups on the Windows team. Thus, keeping them separated makes such reports easier to route and track.
Who knows? You may even get an email from MS that tells you a bug or issue you reported is fixed!
Funny that I posted status about the Spectre Meltdown firmware updates yesterday. No sooner had I finished my post than word appeared that MS had released KB4090007. Entitled “Intel microcode updates” it provides a round of microcode fixes for these infamous vulnerabilities. This particular code targets 6th generation Intel processors in particular — namely, desktop and mobile Skylake processors. Right now, MS offers Spectre Meltdown updates via Catalog only, in fact. Of course, that means the Microsoft Update Catalog, where the 32- and 64-bit versions of KB4090007 are currently available.
If MS Offers Spectre Meltdown Updates Via Catalog, Should You Grab Them?
If you have a Skylake system, by all means grab this update. I did, for my production PC with its i7-6700 CPU. The download, install, and reboot process all took less than 5 minutes, all told. I don’t notice any degradation of performance, either. Both boot and startup took the usual amount of time, and performance on the desktop seems dramatically unchanged. So much for dire warnings about the runtime consequences of the firmware update — at least for the moment. We’ll see how things fare over time.
The Ashampoo item (top) is brief and to the point, buth the intel item (bottom) has more “geek chic!”
Given foot dragging from OEMs as the rule rather than the exception, I’m glad to see MS jumping in with updates to help out. I’m hoping that somebody will come out with firmware updates for my other Asrock motherboard Z97 Fatal1ty Killer and its Haswell i7-4770K CPU. If not Asrock (as seems increasingly possible) then perhaps Microsoft? Go for it, guys, say I.
I’ve been blogging about firmware updates to address the Spectre/Meltdown vulnerabilities since early January. Today’s the first of March, so it seems appropriate to report back in on what’s happening. Some vendors — most notably, Dell and Microsoft, in my case — have been pro-active and forward about posting solutions. Others — like Lenovo — have done a great job of announcing their intentions to post upgrades. Alas, they haven’t actually posted much of anything just yet. Too many — which includes Asrock and Jetway in my case — have been more or less mum on the topic of updates until now. And that, my friends, is why I say that firmware update proceeds at glacial pace where these vulnerabilities are concerned. Sigh.
Here’s what Lenovo says about my two laptops (edited down from their monster-sized original).
More Details on How Firmware Update Proceeds at Glacial Pace
Now I’ll get into the details of the systems I’m taking care of these days, by the numbers
- Surface Pro 3 (Haswell): MS rushed out a firmware patch within a few days of the early January announcements. It worked OK for a while, but then I started having frequent GSODs. A newer firmware patch released in early February took care of that.
- Dell Venue Pro 11 7139 (Haswell): Dell released one BIOS update in late January. It worked OK but I had to pop out the battery to get the machine to boot, either from shut down or restart. A newer patch in mid-February fixed that issue.
- Dell XPS 2720 All-in-One (Haswell): Dell released a firmware update for this earlier this week (some reported finding this yesterday; I installed it this morning). Working OK so far.
- Lenovo T520 laptop (Sandy Bridge): Lenovo now includes this laptop on its list of platforms for which a firmware update is scheduled, but there’s no telling when that’s going to occur. I’m not holding my breath, but I am tickled they’re going to support a CPU this old.
- Lenovo X220 tablet (Sandy Bridge): Although this unit has the same CPU as the T520, Lenovo included it on their platform list about a week sooner than it added the T520. Both of these machines, though 6 years old, remain total workhorses. I use them all the time.
- Two Asrock motherboards grace my household: a Z170 Extreme7+ and a Z97 Fatal1ty Killer. So far, Asrock is mostly mum on the subject of firmware updates. No idea when this is going to occur, but I’m hopeful that both of these newer systems will get a firmware update someway, somehow.
- Jetway Mini-ITX (Ivy Bridge): Now we’re getting out there in the mists of time. I haven’t checked JetWay’s website because I don’t expect they’ll be issuing any patches for this mid-2012 vintage CPU. If intel issues a microcode patch, and I’m feeling ambitious, I’ll work my way through the BIOS patching info at Win-RAID.com and do it myself.
What’s the Current Score?
Let’s see 8 systems: 3 have been patched, and 5 are still waiting. That’s a 0.375 batting average. For baseball, that’s pretty good. For achieving protection from what’s supposed to be a dire set of vulnerabilities, I’m disinctly unimpressed. But because I have to say on top of this stuff, I will. And I’ll keep reporting back on it from time to time. My next expected return to this topic should occur when — mirabili dictu! — Lenovo gets round to posting its firmware patches. You probably don’t want to hold your breath, either…
In the wake of the recently-released KB4074588, lots of PCs with this update installed have resbooted to “lost” USB peripherals. In particular, many users have reported neither mouse nor keyboard present. Because a mouse and a keyboard are usually necessary to do anything on a Windows PC, this poses something of a conundrum. Consequently, I herewith provide what I hope are helpful tips for fixing missing mouse or keyboard. Better to skip such problems entirely, but if you get stuck, try these!
As the top (and current) results from this TenForums search show, this situation is far from uncommon.
Tip 1: Fixing Missing Mouse or Keyboard via Device Substitution
Try a different mouse and keyboard. Seriously. MS explains this gotcha as a driver omission. Here’s chapter and verse
After installing this update, some USB devices and onboard devices, such as a built-in laptop camera, keyboard or mouse, may stop working. This may occur when the windows update servicing stack incorrectly skips installing the newer version of some critical drivers in the cumulative update and uninstalls the currently active drivers during maintenance.
Presumably, the hopes driving this maneuver are two-fold. First, MS hopes that Windows will recognize the keyboard. Second, MS hope that it will successfully download the correct driver. If you find yourself with a working keyboard and mouse, you can skip a heading and jump to “DISM to uninstall KB4074588 at the command line.”
Tip 2: Fixing Missing Mouse or Keyboard via OS Substitution
The problem is that the update removed the old (working) drivers and didn’t supply any new ones. If the OS lacks drivers, another way to fix the issue is to try a different OS to make repairs. That’s why MS recommends booting into the Windows Recovery Environment (WinRE), where mouse and keyboard drivers should be both available and working. There are lots of different ways to access WinRE, so I’ll share two of them (for a more exhaustive treatment try this excellent TenForums Tutorial)
- If your system fails to boot 2 times in a row, AND your system has a built-in recovery partition (installed by default for most Windows 10 systems), it will automatically boot into that partition on the 3rd try.
- If that doesn’t work out, you can boot to the Windows 10 installer and access the “Repair your computer” functions to make your way into WinRE.
Either way, you want to make your way to the command line so you can work on the affected OS. That’s covered in the next section.
DISM to Uninstall KB4074588 at the Command Line
If you’re using a substitute mouse or keyboard, you’ll need to get into an administrative command prompt. If you’re running WinRE, its command prompt is already privileged. Once there, you’ll want to enter one of the following commands, depending on whether your Win10 installation is 32- or 64-bit:
32-bit: dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~x86~~162184.108.40.206
64-bit: dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~162220.127.116.11
Once that command completes, you’ll have removed the trouble-causing update. You must then reboot Windows 10 to restore your computer to normal operation (with access to the missing mouse and/or keyboard restored).
In general, this approach works any time mouse or keyboard goes missing. The details of which package you need to remove may change. Or, you could try to find and install the missing drivers on your own. It’s up to you!