Greetings, 

I have an application that insist on having an INI file in the program folder.  I want to move this INI file to another folder so each user of the application can have their own INI file.

I believe the best approach is to use the CorrectFilePath shim.  I installed the ADK and fired up the Compatibility Administrator (32bit) and created a new database.  I added the CorrectFilePath shim with the following parameter:

• "C:\Program Files (x86)\datacad_17\dcadwin.ini;c:\temp\dcadwin.ini"

I saved and installed the shim (received successful installation message), expecting my troubles to be over.  Unfortunately, the application continues to read and write to the program files folder.

Using procmon, I have noticed some behavior change, though:

If I delete the ini file, it notices that it is gone an recreates it.  Using procmon, I can see it querying C:\temp where the folder was redirected.  However, it gets re-created in programfilesx86.

Using procmon, I can see that this shim is "doing something".  I can see that, when the program starts, it queries C:\temp now.  Before it didn't do that.  I see the following:

• Create File [C:\Temp] [Success]
• QueryBasicInformationFile [C:\Temp] [Success]
• CloseFile [C:\Temp] [Success]

From here, it moves right along to the INI file in ProgramFilesX86.

If I remove the shim -- it never touches the C:\Temp folder (verified in Procmon).

Am I just lucky and found applications that won't work with this shim?  Or am I overlooking something?

I also was curious -- when redirecting files using this shim, do you leave the original file in place, remove it, or does it not matter?

Thanks for lending a hand.  My users and I greatly appreciate it! 

UPDATE: I was re-reading a few articles on shimming, and I started to think about the process.  I started thinking that, maybe a 32bit shim couldn't actually see C:\Program Files (x86) and needed to see program files instead.  I decided to use the variable %programfiles% instead of referencing the x86 directory.  That doesn't seem to have made any changes.

I also dug into the processes and I see that the file being read from fltmgr.sys and, possibly, ntoskrnl.exe.  I've added those both as modules to the shim, but still no luck.

• Edited by Joe.Robinson 12 hours 30 minutes ago