• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

Windows 10: why is a driver re-install ever necessary ?

Blue Bubble

Sharper than a thorn
Joined
May 9, 2005
Messages
6,453
Location
The Green, Duxford, Cambridgeshire, UK
So, my civil partner has a new part-time temp job, where she's using a Dell Ultrabook laptop running Windows 10. Yesterday (the third day on the job), starting the system looked completely normal (which also includes the keyboard lights switching on). However, the keyboard was completely non-functional, so it was not possible to enter a username/password (using the On-Screen Keyboard obviously did work).

She engaged IT support, who then did a re-install of the keyboard driver (the keyboard was thereafter functional as normal).

I am a retired IT consultant with a BSc in Computer Science, so not a complete newbie ;)

Could someone with more Windows knowledge/experience than I have please explain to me why a driver re-install was necessary ? What happened to it to cause it to break so that it needed to be re-installed ? It's not as if it's a dynamically changing piece of software ... it's not been updated in many years, as one would expect of a pretty fundamental and relatively simple part of the operating system.

Why do users accept this as a "solution" to a problem ? In my working days in support (VMS and Tru64), I'd never have got away with blithely re-installing a driver for any particular device without actually explaining what had gone wrong to cause a problem. And no, bit-rot is not really an explanation.


Windows ... grrrrrr :mad:
 
Last edited:
The time to finesse an issue is a luxury IT front line professionals don’t have. If a reinstall restores a setting or corrupted file we have a winner. Most users do not care to understand the why but happy to have a problem resolved.

If the problem starts to manifest widely then the root cause might be examined and often then by vendors.
 
The time to finesse an issue is a luxury IT front line professionals don’t have. If a reinstall restores a setting or corrupted file we have a winner.


How would a setting get set without any user action ? And if it were some setting, why could it not be fixed by setting it "correctly" without re-installing a driver ? And what sort of setting could disable the keyboard ??? Not buying that ...


Corrupted file ??? If a file (essentially a read-only one) gets corrupted then the system has major problems if you can't trust the file system integrity. Not buying that either ...



I think these are brush-off excuses for "we haven't got a clue why the problem occurred".


Most users do not care to understand the why but happy to have a problem resolved.


That would have been the same in my world, but management would have expected root-cause analysis every single time. Correctly so too !



If the problem starts to manifest widely then the root cause might be examined and often then by vendors.


From my Google searches for this issue, I'd say it's pretty common, and I don't see any vendor fixes anywhere. Not getting at you Sideroxylon, but it's this sort of just-accept-attitude that I find totally infuriating.


And oh yes, we non-Windows front-line professionals were under just as much time pressure too, perhaps even more so. But we didn't have to deal with such ridiculous things like this.
 
That would have been the same in my world, but management would have expected root-cause analysis every single time. Correctly so too !

Sorry, but I find this hilarious. When it takes more time, effort and expense to analyze the cause of the problem than it does to implement a fix... management doesn't throw money around like that.

With Windows, you don't have a monolithic entity that makes every driver. Tens of thousands of vendors make millions of different drivers that can interact in quadrillions of different, unexpected ways. You might have an update on one driver or piece of software that overwrites a value or re-uses a particular address that causes a completely unrelated piece of software to save an incorrect bit of data that then corrupts a value in a third or subsequent driver... there are just too many possible variables in a complex system like Windows that strives to support every ridiculous possible combination of hardware that could conceivably be hooked together and expected to work... yeah, "Just reinstall and get the MF working" is the truth.
 
This whole thing reads like a ghost-sighting apologetic. But let me just say this: No IT management expects a root cause analysis for every simple break/fix ticket that hits Tier 1's queue. Maybe if someone is paying attention and has a lot of time on their hands, they'll run a report to see what the biggest workload category or biggest time sink category is, and maybe start a project to find and mitigate the root cause(s) of those tickets.

"We reviewed all the tickets for the past year and discovered there's a widespread keyboard driver problem with the new Dells. We talked to the vendor and added a step to our baseline image to proactively solve the problem. This has resulted in a 13.7% increase in productivity for Tier 1 IT."
 
Sorry, but I find this hilarious. When it takes more time, effort and expense to analyze the cause of the problem than it does to implement a fix... management doesn't throw money around like that.
I once worked on a web-based service that generated millions of dollars of revenue a year. It was literally the lifeline of the company. And the underlying application had a horrible memory leak. Let it run for more than a couple weeks, and it would start crashing. Hundreds of thousands of customers could be affected during our peak season. Chronic crashing like this would absolutely kill the company.

Management examined the problem. The hardcore software development purists insisted that we should go into the code, find the bug, and fix it. Wiser heads pointed out that the core code was over ten years old, and that any attempt to fix the bug would almost certainly create dozens more.

It was much cheaper and safer just to reboot the servers every Saturday at midnight. No root cause was ever sought or found.
 
It was much cheaper and safer just to reboot the servers every Saturday at midnight. No root cause was ever sought or found.

Exactly. I think the OP just doesn't realize that times have changed.

If I got this ticket, fixed the problem, and talked to the customer I'd actually say something to the effect of "a good USB keyboard would probably help in way more ways than just avoiding this problem too. Perhaps we could look into getting you a docking station if you don't move around a lot."

I tell this story a lot but a few years ago an MSP I worked for had an issue where a windows update uninstalled all of the network card drivers for all of the Z machines. One of our companies used pretty much only those, about 200 of them total. We could remotely fix them so we had to touch each machine. We came up with a quick plan of creating a folder with the network driver, creating a batch file, installing both and running it. Did that for each PC, then we tracked down and blocked the windows update. Another update did the same thing, we just walked users through running the batch file. That's all to say, we certainly weren't going to dig through both HP and Microsoft's code to track down the issue and fix it. That would be crazy.
 
The pertinent thing that might have changed was that once IT departments were responsible for writing a lot of the code and that same person was responsible for issue resolution. Also that code was running on a central device that you had intimate knowledgeable of.

Today almost all applications are off-the-shelf with little in-house development and often running on a wide variety of devices of various ages.
 
I once worked on a web-based service that generated millions of dollars of revenue a year. It was literally the lifeline of the company. And the underlying application had a horrible memory leak. Let it run for more than a couple weeks, and it would start crashing. Hundreds of thousands of customers could be affected during our peak season. Chronic crashing like this would absolutely kill the company.

Management examined the problem. The hardcore software development purists insisted that we should go into the code, find the bug, and fix it. Wiser heads pointed out that the core code was over ten years old, and that any attempt to fix the bug would almost certainly create dozens more.

It was much cheaper and safer just to reboot the servers every Saturday at midnight. No root cause was ever sought or found.

We had a similar problem at work with a Ubiquity Wi-Fi. It is absolutely necessary for us to have to have a perfectly functioning Wi-Fi because our customers need to be able to connect to it "in-shop" to upload files for printing. The problem we had was it would suddenly be unable to take a connection every couple of days (it wasn't running out of leases, I looked at that), but a reboot would always fix it for the next couple of days. In the end, I put it on a mains power timer that turned it off for a minute and then back on again at 8am every day. Haven't had a connection problem since, and that was a couple of years ago.
 
No knowledge of how IT departments work and all that stuff, but I had a Dell laptop which occasionally went awry and then worked again after one or another reboot or fix, including several things that were reported on the internet to be problems with Win 10, until one day the hard drive just packed up and everything on it was totally lost. A similar thing happened on a Win 10 desktop, in which a reboot worked every time until it didn't.

Just mentioning that because it seems a failing hard drive often causes boot errors and driver corruptions, and she'd better have backed up her stuff.
 
I am a retired IT consultant with a BSc in Computer Science, so not a complete newbie ; )
FYI, saying this to an actual working IT professional who is trying to solve your problem guarantees that they will lose all respect for you, and all interest in doing any more than the bare minimum to help you.

It's the IT equivalent of saying, "some of my best friends are black!"

The "BSc in Computer Science" is especially grating. Working IT professionals know that a CS degree has very little bearing on the day to day work of IT. It might have some bearing on innovative software development or designing information system architectures.

Also, nobody in IT likes IT consultants. You're really poisoning your own well here.

---

Two stories to illustrate my position:

Once, many years ago, we brought in IT consultants to help us set up an enterprise system. At one point the lead consultant approached me about the feasibility of triggering some piece of software to run on a regular schedule.

"Sure," I said. "We can set up a cron job to do that."

"Cron?" said the IT consultant. "What's that? Tell me more."

Much more recently, one of my service customers came to me because she was having trouble using my service. The issue turned out to be that she was using her OS's default browser, which was not supported.

"Do you have any preference for Microsoft Edge?"

"No," she said.

"Then this is an easy fix," I said. "Just set Firefox as your default browser, and carry on."

"How do I set my default browser?" she said. "I'm in IT, but i'm not that much in IT."

---

The anti-Windows chauvinism also belies the claim to real IT experience. Linux and Unix and MacOS all have their gaps and foibles, too. And this issue doesn't even sound like a Windows issue. This sounds more like a Dell hardware/firmware issue. Maybe even an issue with the third party that manufactures the keyboards or writes the driver.

You can't claim a CS degree and IT consulting experience, and then conflate the Windows OS with the Dell hardware and drivers. I mean, obviously you can, but it's hard to take you seriously after you do it.
 
Last edited:
I once worked on a web-based service that generated millions of dollars of revenue a year. It was literally the lifeline of the company. And the underlying application had a horrible memory leak. Let it run for more than a couple weeks, and it would start crashing. Hundreds of thousands of customers could be affected during our peak season. Chronic crashing like this would absolutely kill the company.

Management examined the problem. The hardcore software development purists insisted that we should go into the code, find the bug, and fix it. Wiser heads pointed out that the core code was over ten years old, and that any attempt to fix the bug would almost certainly create dozens more.

It was much cheaper and safer just to reboot the servers every Saturday at midnight. No root cause was ever sought or found.

Some sneaky person was skimming off the excess memory that leaked and selling it on the black market!! And they would have gotten away with it, too, if it weren't for you meddling kids.
 
Some sneaky person was skimming off the excess memory that leaked and selling it on the black market!! And they would have gotten away with it, too, if it weren't for you meddling kids.

Well, they did get away with it, since we never fixed the leak. I just hope Gabriel Shear is putting it to good use beating terrorists at their own game. Hack the planet!
 
I thought the keyboard driver was part of the BIOS. Does this get get overridden by an actual driver in the OS, or does the OS just hook (?) into the BIOS code?

In all my years in PC repair and support I don't recall ever fixing a problem, keyboard or otherwise, by reinstalling a keyboard driver.
 
The OS drivers aren't on top of any boot/BIOS drivers. It is possible for the OS to call out to the BIOS in some cases (like to draw on the screen or read the keyboard). But in most cases, they won't be used after boot and the native drivers (which don't reference the BIOS) are used instead.
 
The OS drivers aren't on top of any boot/BIOS drivers. It is possible for the OS to call out to the BIOS in some cases (like to draw on the screen or read the keyboard). But in most cases, they won't be used after boot and the native drivers (which don't reference the BIOS) are used instead.

And, AFAIK, keyboard drivers are for the extra bits. Lighting, how the Fn key is mapped, fancy macro keys etc.
All uninstalling the keyboard drivers should do is leave you with an unmodified and unmodifiable but working keyboard
 
Sorry, but I find this hilarious. When it takes more time, effort and expense to analyze the cause of the problem than it does to implement a fix... management doesn't throw money around like that.


But management has already spent money on a support contract, and is expecting something for that. And once the cause of the problem gets found, a proper fix can be made, and the problem occurs no more.


FYI, saying this to an actual working IT professional who is trying to solve your problem guarantees that they will lose all respect for you, and all interest in doing any more than the bare minimum to help you.

It's the IT equivalent of saying, "some of my best friends are black!"

The "BSc in Computer Science" is especially grating. Working IT professionals know that a CS degree has very little bearing on the day to day work of IT. It might have some bearing on innovative software development or designing information system architectures.

Also, nobody in IT likes IT consultants. You're really poisoning your own well here.


Gosh ... that's me told then :D
 
Yes BB how dare you come in here flaunting your credentials like that! ;)

I'd be very interested to know who's right about whether the windows drivers allows a cascade down to the bios keyboard handler. my experience is that is doesn't as I've had situations in Windows where Windows fails to see my keyboard but the bios does. That kind of multi level thinking seems often absent in Windows.
However I suspect the underlying problem is in the driver manager code/architecture. I also think that Dell and Microsoft seem light on proactive Problem management and see it as simpler and cheaper for them to resolve an incident as solved by turning it off and on again rather than do analysis to identify the impact on TCO.
 
Sorry, but I find this hilarious. When it takes more time, effort and expense to analyze the cause of the problem than it does to implement a fix... management doesn't throw money around like that.

I can understand this from when I worked for a bank with its hideous bureaucracy and a defect classification system written by people with very little understanding of how computers worked (insert my repeated story about trying to get them to explain the difference between root causes of 'program', 'application', 'code' and whatever). I tried explaining orthogonal defect classification a few times and I might as well have been explaining postmodernism in Gaelic.
But we're talking about big name software labs here. I worked in one for 7 years and interacted for longer. You should look at the cost to your customers and you of having to advise again and again of the same fix. Especially when your customer's customers (i.e end users) don't have the ability to reinstall drivers.
You windows only guys are used to this. To those of us used to very different OSs like say VMS, MVS, etc it seems suboptimal.
 

Back
Top Bottom