Where does the Installed Updates control panel get the install date from?

A corporate customer wanted to know where the Installed Updates control panel gets the Installed On information from, because they found that the values were always set to the current date regardless of when the update was actually installed.

The algorithm goes roughly like this:

First, ask MSI what date the update was installed by calling Msi­Get­PatchInfo­Ex and asking for the INSTALL­PROPERTY_INSTALL­DATE.

If that doesn't work, then go to the registry key under Software\Microsoft\Windows\Current­Version\Uninstall\Unique­Id and look for a value called (surprise) Install­Date. (Note that 32-bit updates on 64-bit machines will be redirected into a Wow­64­32­Node key.)

If that still doesn't work, then it's time to guess: Windows XP uses the last-modified date of the directory that contains the uninstaller. Windows Vista and higher use the last-modified date of the Software\Microsoft\Windows\Current­Version\Uninstall\Unique­Id registry key. (Again, possibly with a Wow­64­32­Node stuck in there.)

Bonus chatter: Interestingly, the customer didn't phrase the problem like that. The customer said, "The first time a user logs on each day, the install date changes to the current date. Subsequent logons the same day do not change the date. But the first logon the next day changes the date again. What's so special about the first logon of each day?" What's so special about the first logon of each day is that it's a new day! I suspect that the the date is updated on every logon. It's just that they don't notice the change because the date is the same.

Comments (12)
  1. Joshua says:

    Comes from programs that decide the uninstaller is the Windows directory.

  2. Chris B says:

    OMG! I've noticed the same bug in .Net's DateTime.Today property! The first time I call it on a particular day, the day changes! What's so special about the first time I call it on each day? In fact, this one gets worse! The first time I call it in a particular month, the month changes! Happens for years, too!

  3. Ben Voigt says:

    Dilbert commentary on this situation: sometimes it's necessary to revoke the customer's computer use privileges and provide them with an Etch-a-Sketch instead.

    If that isn't possible, blacklisting the email should at least save you from despairing over the world's general comprehension of logic, or lack thereof.

  4. Karellen says:

    Wow­64­32­Node? Isn't that a bit redundant, due to the implicit W(32)oW64?

    [But the previous WoW was W(16)oW(32). Presumably the 32/64 was made explicit for clarity. -Raymond]
  5. Mark VY says:

    This is pretty much off topic, but does anyone know why Windows Update uses so much RAM?  It will happily use hundreds of megabytes, and if there aren't that many megs free, it will start to page, and eventually thrash.  My computer just rebooted from installing today's security update, and all windows update had to do was tell me "install successful".  Task manager says it needed half a gig to do this, on a two gig machine.

  6. IdahoJacket says:

    So, what would cause the registry value (or its modification date) to change every day?

    [I think Joshua got it: Because the app put its uninstaller in the Windows directory, and the Windows directory changes every day. -Raymond]
  7. Matt says:

    @MarkVY: To check the signature of the Windows Update it needs to compute the Authenticode hash of the file, which means mapping the entire file into memory.

  8. Xv8 says:

    @MarkVY: Also, if it is anything that touches .NET it re-'optimizes' lots of stuff (I think it recompiles the IL into native code).

  9. Dave says:

    @Xv8: The .NET thing is mostly a disk space hog though, not a memory hog.  The record space-used that I've seen is 3.5GB required to apply a 14MB update (this was on machines that were at close to capacity, or at least that didn't have the 3,500 megabytes of space needed to install a 14 megabyte update).

  10. Mark VY says:

    I don't get it.  If the update is 14 megs, how can computing a hash value take 3+ gigs?!?

  11. Dave says:

    @Mark VY: Uhh, see Xv8's message that I'm replying to.

  12. Mark VY says:

    Oh.  Wow.  Okay then.  But ouch.  I wish they found a way to re-optimize without gobbling so much RAM.  Maybe just go one file at a time?

Comments are closed.

Skip to main content