The Lack of Wildcard Support for the CorrectFilePaths Shim in Windows Vista

A while back, I write about the Correct File Paths shim. Since that time, I've heard from a number of folks who are using the shim, helping them to configure the command line to fix applications (with the most common explanation being to "quote the pairs" - enclose each redirection pair in quotes, not each individual path, and then space-delimit the pairs you want to redirect).

But there is one specific scenario that seems to be cropping up from time to time - the lack of wildcard support. And where this really makes things complicated is in the root of C.

Say, for example, that you have an application that drops c:myapplog_20080405_152438.log as the log created today, at this time. This happens quite a bit. Some people go down the path of using the command line "c:;%userappdata%" and notice that this leads to the application being even worse off than before. That's because loading up anything off the disk - data files, program files, etc. is a file operation, and gets this shim. (You can configure somewhat the APIs that are intercepted for this particular shim.) Then, keep in mind that c: is going to match absolutely everything on the drive. Yes, it's going to match c:myapplog_20080405_152438.log. It's also going to match c:windowssystem32advapi32.dll. It's going to match c:program filesmy appsource data.mdb. You get the point. The application you shim with this command line is pretty much guaranteed to just crash and burn, because suddenly it can't find any files at all.

In this particular case, you have a workaround. You could use the command line "c:myapplog_;%userappdata%myapplog_ and we'll fix that right up. But what if it's truly completely random? What if sometimes it's c:a1b2c3.log and another time it's c:u3c8e5.log. What do you do then? Unfortunately, the lack of wildcard support means you can't just use "c:*.log;%userappdata%*.log" - and, in fact, you really can't use this shim. Which means you really can't fix this application using shims.

I've seen this enough times to open a bug, and I can get that looked into for a future full version of Windows. But with Windows Sustained Engineering, we don't like to change Windows between releases without justification of business impact. So, if the lack of wildcard support in this shim means you can't fix an application and you're going to end up delaying your deployment of Windows Vista, feel free to use the link on this blog to contact me, and send me (with your work email address) the name of your organization, the application (if it's commercial - otherwise you can just state the nature, you don't need to share anything proprietary with me), and the number of users who can't go to Windows Vista because you can't fix it. Or just post a comment here that expresses the value you'd see in having wildcard support. Whatever you feel comfortable doing - I just want to give you an opportunity to have a voice.

Comments (5)

  1. Aaron Margosis says:

    In other words… the way CorrectFilePaths works is just straight text replacement, starting at the beginning of the file path supplied to the API.  If CFP is configured for "C:;%USERPROFILE%" (and %USERPROFILE% is C:UsersAbby), then when the app tries to load C:WindowsSystem32advapi32.dll, the shim will cause it to try to load C:UsersAbbyWindowsSystem32advapi32.dll instead.

  2. ABC says:

    I understood the concept of CorrectFilePath shim….but I just want to where to give the redirected path…..

    when we are applying this shims, we are applying it to the exe……..but when this path( I mean redirected path) comes into picture?

  3. cjacks says:

    Hi ABC,

    You enter it by pushing the parameters button when the shim is selected. Enter it @ the command line. It’s then invokeed when you call the intercepted apis.


  4. ABC says:

    Hi Chris,

    Please could you give me the exact syntax, how to provide it in PARAMETER field.( I am trying it, just by giving the redirected path itself at this parameter field)

    Is am right?….


  5. Phromang says:


    Thanks for the excellent website.  It’s been a great supplement to the ACT documentation.

Skip to main content