This also causes the most infuriating issue I've ever had with a controller and Windows 10. The "official" driver from the manufacturer hasn't been updated since a final revision in like Windows 7. Windows 10 offers a basic driver, but it's totally broken and the Windows driver constantly updates and overrides the old one. Anytime I want to play a game with this controller, I have to uninstall from device manager and install the old driver but ignore the restart. It works, for some reason, but as soon as the machine gets restarted, the driver is replaced and I get the yellow exclamation point in Device Manager again. Not a great workaround, but I'm glad it works for most things.
> This also causes the most infuriating issue I've ever had with a controller and Windows 10.
According to the text, it's designed to prevent the problem you describe:
When the system looks for a driver to use for a particular piece of hardware, it ranks them according to various criteria. If a driver provides a perfect match to the hardware ID, then it becomes a top candidate. And if more than one driver provides a perfect match, then the one with the most recent timestamp is chosen. If there is still a tie, then the one with the highest file version number is chosen.
I don't know where this is going wrong for you but both the file version and the timestamp are things you can manipulate on that driver file. Might help, although you're in trouble if the manufacturer's driver isn't a perfect match to the hardware ID.
It does, but I have to assume that the Windows version also is a perfect match for the hardware ID. Since the older driver from the manufacturer supports all the features, but the date is before June 21, 2006, the MS driver is used instead which is, essentially, neutered for some functions.
The text shows that the driver is working as intended. The newer driver is being chosen automatically. The problem is that the newer driver is the Microsoft one. The sad thing is that I don't even know the Manufacturer of the driver anymore. It was painted on the controller and has since rubbed off and the driver file itself just shows up as "Generic Joystick Driver" or something like that. At one point, it got identified as an XBOX 360 controller. :(
That driver must predate Windows 7, then, which was released in 2009. I've found drivers from Vista or before don't want to work with Windows 10 in some fashion anyhow (perhaps the 32-bit to 64-bit transition?).
Possibly. I've had the thing for close to 20 years, I think. It came with a bundle that had a sound card and a DVD (or maybe even CD) drive. It's USB, though, so it can't be that old!
Just out of curiosity: Have you ever considered just buying a new controller? Spending your time on troubleshooting drivers doesn't seem like a sensible decision from the time=money point of view.
Of course! I do own other controllers! There are just some games that don't seem to recognize newer controllers the same way (the original Mortal Kombat being one of them). I'm not saying that my issue is common and I realize that I'm putting this issue on myself, I just mentioned it because it's a situation that highlights why their "solution" to the problem they have is more of a workaround rather than an actual fix. As others have pointed out, the correct "solution" is to de-prioritize their own drivers. It's their driver and their OS. They could even have a flag that's set in the driver for OS that also affects priority.
From what I can tell, the "solutions" presented here don't actually solve anything, make things a lot more complicated, and just open new cans of worms. For niche cases there are always good workarounds.
USB 1.0 came out in 1996 (I recall a special release of Windows 95 had embryonic support for it), so close to 20 years, indeed! The fact you can get the driver to work at all is pretty impressive, given it's not getting updates.
I see what you mean. I just took a look at how you might go about tweaking the date on these files manually, either by tweaking an extended attribute or using a hex editor (I'm not sure) and it occurred to me... digital signing. I don't know, might be worth a try, but it might not work if the driver is signed.
Find the driver files and change the owner to 'TrustedInstaller' and then make them read-only by everybody. As far as I can tell the only way to remove a 'TrustedInstaller' file is in safe-mode.
Using the date is obviously a kludge and does not match the semantics of the desired mechanism (3rd party specific drivers overriding baseline system drivers).
But there is something profound here: That MicroSoft is willing to take a static informational figure (such as a date) and use it for other purposes while doing a poor job of documenting it and handling edge cases. That MicroSoft has let this system sit for 10 years is incredibly profound, in my opinion.
Separate directories for system and vendor drivers. System directory given lowest priority.
Wouldn't require modifying vendor drivers or legacy installation or whatever. Just move the system drivers.
I must be missing something pretty fundamental here, because this seems like the immediate natural solution.
----
Disclaimer: I've had basically no meaningful-to-me interactions with drivers that weren't mediated by an installer or package manager, and I haven't used any form of Windows in 10 years.
Drivers have a priority field 0-255. Vendor drivers can only use 128-255. System drivers start at 255 baseline. Highest priority (0 is highest) always wins, and ties are broken with version or date comparison or what-have-you.
Right, the system baseline (255) starts well below the vendor's max priority (128). The vendor would start at 254 presumably, and overeager vendors wanting to start at 128 would only harm themselves (in terms of future flexibility).
When MS needs to supersede the vendor driver, they can issue priority 253 (i.e. vendor + 1) graciously or 127 violently. They can also retract the 127 driver or overwrite its priority back to 255 when appropriate.
Actually, I think you made that too easy. Microsoft itself has lots of legacy drivers - probably thousands. Changing them would require finding, recompiling, retesting, and redistributing all of them at best. That's certain to be expensive, and may not even be possible in all cases, so you're probably not going to do it.
So how would you fix this without changing any drivers from any vendor that have already been released?
Also keep in mind that this is a minor convenience feature that most people will rarely see, so you probably don't have a massive budget.
Not the grandparent, but my first thought would be to use the signature. If the driver's signed by Microsoft, and another matching driver is signed by the hardware vendor (or is unsigned and the user has already gone through the relevant approval tomfoolery), then prefer the vendor's.
> So how would you fix this, keeping in mind you are not allowed to touch the vendor driver's binaries in any way?
I'd change the premise, since Microsoft definitely is allowed to enforce policy on vendor drivers through its WHQL/code signing program, and has wielded this power.
Not that I necessarily agree that all drivers should have to be signed, but refusing to sign drivers to solve quality problems is entirely in scope for having such a code signing program in the first place. Unsigned drivers Microsoft can simply wash their hands of: "We can't enforce policy on those, sorry." Since manufacturers want signed drivers to ease confusion, they will come in line, especially since it's a particularly low bar to set.
This is far from a field with which I have experience, so I can't provide any sort of solid answer. I imagine that it would be a significant change, and would take time to do right.
But not a decade. Surely, something could have been introduced in any of the 3 OSs released since that date that could have addressed the issue.
I'm not trying to play them out to be evil, or incompetent. I think this is just an example of a problem that was on the "let's do this tomorrow" list for 10 years running. Understandable, in a way, but somewhat less understandable when in the context of a giant like MicroSoft.
You add a metadata to the MS drivers that tells Windows they have a special low priority. If a driver doesn't have the flag explicitly set, then it gets a default "normal." priority.
Fix the license agreement with the vendor. If I'm going to be nice enough to distribute your driver for you, I reserve the right to alter its metadata in any way I deem necessary.
Imagine- MS pushes out a driver update where the drivers are dated to the actual day they were produced, causing them to necessarily and simultaneously override all custom drivers on every Windows box on the internet.
That's not a feature, that's an existential risk to MS as a company.
"...if more than one driver provides a perfect match, then the one with the most recent timestamp is chosen. If there is still a tie, then the one with the highest file version number is chosen."
So check the manufacturer of the driver, and if it's Microsoft then assign the lowest priority.
Microsoft, as a company, has issues with inter-team communication. So I'm guessing the bug of Windows drivers taking priority was discovered by the build team, and rather than talk to the relevant team about the problem, they decided to just fix it themselves with this hack.
The adage "If it's stupid but it works, it isn't stupid" may apply here... or this may be the perfect counterexample.
EDIT: It's also possible that this is the "simpler" solution. The behavior of the driver selector probably went through a litany of testing before this problem was discovered. Changing the driver ranking algorithm is a major modification that would warrant another litany of testing. Given budgets and deadlines, I can see someone implementing this hack as a clever way to avoid re-testing a major component.
Technical debt is common for the same reasons monetary debt is common.
Simply put technical debt is a measure of how much it will cost you to modify your software while maintaining acceptable level of quality. Since with every change codebase gets bigger your debt increases. You can't just "manage" it away.
Many, many times people would be better off letting Microsoft replace the manufacturer's crappy drivers with something newer, or just ignoring the manufacturer's drivers completely from the time of installation. This is often the case with motherboards that do not ever receive driver updates to accommodate new Windows versions, or are otherwise abandoned by the manufacturer after a year or two.
Microsoft might be the manufacturer of the hardware, and perhaps in that case they still don't want drivers built and distributed with Windows to override drivers installed separately?
The drivers provided with the OS are generic. The drivers you can download are bespoke and offer additional features.
A perfect example is Microsoft's webcams. The built in driver will run the webcam fine. The downloaded driver adds "fun" overlays, filters, and software to control it.
So that's why not. Users won't want their webcam driver being downgraded every time a Windows Update is installed in the background. Even for Microsoft hardware.
Except, presumably, the vendor-provided driver is a match specifically for the hardware ID, which would already put it as the #1 match and no one would ever care about the timestamp.
It does seem to me that, at least somewhere along the line, we'd probably prefer the generic Windows driver from 2017 over the specific vendor driver from late 2006, though...
They also produce custom drives for that hardware (e.g. webcams). If they follow your plan then both the OS driver and the custom driver have the same priority and newer versions of the OS may disable Microsoft's bespoke hardware drivers.
To all you nay-sayers, this is Raymon Chen's blog. He has nothing to do with Microsoft's marketing machine and is probably a better engineer than most of us.
He's not promoting anything, he's just writing about a tidbit people would be interested in.
If you don't believe me, go through his blog archives. You'll most likely learn a thing or a dozen.
I love this blog. Anytime I see a submission on HN that points to microsoft.com I check to see if it's oldnewthing and if so click through, it's always been an interesting and rewarding read.
But why June 21, 2006, specifically? According to Wikipedia, there was a circulated Pre-RC1 Vista build (but only the first of 3) that was built on June 20th, and June 21st was the first day of summer that year, but neither of those seem like good reasons to pick this date in particular.
Much more than that. For example, both audio and video drivers had massive rewrites and rebuilds. Video drivers received a lot of tweaks for DirectX 10. More importantly, MS pushed the entire audio stack to use the User-Mode Driver Framework [1], which resulted in a lot of changes in how audio drivers access the underlying hardware.
My first thought was 'how ridiculous', but then I started to think of all the times I've utilized 'hacks' like these to get projects working and it's humbling to see that even at the highest level sometimes we are in 'just make it work' mode.
Wow, this is a quick hack around not giving space to metadata about the driver preference and trying to communicate it out of band, and they are passing it off as something to be emulated.
>And if more than one driver provides a perfect match, then the one with the most recent timestamp is chosen. If there is still a tie, then the one with the highest file version number is chosen.
I sort of get WHY they don't priorities highest file version above timestamp, but it also seems to indicate that they have an issue with managing drivers. I'm sure it's more complicated than I imaging, but shouldn't there by a way to tell Windows that you installed a driver and you want to use that one and not the bundled/updated driver from Microsoft... Well I suppose there is, give it a newer timestamp.
A typical Microsoft / cowboy programmer "solution". Ever wonder why Microsoft products are so buggy and unrealiable in every possible way? That's because they are built from hacks upon hacks just like this one with no regard for the user experience.
In the Linux world, instead of a proud "excuse" on a blog, a problem like this would kindle a discussion for a few days on the newslists, and a solution would be proposed and implemented in the following two months, to be accepted in the mainline a week afterwards. In macOS, this problem might stick around for a while, but Apple is forward-thinking enough to find better solutions eventually for problems that aren't necessarily vital but still should be corrected. For Windows, I doubt this will ever be fixed unless they do away with drivers as we know them entirely.
That's true, but then of course you would end up breaking compatibility with lots of things.
Linux has their drivers in the kernel tree for the most part, with no promise of backwards compatibility whatsoever. macOS is fine overall, but I've never had a major update not trash major parts of the OS, whether that's the build environment, some subset of GUI apps, or general hardware support.
Windows has a driver model. While not a promise, third parties can typically expect drivers to keep on working. I've never experienced an OS other than Windows with such broad hardware compatibility and such broad binary compatibility. Except in rare instances, just about every piece of non-driver software from the Windows 95 era works unmodified on modern 64-bit Windows. AMD64 did not exist when Windows 95 was released. Drivers also typically work unmodified, the major exception being a pretty significant change around the time of Windows Vista.
The Linux "solution" would be to yell at the driver maker to contort their driver to fit the Linux model and put it in tree. A vendor that refused would need to have their driver installer manually blacklist the kernel driver, and get support calls whenever the kernel's updated because the abi breaks again.
This is true for proprietary drivers, but the many open source drivers and replacement drivers would be fixed by someone in the next weekend after a kernel update, for ABI changes this minor. It might bother the single developer, but after the patch is distributed, it's completely transparent to end users, unlike Windows where you usually need to force every user to manually download the new update.
Ah, brings me back to decades ago when we sold and supported custom DOS apps - we would force the installers to change the time of the .EXE file to match the installed version number, e.g. 01:00 am for version 1.0, 01:13am for version 1.13 etc.
That way we thought we could tell which version the user was using over the phone by asking them to do a DIR (useful if they couldn't start the application to see the version number in there).
Of course, this system rapidly broke down because users would copy the files across to different floppies or hard drives, causing the file dates to be reset to whatever it was at the time!
No. I need some cases, the MS provided driver must take precedence over the vendor one. As a comment to this article says:
"I have a USB 3.0 controller in my system where Microsoft took over control of the driver, probably due to the hardware manufacturer going under. Anyway, the driver Microsoft provide is signed by the same certificate as they use to sign other drivers for Windows. But in this case, you would want the Microsoft provided driver to win out over any manufacturer provided driver because they are all broken in some way."
Of course they could have separate signing certificates for 'overriding' drivers, but that would be just as much a hack as using the time stamp.
If you don't trust your OS vendor to make such choices for you, why do you trust their OS? Consider a case where
- a user installed a top of the bill vendor driver.
- vendor goes out of business.
- driver has enormous security issues/doesn't work with some newer hardware.
- Microsoft releases an improved driver.
Should Windows:
- assume the user knows better and keep using the vendor driver?
- ask the user whether it can remove the outdated vendor driver (and any older one(s) still present), so that the Microsoft-provided one can take over? (even if the vendor-provided driver targets a broader range of USB devices?)
- do what it does now?
I think the number of people who would rightfully want to still pick the vendor drivers can easily be counted on the fingers of one hand, so my $0.02 is on the last.
All others would be baffled by any question asked and accidentally might pick the wrong answer.
You might not have a choice, say the vendor provides software (other than the driver itself) that is required to use the product and forces the driver install at the same time as the software.
There's very few drivers that need to be manually installed anymore. Even fewer that require the absolute deletion of the previous version by the user. It's all automated now.
"Of course they could have separate signing certificates for 'overriding' drivers, but that would be just as much a hack as using the time stamp."
It'd be far less of a hack, IMO. At least that particular hack wouldn't be totally subverting something with as much predefined semantic meaning as a timestamp.
Besides, it could actually fit into Microsoft's organizational structure reasonably well. The team that maintains default drivers could have one signing key, and the team that maintains override drivers could have a different signing key. Same deal for Microsoft teams/departments that develop/maintain drivers for Microsoft hardware projects (like Microsoft-branded HIDs).
Every Windows box is different from every other one. Some Windows drivers are way more stable, less-bloated or functional than the OEM's drivers (personal example: Realtek audio) on certain hardware, other times (as seen in this thread) it's the exact opposite. Managing and selecting which driver works well on your particular combo of hardware, and preventing auto-updates from overriding your choices should be a top priority for Microsoft. They desperately want Windows to be as user-friendly as macOS in this area, but the reality is that Windows runs on heterogeneous hardware and in practical terms, it just doesn't work. Right now forcing one particular driver over another is an exercise in pain and uncertainty. You never know if tomorrow you'll wake up to your microphone not working (again) because of an overnight update. It's silly. Just give end users a friendly interface and stop the nightmares.
Sometimes the Windows driver is actually better than the vendor driver. I've seen several chipset/SATA drivers (such as Marvell, and AMD) that break TRIM support on SSDs. To get TRIM working I had to revert to the regular Windows driver.
Something about this must be broken on my Windows 10 partition, because it keeps trying to overwrite my updated Intel Graphics card driver via Windows Update. I ended up having to blacklist the update to stop it from bugging me.
Removing the date criteria is significant change to the codebase and will eventually require more testing. This might not work well with budget and deadlines.
The worst thing to me is that they seem to think it's OK to do something like this and then not do something in the UI to make the blessedness of the specific date they choose clear.
