Files Remain Hidden Even though I selected show Hidden & Protected

Discussion in 'Windows Vista File Management' started by LabTechnician, Apr 23, 2007.

  1. Hello.
    We have a computer with Windows Vista Business 32bit on a Machine here in
    our Lab.
    We are trying to figure out why some of the files in our software are always
    We are logged in as administrator, and we have set the folder options so
    that it always shows hidden files and folders, and to always show protected
    operating system files. and to always show file extensions.

    In windows xp we see these files in windows explorer, with no problems.
    However to see them in windows vista we have to use the following application
    With this application we can see all the hidden files in the folder, however
    for some reason windows vista's explorer does not show these files, and we
    can not see them even in the windows vista Dos comand prompt.

    We have no idea why these files are hidden or how to make it so that they
    are not hidden in windows vista, after they are installed through our
    some of the file names are as follows.
    We are not sure if it is because vista will always hide files named this
    way, we tried renaming one of the files to random dfl.bda, and then all of a
    sudden we could see the file.

    We appreciate all the help anyone can give us.
    Thanks in advance.
    LabTechnician, Apr 23, 2007
    1. Advertisements

  2. Lab Technician

    Have you searched the drive for these files?

    These files may be subject to the Virtualization for Vista, this is for
    non-compatible programs that store user configurable files such as .cfg,
    ..ini, and other user files out of the

    %systemroot%\Program Files\program name, folder(s)

    and places them in the

    %systemroot%\Users\username\AppData\Local\VirtualStore\Program Files\program
    name, folder.

    If this is the case, then when you open your software programs folder In
    Windows Explorer, you should see a "Show compatability files" button on the
    Command Bar. Clicking this button will take you directly to the Virtual
    Store folder.
    Ronnie Vernon MVP, Apr 23, 2007
    1. Advertisements

  3. LabTechnician

    Stan Guest

    This is the first time I have seen anything about Virtualization. Did a web
    search but did not find any really useful info. What is it?


    Stan, Apr 25, 2007
  4. Hi Stan

    A little background first.

    Vista is built on a new security model that is based on what's called a
    "Least User Privilege" environment. What this means is that for software to
    be compatible with Vista, it must be designed to run under a Standard User
    account. This means that software programs are no longer allowed to write to
    sensitive areas such as Program Files, System32 folder, HKey_Local_Machine
    in the registry, etc.

    Software developed for previous versions of Windows pretty much required
    that the user must use an administrative account to use that software
    because this software did write to these system wide, sensitive areas (even
    though the Microsoft guidelines for developing software tried to deter this
    practice). These developers designed their programs to have system wide
    access, even though this was not really required. This left the system wide
    open to attacks from malware that would use the privileges of the logged on
    user (administrator).


    Going to the next level, Vista now 'requires' that software programs 'must'
    use the least user privileges for software to be compatible with Vista.
    Microsoft recognized that this could have a disastrous effect since so many
    legacy programs would not be compatible with Vista so they implemented file
    and registry Virtualization.

    This Virtualization simply means that if a software program attempts to
    write to a restricted area, (such as C:\Program Files\software program
    folder) then that write function will be silently re-directed to a
    non-restricted area, such as C:\Users\username\Local\Virtual Store\Program
    Files\software program folder.

    This allows the program to run as designed while still protecting the

    However, file and registry Virtualization is not permanent. It is only there
    to allow the software developers time to update their programs to be
    compatible with Vista. Virtualization will disappear sometime in the near
    future and programs that are not compatible will simply not run on Vista.

    Here are some links with more information, if you want to dive deeper into

    Common file and registry virtualization issues in Windows Vista:

    Getting to Know User Account Control: MVP Article of the Month - October

    Developer Best Practices and Guidelines for Applications in a Least
    Privileged Environment:
    Ronnie Vernon MVP, Apr 25, 2007
  5. Thank you for your help Ronnie.

    I did find it interesting that if our program is run by right clicking our
    shortcut and then select run as administrator, the hidden files now appear
    within the softwares, program files folder. Thus appearing to bypass the
    virtualization folders. Its also still intersting that by using the FAR
    program i listed, you can still see the files in the original folder.

    Virtualization was somthing we were not very aware of in vista.
    Functionally speaking our software works well in xp, and also vista however
    this new virtualization is giving us some difficulties in
    installing/uninstalling and updating our software, as well as some
    annoyances in running our progam.

    Some of the issues we are having which may be in part to the virtualiztion
    and new permissions/security UAC systems are as follows:

    Problem 1: Installer issues:
    Our installer does not overwrite the files which end up in the
    virtualization folder, Possibly because it is not aware of this feature, so
    we are looking into trying a new version of our existing installer or
    entirely new installer. This is problematic when it comes to uninstalling or
    installing over our software. Thus upgrading our software is currently not
    possible without manualy deleting these hidden virtualized files or their
    containing folders (which is somthing we want to avoid). Our current
    installer also allows the user to select which folder they want to install
    our software to, thus nothing stops them from using protected folders like
    program files (which is still our default folder to install to). This is
    somthing we have to resolve, and i guess we may have to put limits on which
    folders our software is allowed to install in, and maybe change our default
    folder to somewhere else avoiding program files.

    Problem 2: Config file writting:
    So now since we can no longer write to our .cfg files in program files, we
    are left to finding an alternative location for these files, or start writing
    this data to some other non standard madeup extension file other then .cfg.

    Problem 3: Unidentified Publisher:
    We now have to look into how we can become an identified publisher.
    Basically what is necesary to avoid these warnings that pop up every time we
    try running our program as administrator.
    So we are searching to see what is necessary, and what this is going to cost

    Problem 4: Run without Administrator:
    Right now if we run manually select our software shortcut and run as
    administrator, the files show up in our usuall program files folder, and
    everything works as usuall. So maybe one option is to find a way to always
    run our software with full admin, yet avoid the annoying warning signs,
    without resorting to disabling UAC, which we dont want or plan on doing, as
    we wouldent expect people who use our software to have to do this. Also a
    better option is to do what is necessary to our software so that it fully
    operates in the least permission normal accounts.

    In regards to the above problems we have found some websites that do explain
    a few things, but some of this is confusing, with various possible solutions
    making it difficult to select our best path forward, this is somthing that
    will take some time for us to test out and discover.

    Any further help you can provide in terms of links or advice is greatly

    Many thanks, for your two posts which have been very informative.
    LabTechnician, Apr 26, 2007
  6. Lab Technician

    What you really need to do is make a few changes to your program so that it
    will run under standard user privileges.
    This is way that programs designed for compatibility with Vista are supposed
    to be configured.

    I'm not a developer, but there are free developer forums where the Microsoft
    developers answer questions about any stage of software development for
    Vista. It's likely that they can get you up to speed very quickly. Many
    times configuring a legacy program to work with Vista can be as easy as
    including a simple Manifest file with the installation .exe.

    Windows Vista Developer Forums:

    Also, here are some links that will give you more information:

    The Windows Vista Developer Story: Windows Vista Application Development
    Requirements for User Account Control (UAC):

    Download details: Windows Vista Application Development Requirements for
    User Account Control Compatibility:
    Ronnie Vernon MVP, Apr 26, 2007
  7. LabTechnician

    retroman Guest

    Hello Lab Technician,

    I see this effect as well, and I think it illustrates a contradiction in the "virtual
    store" (VS) concept. The VS is supposed to protect the \Program Files folder by
    redirecting application data to another folder with less restrictive permissions. But
    applications that try to write to \Program Files are older, non-Vista apps, the very
    ones that often require admin privileges to run properly under Vista. Once given the
    needed privileges, the apps can and do write to \Program Files again.

    As a result, I see older applications that end up with *two* sets of data and config
    files. On installation, the first set is created in the VS as expected. If I give
    the .exe file admin privileges to correct problems that develop after installation,
    the app then creates new data and config files in \Program Files.

    Hello Ronnie,

    That would be a disaster for users of older applications, and I will be surprised if
    MS allows that to happen. Given my observations above, it appears that at least some
    older apps will still run on Vista if granted the needed privileges after
    installation. That is because once an app has the needed privileges, the "virtual
    store" becomes irrelevant.

    The other option that users will have will be to simply lower the permissions needed
    on the entire \Program Files tree, thereby restoring the ability of installers and
    applications to write config files there. I'm not recommending that, but with no VS
    available, surely some people will do so if needed to get vital applications to run
    on Vista.


    Doug M. in NJ
    retroman, Apr 26, 2007
  8. Hi Retroman

    <inline response>

    The testing I have performed on this with a few different applications shows
    the same behavior. However, in each case the applications files seemed to be
    mirrored in both locations. When one is changed, the other shows the same
    change. This occurs with no privileges being changed.
    This would be a likely result, however, it would also be just as likely that
    this would completely trash the new security model for Vista. I see this
    changeover to a more secure version of Windows as being a very long process
    that will likely go on for years.
    Ronnie Vernon MVP, Apr 27, 2007
  9. LabTechnician

    retroman Guest

    Interesting, I will look for mirroring. I haven't seen it so far, although I do see
    a case where the file dates and sizes are different for an application that I did not
    give "run as admin" privileges. Opera 9.2 has not updated the files in its Profile
    folder in \Program Files since installation. Only the Virtual Store versions are
    updated daily.

    I did modify some permissions in my first few days with Vista, so that muddies the
    waters a bit at my end. Foolishly, I did not keep a record of exactly what I changed.
    It would be nice if there was a way to reset security settings on the entire \Program
    Files folder to the supplied defaults. I might see different behavior from the VS

    Anyway, Ronnie, thanks for your response. I think that this area has not been given
    the attention that it deserves.


    Doug M. in NJ
    retroman, Apr 27, 2007
  10. On Wed, 25 Apr 2007 18:40:00 -0700, LabTechnician

    If you can accept advice from a very "ex-"programmer...

    Vista makes a lot of changes, and there are 2 ways to develop for it:

    1) Do what you normally do, make changes when this fails

    2) Research the intentions behind the changes, develop for Vista

    It may be a pain, but I'd strongly recommend (2).

    Without an understanding of why Vista is designed as it is, you'll
    find it harder to anticipate the collisions that reactive approach (1)
    will require you to work around.

    You'll be faced with a sea of inexplicable and seemingly-unrelated
    issues, from UAC to virtualized locations etc. that only make sense
    when you get into the design goals for Vista.

    As Vista RTM is the first step towards the new design approach, what
    works today may not work tomorrow... IOW the pain of (1) won't stop
    when you ship your own working app, but may pop up again and again
    over the years, as SPs and fixes discard some of the
    backwards-compatibility stuff that may still work in today's RTM.
    Yep; that's the design intention. So whenever you "touch" one of
    those protected locations, you have two separate behavior sets to
    tshoot, depending on whether the user was elevated or not.

    As you've already discovered!
    If you're licensing an existing 3rd-party installer that you're
    well-familiar with, see if they have a new Vista-orientated version.

    That may cost you money, but if they can hide the details in a way
    that is robustly in line with Vista's design, the value added may well
    be worth it. Installers may be close to the advice one hears about
    encryption; "don't try to roll your own, rather user one that works"

    OTOH, if the installer vendor is still "huh?" on the way Vista works,
    and appears to mired in approach (1), find something else ;-)

    AFAIK, the design intention of Vista is that a bone fide installation
    process can write to and populate restricted areas such as "Program
    Files", but thereafter the normal operation of the sware should not
    attempt to change these. IOW, you'd treat the code installation
    footprint as "read-only", perhaps designed to be writable only by your
    own designated update facility, whereas everything that needs to be
    touched in runtime is stored on a per-user basis.

    The problem comes to settings that you wish to apply across all users,
    and the answer is probably to access the new "shared" store that may
    also be where the "system" stuff is virt'ing to.

    To some extent, use of %variables% may allow you to gloss over the
    changes such that your dev will work for both Vista and XP, but there
    may well be limits to how far that will go.
    That's a good feature; don't lose that ;-)

    Seriously, I often gong apps clean out of the selection ring because
    they force me to locate their code and data in fixed locations.

    For best marks, allow user-settable paths for:
    - program code
    - inactive material, e.g. patches, backups, .MSI, etc.
    - user data and settings
    - incoming material, e.g. "received files"
    - Start Menu flyout, with [x] "...for all users" checkbox

    This fits strategies that wish to locate programs in C:, inactive
    bloat in F:, user data within a backed-up subtree off C: while
    excluding incoming material (as a malware risk) from all of the above.

    Specifically; do not mix or nest program code, data, and settings.

    Vista would see program code under "Program Files" (so that it is
    protected by the mechanisms that frustrate you for now), whereas
    settings etc. would be within an AppData subtree and data would
    default to within the user's Documents subtree.

    If you don't do the above, then what happens is that some users will
    move things around (or rename them) and then your uninstaller can't
    clean up. For example, your uninstaller would miss Start Menu icons
    if these were moved or renamed, and not everyone likes to be stuck
    with pointless "Vendor, App, App Name " flyout structure.
    It's a good location to install to. You just need to scope what goes
    there, so that it can enjoy the protection without the hassle.

    Else any passing malware with user rights can "update" your software's
    code, which is Ungood.
    The suggested fix there is to nest these within your own space in
    AppData subtree. If the data is small, it may be acceptable to use a
    fixed subtree name within this space, rather than off the user the
    ability to change it, or you can store your own pointers to this and
    other paths within HKLM\Software\YourSubTree

    Don't mix code and material that needs real-time updating in the same
    place, even if you can find ways to do this. I can see trends that
    may break the desirability of this in the future, along similar lines
    as the concept behind DEP (No-eXecute).

    If you get this right, you position your app for readiness for running
    from optical or otherwise write-protected storage. There may also be
    efficiencies if material is known not to be subject to runtime change.
    That, too, is a trend that may pick up momentum and grow teeth in the
    64-bit age. Already, the intention to kill unsigned drivers and
    kernel access is there, even if it annoys large av vendors etc.
    That's appropriate (if not inevitable) for certain types of software,
    such as hardware diagnostics, data recovery, etc.

    OTOH, if your sware has nothing to do with the system as such, and is
    purely user-orientated (e.g. games, accounting apps) then strive to
    work within limited rights.

    This is obviously a requirement if you are trying to sell into the
    space of managed IT (or may possibly grow into those shoes) but it is
    becoming a necessity for home consumers as well.
    Don't force users to take system-wide risks just to use your software,
    else you may find yourself left with the empty end of the Xmas cracker

    Unfortunately, for the first few years of Vista at least, some folks
    will disable UAC, so you have to test under those conditions too.
    At some point, that may be the only way you're allowed to run.

    This should have happened when XP pushed NT into consumerland, but it
    didn't - developers could still write for Win9x and things would
    generally work as long as users didn't try to use NT's strongest
    security feature, i.e. limited per-user rights.

    It's because of this complete disregard for XP's design goals
    (especially in consumerland) that Vista is cracking the whip now, by
    moving the mountain to Mahommad. If devs don't write for non-admin
    accounts, Vista will force non-admin restrictions into admin accounts.

    It's an ugly mess, but we mainly have app devs to blame - QuickBooks
    and other accounting apps that still "need admin rights" and insist of
    saving data within their installation subtree, games and children's
    software that "require admin rights" to run, etc.

    So don't blame the pooper-scooper (as Vista has to be) ;-)
    I'd start by looking into MS's site, especially those sections written
    with the developer community in mind. Horse's mouth, and all that.

    The most accurate diagnostic instrument
    in medicine is the Retrospectoscope
    cquirke (MVP Windows shell/user), Apr 27, 2007
  11. LabTechnician

    Julian Guest

    Would this virtualisation have anything to do with the advice seen in some
    places and ridiculed in others to run installers as Admin and to set Admin
    privileges on the legacy app itself/run it first time as Admin?

    I have a lot of trouble with legacy apps and UAC etc. and trying to work out
    what I should be doing to minimise downstream irritation.
    Julian, May 7, 2007
  12. LabTechnician

    Ger Guest

    I am also having a problem accessing downloaded files, but I am unable to
    find the "Show compatability files" button on the
    Ger, Mar 2, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.