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 Monday, June 15, 2015 6:45 PM

Hi Joe.Robinson,

The main issu is to change the behavior of the application to create the INI file automatically, right?

In my opinion, this behavior is more related to the operation mechanism of the application.
Considering it is more likely a developing issue, we can try to ask for help from our MSDN Forum. They may have some good advices for you. You may need to contact the application developer for help, too. They are more familiar with this application.
MSDN Forum
https://social.msdn.microsoft.com/Forums/en-US/home

Best regards