Why are all Windows drivers dated June 21, 2006? Don't you ever update drivers?


Why are all Windows drivers dated June 21, 2006? Don't you ever update drivers? Are you just a bunch of slackers?

What's more, the date of June 21, 2006 applies even to drivers like Storage Spaces, which didn't even exist in 2006! Has the Research division been using their time machine again?

The dates on all Windows drivers are set to June 21, 2006. The version number increases over time, but the timestamp stays put.

My colleague Zac explains: 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.

Suppose that the timestamp on the driver matched the build release date. And suppose you had a custom driver provided by the manufacturer. When you installed a new build, the driver provided by Windows will have a newer timestamp than the one provided by the manufacturer. Result: When you install a new build, all your manufacturer-provided drivers get replaced by the Windows drivers. Oops.

Intentionally backdating the drivers avoids this problem. It means that if you have a custom manufacturer-provided driver, it will retain priority over the Windows-provided driver. On the other hand, if your existing driver was the Windows-provided driver from an earlier build, then the third-level selection rule will choose the one with the higher version number, which is the one from the more recent build.

It all works out in the end, but it does look a bit funny.

Zac told me, "It's an awesome example of something that seems stupid and insignificant turning out to have a profound purpose."

Comments (65)
  1. pc says:

    Good to know that it's intentional. At some point, do you think there will be a plan to explicitly rank Windows-provided drivers below Manufacturer-provided drivers (maybe by looking at details of the driver signing certificate or the like), or will we be living with this hack until the end of time?

    1. Klimax says:

      It has to account for drivers that are made for XP but Microsoft has proper driver for Vista. (IIRC case for older IGPs by Intel that are part of chipset for LGA775 socket) Those XP drivers would work, but would be suboptimal and likely cause issues.

    2. Zac Lockard says:

      It sounds very hacky, but it's actually very flexible and robust. There's an implicit ranking system here that's more nuanced than "MS drivers are the lowest rank." By picking a 2006 date, the real effect is that any Vista+ driver will outrank the MS driver - but XP drivers won't. SOME MS drivers actually have a 2009 date, because there was some breaking change in Win7 - so Vista drivers will be lower ranked, but anything Win7+ will be good. You can extrapolate onwards - this system allows the ability to pick the date of the last breaking change to the underlying platform, and essentially deprecate older drivers without any code change. It just turns out that most components are compatible all the way back to Vista.

      1. Rob Record says:

        Couldn't you use larger version numbers to indicate breaking changes, and point releases to indicate non breaking changes, as with most UNIX software? It does seem hacky to hijack the date for this purpose.

        1. Rob Record says:

          Never mind, I read the comments below. What a mess to sort out!

  2. camhusmj38 says:

    Perhaps it would've been cleaner to have another flag for Windows provided (i.e. Microsoft signed) driver and then alter the rules accordingly so that they have lower priority than vendor drivers.

    1. Darran Rowe says:

      They would have to be careful with that, because it cannot apply to all Microsoft drivers.
      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.

  3. Damien says:

    Or it's an example of abusing an existing mechanism rather than changing it to explicitly address the problem at hand. Off-hand, the question that springs to mind is why is timestamp considered ahead of version number? There may be a good reason for it but it's not obvious to me.

    1. I daresay it's to ensure the most up-to-date version of the driver is used in cases where an updated driver is released but somebody forgets to bump the version number. (It shouldn't happen, but no doubt it does.)

      1. Damien says:

        That would still be solved with the timestamp and version checks reversed. If the versions are identical then compare the timestamps.

        1. Klimax says:

          Won't fix case where lower version number is used for some reason. IIRC already saw such case)

        2. Zac Lockard says:

          Zac here: using date first allows developers to build and test multiple versions of a driver on the same day without messing with it too much. Just rev the version for each compile and you're on your way

          1. Fred Fnord says:

            ...what?

            If it considered version number first, that exact same series of steps would work. Or having versions that compare as equal and using the windows equivalent of 'touch'. Or using the command line that sets a driver as active.

          2. Zac Lockard says:

            @Fred Fnord
            Consider the fact that there may be multiple entities making drivers for the same device, and there's no telling what versioning scheme they're using. Having version be the first tiebreaker means that if for some reason two different drivers for the device have driver versions that intersect, the behavior may be unexpected. In a development scenario, having the date be the first tiebreaker ensures only drivers you have built today are under consideration for ranking.

        3. Martin Plamondon says:

          If you read carefully, you'd see that all Microsoft versions of the driver are dated wayback to make sure that a manufacturer provided driver, even with a lower version number, would have priority, it is assumed that a manufacturer knows its hardware enough to have the better driver even if it's version number is lower than the Microsoft provided one.

    2. Antonio Rodríguez says:

      I guess it's because drivers from different providers (chipset maker, system assembler, Microsoft...) each have their own numbering. You could end with a driver from Microsoft which came with Windows XP (version 5.1.2600) and a more recent driver form the manufacturer with version, let's say, 2.6.

      1. Damien says:

        But the first level check is an exact match on the hardware ID. Unless I've misunderstood, then that should mean we're not talking generic drivers, we're talking drivers targeting a particular manufacturers product. So the drivers in question (again, unless I've misunderstood) are always the manufacturers drivers, it's just whether they've been bundled with the OS.

        1. Simon Farnsworth says:

          It's not an exact check on the hardware ID - the first check can be as weak as a check on the hardware class ID, which is rather broad (e.g. "all webcams", or "all sound cards" on USB).

          If I've got a manufacturer driver for my webcam that enables awesome features, but the webcam is designed so that the Microsoft UVC driver will drive it as a plain webcam without the awesomeness, then you want the manufacturer driver to override the Microsoft driver.

          Similar applies if I've got a manufacturer driver that enables standard features that Microsoft hasn't yet (say automatic pan/tilt/zoom). Both drivers may attach to the UVC class, but I want the manufacturer one that I've installed, not the Microsoft one (at least until MS catch up with the hardware).

        2. Microsoft doesn't only provide generic drivers, they provide a huge number of device-specific drivers as well. The transition to Vista and x64 saw Microsoft taking over hundreds, maybe thousands of unsupported devices from defunct, buggy, or lazy manufacturers.

    3. Darran Rowe says:

      Well, one possibility is Intel RST and Intel RSTe. The high end chipsets can normally handle both, so what you use depends upon what version of the drivers you install. If you start with say RST and decide to change over to RSTe when a newer driver becomes available, then RSTe would never install due to the version numbers always being lower than the RST drivers.
      Without having this direct upgrade option, the only choice you would have is to uninstall your SATA controller drivers, and that is not fun.

  4. Bradley says:

    Why does it even look at the date if you have to go to such lengths to make everything ignore it?

    1. Brian says:

      I'm assuming that the year 2006 is significant. That's the Vista time-frame. By using a date like that, you are saying "always prefer a Vista-era driver to an XP-era driver"

  5. xcomcmdr says:

    Where does the hardware ID come from ?
    Can too hardware IDs collide ?
    Since when hardware IDs are used ?

    i'm sure I can find by googling it (or not) but I can't help but find the process of finding drivers in place of the user very interesting.

    1. Richard says:

      If a manufacturers were well-behaved then there wouldn't be any collisions. Unfortunately they are not.

      Taking USB devices as an example:
      Any manufacturer of USB devices buys a manufacturer ID from the USB standards body.
      They then produce many products, each of which has a unique model ID set by the manufacturer.

      So far, so good.

      Unfortunately some manufacturers re-use the manuf and model IDs of a different manufacturer, claiming that they are identical. If they really are, then it works - but there are usually slight differences...

  6. user says:

    That's strange because on all manners of Internet forums, it's extremely common to read complaints like "I updated Windows and it replaced all my [manufacturer-provided] drivers and broke XYZ". From the description, it sounds like that would only happen if they had a generic driver which got replaced by a more specific driver matching the hardware ID?

    1. Richard says:

      That's a different issue.
      Many manufacturers offer driver updates via Windows Update - it's generally the only way that a non-technical user will ever get a driver update
      - Unless you write your own auto-update system...

      However, Windows Update is often going to be behind the manufacturer themselves.

      So that one is really due to bugs in Windows Update, and/or issues with the metadata provided by the driver manufacturer. Probably both.

  7. DWalker07 says:

    Wait:::

    "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."

    This implies that the driver provided by the manufacturer must have a later timestamp than June 2006, if you want the driver provided by the manufacturer to be chosen. Some devices have old drivers... but I suppose any drivers older than 2006 will not be Windows 7 or Windows 8 or Windows 10 drivers.

    Also, the date of the manufacturer's driver could be later than 2006, but the version number could be earlier. Or vice-versa.

    I suppose it all works out in the end.

    1. DWalker07 says:

      Actually, yes, the link says as much. I missed it the first time I read it.

    2. zboot says:

      No, it does not imply that.

      For that to be implied, you must first be able to definitively state that there is always a perfect match Microsoft bundled driver available!

  8. smf says:

    It's annoying when you can't tell if a ten year old driver from 2007 is better to install than the latest driver that gets bundled with Windows. It's mostly a problem for driver updaters as they have a database larger than windows update.

    1. Neil says:

      The system isn't foolproof: I have a Linksys 802.11b Wireless USB device which I could only get to work with the driver from the CD, not any later drivers either from the manufacture or though Windows Update.

  9. Gabriel says:

    One would expect that they could came with something more than a sysadmin hack today, but Microsoft.

    1. xcomcmdr says:

      I see someone didn’t read the article.

      This is sadly typical of haters.

  10. Matthew says:

    So instead of fixing the ranking system to make sense, they jerry-rigged things to work with a broken ranking system.

    This is sadly typical of Microsoft

    1. xcomcmdr says:

      I see someone didn't read the article.

      This is sadly typical of haters.

  11. y says:

    you still didn't explain what is the reason why the date is exactly "June 21, 2006". Why not "June 20, 2006"?

    1. Sure, it could've been June 20. You have to pick something.

    2. Ivan K says:

      June 21 was the northern summer / southern winter* solstice for 2006. So that explains that :-).
      *Except for New Zealand, but meh.

  12. Ed M says:

    Really? Instead of actually correcting the issue and checking the manufacturer of the driver and putting Microsoft's at the #2 spot when this happens (maybe even having an option in the settings on whether or not to do this), Microsoft, and I mean MICROSOFT, adds a band-aide.

    This, my friends, is why most software these days is crap. Don't fix the problem, just apply workarounds.

    1. Zac Lockard says:

      You could argue it's a bandaid, but it's actually a rather robust solution. Your proposed solution has just as many issues - SOME Windows drivers are actually designed to be the best match. They have dates that match the build. Always downranking MS drivers would break those drivers. So you could say that there should be some formal way to declare that it gets deprioritized - but you just end up with the same problem: what if an MS and third-party driver both say they're deprioritized? It turns out that using something non-boolean works really well.

  13. md says:

    The blog description skipped over several steps on how Windows ranks drivers[1]. The first and main criteria is on how a driver is signed (i.e., the source), and only after that does it potentially need to tie-break based on the blog's description of hardware IDs, dates, and file versions.

    Lowest rank score wins, and an inbox driver (i.e., a driver included with Windows) is scored 0x0D000003, which is higher than a WHQL signature score of 0x0D000002 or 0x0D000001 (according to setupapi.h in the Windows SDK). However, in Windows 7 the default policy was changed [2] to now treat all signers the same, which now effectively ignores the source. Apparently this date is used to still try to favor vendor drivers despite this change in policy.

    1: https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/how-setup-ranks-drivers--windows-vista-and-later-
    2: https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/allsignersequal-group-policy--windows-vista-and-later-

  14. Clayton Macleod says:

    Too bad this doesn't always work. I have to reinstall drivers every single time you release a new build. My drivers are still installed, but no longer work. So, along with having to set up all kinds of settings that should survive new build installations, I also have to reinstall drivers. It makes me wonder why I bother with insider preview builds because so much of my time is wasted setting up the OS again and reinstalling drivers. Every single setting that a user can make should survive a new build install if that setting survives a regular reboot. Any setting that survives a regular reboot is obviously a setting that gets saved somewhere. Even something as simple as the width of the left-hand pane in File Explorer. The default is uselessly narrow because you can't see jack. After I make that wide enough to be usable (nobody uses 640x480 anymore!) that setting survives reboots. Why do you reset it when updating to the next build? Same goes for every single other setting anywhere in the OS or any app. Why do you reset any setting at all? Knock it off!

  15. Steve says:

    I can see why they do it like this, but there are so many better ways.

    The Linux way would be to use a different Epoch number; so distribution drivers would be epoch 1 (and whatever version), whereas vendor-supplied can be epoch 2. This means vendor-supplied always trumps distribution, regardless of driver version.

    It is too late now, but maybe MS should have said that MS-supplied drivers are always version 0.(something) and Vendor can use 1.0 and up.

    1. Richard says:

      Sometimes when a vendor goes out of business, Microsoft takes over the driver and fixes important bugs in it - perhaps it claimed to handle hardware that it didn't.

      Then sometimes another vendor buys the defunct brand and produces a new driver that's better than the second MS one - perhaps it then really does support that hardware, plus some new hotness)

      Now there are three, all with different version numbering schemes.

      Everybody agrees on the date these happened though.

      1. Darran Rowe says:

        My system had a case of the first. A USB 3.0 controller in my system had rather broken drivers, some fun stuff occurred like not being able to identify hardware and bad interaction with the USB 2.0 controller in my system. Eventually, Microsoft took over the driver and all of those bugs went away. This driver essentially became a Microsoft provided in box driver. This driver should never lose out to a vendor driver because it is newer even though it is a Microsoft driver.

  16. Dave says:

    If all the drivers have to be dated 21 June 2006, are they all written by guys with the surname Singh?

  17. Dave says:

    If you need weird workarounds like this, the bigger issue may be that Windows has a bizarre algorithm for choosing drivers. Consider fixing the root issue so workarounds for your own product are not necessary.

    1. Klimax says:

      What "workarounds"? There are no "workarounds". You may want to re-read before commenting. Your reading comprehension failed you terribly first time.

      1. Rob Record says:

        Changing the date is a workaround.

  18. Marcos says:

    When did windows start doing this? Since I installed windows 10, my mom's laptop gets messed up every time windows installs an update and I think it's because all the drivers get replaced.

    She hasn't complained in a while but not sure if it stopped happening or she got tired of complaining.

    1. Klimax says:

      Actually, those major upgrades are completely new installations, that's why there are some issues with drivers. (With users stuff migrated to new installation)

  19. hacksoncode says:

    I think it's worth noting that, as he commonly does, Raymond has simplified the actual process in order to explain the specific topic of his blog post.

    There's quite a bit more that goes into driver selection on a particular machine than just hardware id matches, date, and version number.

    There's CHID targeting, Feature Scores, test distribution registry values, more subtlety on how exactly hardware IDs are matched, etc., etc., etc.

  20. Carlos Osuna says:

    This little things remind you that something deep inside Windows are just plain wrong and haven't been fixed in quite a while.

    The failed promise of Vista was it's own demise. Wonder if some day in the future we will refer to a given politician or public figure as the "Windows Vista" of Politics or TV or cinema. Translation: "he or she promised too much, but didn't deliver on those promises".

    My two cents... bitcoins of course.

    1. Klimax says:

      Your 2 cents are even more worthless then bitcoin ones. Although you are terribly vague, yet quite wrong. Quite an achievemtn to be very vague yet wrong...

      1. Klimax says:

        I forgot to fix "achievement"...

    2. xcomcmdr says:

      What a load of incredibly vague and useless hate.

  21. Craig says:

    gwmi Win32_PnPSignedDriver | ? DriverDate -match '20060621' | select Manufacturer,DeviceName,DriverVersion,DriverDate,HardwareId | out-gridview

  22. Br.Bill says:

    This is all unnecessary, because of the Windows Registry. What's the point of that system if not to provide functionality exactly for this sort of purpose?

  23. Alex Ionescu says:

    Well this'll be fun once RS2 ships and reproducible builds no longer have a timestamp :-)

  24. I've wondered this before, and hearing this explanation makes perfect sense. A thoughtful piece of planning by the Windows team. :)

  25. Ken Hagan says:

    For what it's worth, I'd *prefer* the Microsoft driver over the vendor driver, regardless of dates or versions, as long as the hardware ID matches. In my experience, the latter are "optimised" for sales and marketing purposes whereas the former are built by someone who knows how to write a solid driver.

  26. MS-DOS use the timestamp to record the version information.

  27. Hubert says:

    Nice to know that but still .... "It's an awesome example of something that seems stupid and insignificant turning out to have a profound purpose." - really? Unfortunately I would say that this is still stupid and moreover definitely a BAD design and dirty hack which should be used (in best case scenario) as quick fix before some proper solution is found. I would bet that it was meant to be a quick fix, but someone forgot about this since it's a low priority issue. If not then I do not know who gave that +2 on code review ... Sorry guys but this should be fixed.

    1. Max says:

      Although it seems like a hack at fifrst glance, it's actually a fairly elegant solution to a problem that there isn't really a better design for. The total chaos and deep importance of the driver space means that sometimes the manufacturer driver is meant to override the Windows driver, sometimes the Windows driver is meant to override the manufacturer driver, and versioning is meaningless since the two driver options are from different companies. It's easy to say "that's a bad solution", but how can you say that for sure if you haven't done the legwork to come up with a better solution yourself?

  28. BZ says:

    In this day and age, you'd think there would only be one driver for any piece of hardware. MS would know about what the manufacturer is doing and vice versa. They would agree on who makes the driver, or at least on the versioning scheme.

Comments are closed.

Skip to main content