Avoid the acredir.dll Shims: RedirectFiles and RedirectRegistry

As we continue our journey through shims provided by the Windows Shim Infrastructure, we have reached a point where I can no longer avoid a discussion of the shims contained in acredir.dll: RedirectFiles and RedirectRegistry.

Last time around, I pointed out how to redirect the registry using VirtualRegistry, which requires a command line argument which (for a very long time) was not publicly documented. Instead, a lot of people have been using RedirectRegistry, for two important and logical reasons. First, the name just sounds so tempting, since that's exactly what you likely want to do. Second, the act.chm actually does document these shims. So, I understand why people would rationally flock to these shims.

However, one of the internal questions that I address quite a bit: why can't I get xxx application to work with the RedirectFiles shim? Am I putting in the command line wrong? (and the command line follows)

So, I'll just say this. You shouldn't use these shims, because they're not designed to do what you think they're designed to do. Specifically, they target Internet Explorer.

Try it. From Compatibility Administrator, press the Query button on the toolbar. The second tab, fix properties, allows you to find programs fixed using a shim. Put one of these two shims in there, and then press the Find Now button. IE7 is the only thing that comes up. Now, try either VirtualRegistry or CorrectFilePaths. Lots and lots of things come up.

You see, IE7 leverages the Windows Shim Infrastructure to resolve an important compatibility issue: attempts by ActiveX controls to write to areas that Mandatory Integrity Control prevents them from writing to in LORIE, implementing an Internet Registry and Internet File System - a separate Virtual Store than that used by the operating system - and these two shims help make that happen.

So, these two shims are specifically designed and optimized around this one scenario, and were even separated off into their own DLL to help keep them separate. The problem is that we include the acredir.dll shims in Compatibility Administrator without this caveat. They have tempting names. We give them good documentation. So it's no surprise that people use them.

Instead of RedirectRegistry, I recommend using VirtualRegistry, which can redirect (among other things). Instead of RedirectFiles, I recommend using CorrectFilePaths (which I haven't talked about here yet, but I'm getting there).

Comments (10)

  1. The last time around , I suggested that you avoid using the acredir.dll shims – RedirectRegistry and

  2. Hana says:

    Hi Chris,

    I noticed that there is a VirtualizeDeleteFile, is there any "VirtualizeDeleteKey"?

    I encounter an application trying to remove a key from HKLMSoftware[Application_Key] during runtime but failed due to lack of permission.

    Is Shim can help in this case?



  3. cjacks says:

    Hi Hana,

    There isn’t an equivalent. If the user needs to be able to create and delete a key, I’d use VirtualRegistry with the ADDREDIRECT(old^new) command line to point these keys to a user-writeable location so they can be created and deleted by a standard user.


  4. Hana says:

    Thanks Chris.

    How about this:

    During installation, the script will execute an executable, eg: m.exe, and this m.exe will delete a key from HKLMSoftware[Application_Key].

    It should be not allowed. Can VirtualRegistry shim works in this case as well?

    Many thanks,


  5. cjacks says:

    Hi Hana,

    If it’s during installation, isn’t the application already elevated, in which case permissions aren’t an issue?

    The reason I ask: if what it’s trying to do shouldn’t be allowed because the key is protected by Windows Resource Protection, then you will want to use WRPRegDeleteKey. If it’s one of yours, then what’s wrong with deleting it? Or is it someone else’s key that the installer shouldn’t be deleting, in which case you may want to think about Virtual Registry?

    Is it an MSI? Could you just apply an mst to knock out that behavior?


  6. Hana says:

    Thanks Chris,

    I’ve tried out your idea.

    Here I have another scenario, if the msi is running another executable to delete the registry, here I believe the permission to delete the registry key will not be inherit to the executable.

    Do you have any suggestion on this case.

    Many thanks,


  7. cjacks says:

    Hi Hana,

    If the exe the msi is launching is a deferred custom action, change the custom action type to add the msidbCustomActionTypeNoImpersonate bit, and we will stop impersonating the launching (non-admin) user, and it should work.



  8. Hana says:

    Hi Chris,

    Many thanks for all previous advice.

    Here I have another problem, I tried to fix an application that required unlocking on the HKLMSoftware[Application_Name].

    Normally this should be virtualized, but in fact, it doesn’t. I try to track if any administrive privilege using SUA but the above key is not tracked to use administrive privilege.

    Tried to applied both ForceAdmin and VirtualRegistry on this application but not working. Thinking of it might required any module to make the Shim working, hence I tried to check in procmon, but there is zero entry in procmon showing that the application trying to access the key.

    However, once I unlock the key, it work properly.

    Do you have any idea on this?

  9. cjacks says:

    Hi Hana,

    If procmon says that nobody at all is using the key, then changing the ACL clealry can’t be fixing anything. Check the virtualization event log to see if there are any events there, and double check in ProcMon. Changing permissions on an unused key by definition fixes nothing – we must be missing someting here.



Skip to main content