File version information does not appear in the property sheet for some files

A customer reported that file version information does not appear on the Details page of the property sheet which appears when you right-click the file and select Properties. They reported that the problem began in Windows 7.

The reason that the file version information was not appearing is that the file's extension was .xyz. Older versions of Windows attempted to extract file version information for all files regardless of type. I believe it was Windows Vista that changed this behavior and extracted version information only for known file types for Win32 modules, specifically .cpl, .dll, .exe, .ocx, .rll, and .sys. If the file's extension is not on the list above, then the shell will not sniff for version information.

If you want to register a file type as eligible for file version extraction, you can add the following registry key:

             (Default) = REG_SZ:"{66742402-F9B9-11D1-A202-0000F81FEDEE}"

(Thanks in advance for complaining about this change in behavior. This always happens whenever I post in the Tips/Support category about how to deal with a bad situation. Maybe I should stop trying to explain how to deal with bad situations.)

Comments (26)
  1. Gabe says:

    What the heck is a .rll file, some sort of DLL that only has resources? My system has several of them, mostly appearing to be dev-related.

  2. Brian_EE says:

    @Gabe: Resource library used by various Windows programs; contains program resource information, such as program data and global parameters; typically stores resources for a corresponding dynamic link library (.DLL) file.

    RLL files may be used for application extensions. For example, an RLL file can store localization information for a program, such as foreign language support.

  3. Euro Micelli says:

    It's odd that .cpl (control panel) is on the list, but not .scr (screen saver). I verified that on my system. Probably a minor oversight.

    I bet  there are other file types with resources not on the list, but I can't think of any right now.

  4. Azarien says:

    "File version information does not appear in the property sheet for some files"

    That sounds like a title of KB article, complete with problem description and a workaround.

  5. Antonio 'Grijan' says:

    This change makes a lot of sense from a security point of view. Trying to extract version information from all files can make Explorer crash with files that look "just like" an executable, and that crash could potentially be used as a code execution attack. Just put this crafted file called "Important Document.asd" for download and wait for someone to download it. As they can not open it, chances are that at least some users will try to get more information about it with Explorer's Properties command. Gotcha!

  6. alegr1 says:

    >And what if all those files are on a network server halfway around the world?

    Cue Raymond: What if those are offline files?

  7. Anon says:


    You've spoiled tomorrow's blog post: "How much of a remote file does Windows need to read in order to build the property sheet?"

  8. JM says:

    I remember using the old trick of getting the file properties and taking the presence of version information as a sign that I was dealing with a PE file with a weird extension, but I honestly can't remember the last time I used it, let alone noticing that it stopped working. Good to know I shouldn't rely on it in the future, though…

    Can't say I disagree. Scanning arbitrary files for potentially useful stuff to display is a recipe for disaster — for security, stability, performance, you name it. As a feature, this never made much sense to begin with, occasionally useful though it might have been.

  9. Roger says:

    @anon:  In a related test when I was working on SMB/CIFS I tested how many round trips Explorer needed to show the contents of a specimen zip file.  A human writing the protocol would use 4 although one was two combined so lets call it 5.  XP's Explorer made 3,000 roundtrip requests, while Vista made double that number although many of the additional ones were asynchronous.  This kind of "inefficiency" is what provides product opportunities.

  10. David Crowell says:

    *This* is why you shouldn't give your libraries odd file extensions.  I'm looking at you, Powerbuilder.

  11. JamesJohnston says:

    But, *why* was the behavior changed in Windows Vista?  I also noticed this change a long time, and wondered why.

  12. Frank says:

    @Antonio: You can just rename the crafted file to awesome_utility.exe and trick people into downloading it. It's definitely not related to security.

  13. cheong00 says:

    [For example, an RLL file can store localization information for a program, such as foreign language support.]

    I think we have MUI file for that, and it can store anything the a RES file can hold.

    I'm a bit confused about what are the difference of them.

  14. Brian_EE says:

    @JamesJohnston: Because it seems like an incredbly stupid idea* to begin with (*searching through all files).

    I'm going to take a WAG* and say that 90% of files on a computer system don't contain .exe-style version structures. (*WAG == Wild-@$$-Guess).

    So Windows should waste all those cycles on every file for a few file types that support this? And what if all those files are on a network server halfway around the world?

  15. That sounds like a rather sensible change, to me.  Why bother trying to find file version information in a bunch of files that probably don't even have it?

  16. Arthas says:

    I have a small question recently.

    why .net framework named "netFx"??

    framework is just f, what is x?

    I didn't see any Ex here.

  17. JM says:

    @Frank: except that strange .exes come with stern warnings or outright blocks on every system that cares about security; getting file properties understandably does not. Nobody but the hapless victim is surprised if strange executables steal your credit card info, while there would be outrage if it could happen just from looking at the properties of "cutekitten.jpg". Not to say the version information parser contains a bug this severe, of course… In other words: if a malicious file is an executable, problems with the version info are the least of your worries. If it's not an executable, problems with the version info have no right of being there at all. Even if this change wasn't done to reduce potential attack vectors, it still makes sense from a security standpoint.

  18. xp.client says:

    Vista/7/8/10 also omit custom version information strings, do not show all of the same information as the old Version tab unless you tweak the Registry for each extension and do not support quickly copying any of the displayed information to the clipboard.

  19. Mityador says:

    @Antonio 'Grijan': Consider that attacker could name his file any way he likes, including any of the white-listed file extensions. Hence for security, it is really required that Explorer inspects the inspected file carefully. Period. Writing secured code simply is more work and there is rarely a shortcut unless you count not implementing the feature altogether as a viable option.

  20. skSdnW says:

    In Vista they really pushed the new property system and two of the casualties were the version tab and IColumnProvider. The attack surface is still there but it is smaller because only certain extensions are scanned. The details tab has fewer entries because it will only display the version strings exposed by the property system. (The undocumented API that enumerates all version strings was also removed from version.dll)

    The really sad part is of course that you cannot copy the strings anymore.

  21. Mark says:

    Mityador: it's everything to do with security – known "risky" files (including .exe) are filtered on various download sites and email clients. It's the same reason the "mark of the internet" exists – to catch people who aren't aware they're doing something dangerous.

    In fact, not implementing the feature altogether is exactly what happened here. There was a choice between rewriting the version property pages to process data securely, taking into account security models and user expectations, and the decision was to can a marginal feature in exchange for a considerable amount of time saved.

  22. Engywuck says:

    @cheong00: isn't .rll older than MUI?

  23. Joker_vD says:

    Obligatory mention about the recent vulnerability in the strings utility. I hopw Windows' equivalent of libbfd is more safe, but still: parsing every file just to see if maybe it's something you recognize is not very safe.

  24. cheong00 says:

    @Engywuck: You're correct. MUI is Vista+ only.

  25. @Arthas

    FX is an abbreviation for Framework.  Examples:

    .NET Framework -> NETFX

    DIFx -> Driver Install Framework

    stdafx -> Standard Application Framework

  26. Medinoc says:

    A thing that always bugged me about versions in properties is that the properties of a MSI list a number of things that DON'T include the product version.

Comments are closed.

Skip to main content