The case of the blank file properties dialog

The case of the blank file properties dialog

  • Comments 2
  • Likes

Hello all. Prabhakar here again, and today I would like to talk about an issue which I recently came across where a user was not able to pull up the detailed description of files on a Windows Server 2008 machine. When the user would right-click a file in his System32 folder and select Properties, this is what he would see on the Details tab:

 

1

 

This of course is missing quite a bit of information, and should really look like this:

 

2

 

Other machines in the environment showed file details properly, and in fact this same machine showed file details correctly for most file types, so what could be the problem here? Well, it turns out the cause of the problem was that the user browsed the root of the C: drive before he went into the System32 directory. This doesn’t make sense on the surface, but here is what happens.

We have what is called a PropertyHandler in the registry for each file extension. In this case, the PropertyHandler CLSID value was CLSID_NoHandler, which means that there was no property handler for .sys files. This setting is case-sensitive, so in this case .sys was broken but .SYS was not.

It turns out that there is a special case within CFileSysItemString::_Class to associate files without an extension that have the System attribute set assigned the class '.sys' . However, when FileSysItemString::_GetHandlerAndClsidFlags calls PSLookupPropertyHandlerCLSID, it passes the filename, not the extension, with the assumption that the filename includes the extension. Since “c:\bootmgr” does not have an extension, and is marked as a System file, the lookup fails, and this result is cached under the “.sys” extension. As a result, subsequent lookups for other files with the “.sys” extension will also fail.

If any file with a .sys extension had been viewed first, the correct value would have been cached and the issue would not occur. Since this is all predicated on the file having the System attribute set, the issue would also not happen if the Bootmgr file was not visible in the first place, which it is not by default. In order to see this issue, you would have to have both of the following settings implemented:

 

3

 

Luckily, this is just a transient issue since the information is cached. You can work around this issue by doing any of the following:

 

· Re-enable hiding system and hidden files

· Open “C:\windows\system32\drivers” (or some other folder with real “.sys” files) first, before navigating to “C:\”

· Restart explorer (or log off/log on) to clear the cache

 

You could also use this as an opportunity to upgrade to Windows 7 \ Windows Server 2008 R2, since the code path has been changed to pass the extension instead. smiley

 

Til next time..

Prabhakar Shettigar

Share this post :


Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • didn't get a chance to post because the blogs were down. But, maybe you can shed some light on this.

    running win7, right click on an xls file, choose properties and on the detail tab, try to enter a version number. you can't. now change the xls to xlsm and try the same thing. you can now enter a version number. why is this blocked for an xls and not an xslm?

    i use this to track versions of 2003 excel files and i'm constantly renaming the file so i can change the version number.

  • didn't get a chance to post because the blogs were down. But, maybe you can shed some light on this.

    running win7, right click on an xls file, choose properties and on the detail tab, try to enter a version number. you can't. now change the xls to xlsm and try the same thing. you can now enter a version number. why is this blocked for an xls and not an xslm?

    i use this to track versions of 2003 excel files and i'm constantly renaming the file so i can change the version number.