Why does the install date and size of a program change roughly two days after I install it, even though no changes were made to the program in the meantime?

A customer observed that when they install a particular company's product, and then go to the Programs and Features control panel, the program shows up with the correct installation date. But wait a few days, and then installation date jumps forward roughly two days, even though no updates for the app were installed in the meantime. (Also, the file size changes.) What's going on?

What's going on is that the system is trying to improve upon the incomplete information it was given.

If a program does not provide size information, then the Programs and Features control panel starts guessing by doing textual matching between the name of the program in the Start menu and the name of the program in the Programs and Features folder.

And if a program does not provide installed-on information, then the Programs and Features control panel assumes that the file was installed (or last modified) the last time its uninstall information was modified. There is no creation time for registry keys; last-modified time is all you get.

The final piece of the puzzle is that in Windows 10, the Storage Service looks for programs that registered with the Programs and Features control panel but didn't provide any size information, and it works behind the scenes trying to do a better job of figuring out which files on the system are part of that program, and when it comes to a conclusion, it updates the registration with the updated size information.

Okay, now it's time to connect the dots.

You install a program that provides incomplete information in its Programs and Features registration.

Some time later, the Storage Service figure out a good estimate for the size of the program. The Storage Service then updates the registry entry with the improved size stimate.

Updating this information causes the Size column to change.

And if the program did not specify an Installed On date, it also has as a side effect of changing the last-modified time of the registry key, which causes the Installed On column to change.

To avoid this problem, just make sure your program fills out both the InstallDate and the EstimatedSize fields when it registers with the Programs and Features control panel.

Of course, if it's not your program, then you either have to lobby the program authors to do it, or you can just dive in and set the values yourself.

Comments (31)
  1. Dalibor Čarapić says:

    The installation date in Windows 10 Apps & features / Programs and features is such a useless thing. Every time a Windows update is installed a bunch of my installed application look like they were installed at that time. Why not just keep the same date when the installation program was run and do not touch it? I guess that 99% of the users would be just fine with that. Why try to be ‘smart’ and fail so miserably?

    1. And how do you know when the installation program was run? Is that recorded anywhere?

      1. aybe says:

        I can’t believe the Windows team cannot track when last time an executable was run. On my bloated system, there are ~3000 executables in both Program Files, a simple data structure like a dictionary would do the job.

        And as someone else pointed out, the plumbing is certainly all done but components are light years away from each other (insert bureaucracy and lots of coffee here).

        1. Um, none of those 3000 executables are installers. The installer was on a CD somewhere or was deleted from your Downloads folder. (Heck, some installers are batch files.) We’re talking about Win32, where an “installer” is just an app that copies some files somewhere. There’s nothing that unambiguously says “I am an installer, and here’s all the information you need about the app that I’m installing!” (Life would be so much simpler if there were.)

          1. Joshua says:

            I write installers from time to time. Size is kinda hard to get after the third in-place upgrade and considering the data store is many times larger then the codebase after the program has been in use in awhile. I think I provided something for install date though.

          2. Maggan says:

            Actually, MS was heavily involved in supplying 64-bit shim installers for 32-bit apps. You know exactly what an installer is. Batch files are not allowed write to program files folder (without running as admin), gets redirected to program data folder instead.

  2. skSdnW says:

    If we want to be good citizens and write these values, where do we find the documentation for them?

    The MSI documentation lists them @ https://msdn.microsoft.com/en-us/library/aa372105(v=vs.85).aspx but it does not tell us the value types nor their format.

    These values have been in use since 2000 IIRC but never been properly documented on MSDN.

    1. Rich says:

      An MSDN article that stops short of being useful ? Shocker !

    2. Jan Ringoš says:

      My rule of thumb is to see how everyone else does it and check if it displays right.

    3. WiX can apparently do it.

      But I am currently looking for a why to write a multi-paragraph comment in this blog, because it seems it eats my line breaks. Maybe this will do the trick…

      1. skSdnW says:

        WiX uses MSI and gets some of this for free.

  3. JM says:

    Why would Windows depend on (or even allow) an application to provide its own InstallDate value?

    1. Brian says:

      Re-read Raymond’s post and then put yourself in Windows’ shoes.
      Windows can do one of two things to figure out an “installed on date”; it can either tell when the last time the installation information was changed (causing the two day shift described above), or it can read some information written by the installer. If you think about it, only the installer really knows when it actually did an installation (the same installer may be used to update a program – something that’s not an “installation”). So, the rules for installers say “when you install something, leave a breadcrumb in this particular place and we’ll display it to your users”.

      1. Mihailik says:

        Windows can see file creation/modification dates, last modified date on registry — or even introduce creation date in registry.

        Neither of these NEEDS to jump two days. The fact that it was implemented that way is entirely due to choice made by the coder. Possibly driven by the culture and strategy Microsoft sets for coders.

    2. Because before Windows 10, the concept of “app” was an absolutely abstract one. Windows only knew files that might or might not be somehow related. Apps were not delivered in a tangible cohesive unit that Windows would recognize.

      Windows 8 tried to change it but couldn’t. Windows 10 at least recognizes… something.

  4. Gregory says:

    Hmm, why can’t InstallDate field be set to the time at which the app is installed instead of left empty in case the app doesn’t provide it?

    1. cheong00 says:

      Same here. If I’m new to create installer package, I won’t expect that I have to fill that myself.

    2. Chris Crowther says:

      Because an installer is fundamentally just a program that copies files to the system for you. You could have written a custom installer from scratch, and then you’ll have to create all the relevant registry entries yourself. You don’t have to use MSI or any of the installer systems which wrap it.

      1. Someone says:

        @Chris Crowther: If it was really just a normal program, then Programs and Features would not even include the item in its list. To be in this list, the installer somehow get the attention of the system. And when the system (or the Control Panel applet) notices the new item, the system can record the current as the installation date…

        1. Suppose you install the program on January 1st, and you don’t open the Control Panel until July 30th. Are you saying the install date should be recorded as July 30th, because that’s when the Control Panel noticed the new item?

          1. Someone says:

            It already has heuristics to guess the installation data (if not provided by the installer). Once it has guessed this date, it should record it. And after this, it had never to guess it again, so the issue of this topic would vanish.

          2. cheong00 says:

            Not “Control Panel”, but Windows Installer.

            Maybe it can just fill the InstallDate on RegisterProduct standard action? The uninstall registry key is created in this step anyway.

          3. Windows Installer sets the Install Date value, so the issue is moot. The heuristic is for apps that don’t use Windows Installer.

  5. florian says:

    Well, that’s simple: The Storage Service should check if there’s an Installed On date, and set it before updating the Size (derived from the last-modified time of the registry key prior to touching it).

    But maybe the source code for these two features (the Storage Service, and the Programs and Features control panel) is a few millions of lines apart, and the people maintaining it may never have met each other. You see, I’m all familiar with managing HUGE projects ;-)

    1. Yup, that’s almost certainly the reason.

      1. GL says:

        How come the people working on Storage Service providing information for (Add or Remove) Programs in Settings/Control Panel might not know another value residing in the same key? That sounds like reading bible in one’s house and being deaf to what happens outside the window (两耳不闻窗外事 一心只读圣贤书, in case you know this idiom).

        1. AndyCadley says:

          They may well know the information is there, they just aren’t aware of the weird and wonderful heuristics that Windows uses to figure out what information to show if it appears to be missing – nor of the subtle unintended consequences of them correcting the “size” figure.

  6. Osexpert says:

    If it can guess the size, can’ t it also guess the installed on and set this registry value first? But wont the guessed size become outdated when the program is updated?

  7. Mihailik says:

    You guys are intentionally Kafkian, to get more money on support contracts — or just sloppy?

    If Windows uses ‘last modified’ date for its estimates, should Windows be careful not to interfere with ‘last modified’ date?

  8. mikeb says:

    Installers are tough. Want to go shopping?

Comments are closed.

Skip to main content