JoeB

Good Day Peter And Everyone Who Have Read This Post, I have discovered the reason for my problem. And, it is not only with regard to fsuipc.ini exclusively, but other files as well. It is how Vista (and in all probability Windows 7) handles file utilization. Mea Culpa. When I performed the file search for fsuipc.ini, I did so using the standard file search. I should have searched using the Advanced search feature and checked the Include non-indexed, hidden, and system files (might be slow) box. Using this search, I found an additional copy of the fsuipc.ini file in the following folder: C:\Users\Flight\AppData\Local\VirtualStore\Program Files (x86)\Microsoft Games\Flight Simulator 9\Modules. It is this file the OS uses when FS9 references the fsuipc.ini file (and most likely other applications referencing other files). By editing this file the problem was solved. I also copied the edited file to the C:\Program Files (x86)\Microsoft Games\Flight Simulator 9\Modules location to ensure both files are in sync assuming that by preference the OS updates the normal file location with the VirtualStore file should a mismatch between the two occur at log off, although this was not investigated. Verifying the fix during the same session and then through a reboot confirmed the fix held. Although I am a retired software engineer, I know little of the inner workings of Microsoft's operating systems. Having said that, I believe that Microsoft uses the VirtualStore file exclusively until the normal file location is updated when it also updates the VirtualStore file. I am assuming the root cause of the problem was a corruption of the normal file's location or some other attribute in the file swap table. Thus, when the normal file location was updated or deleted, the VirtualStore (read: virtual memory) file was not. Why a dual definition of the button and a swap table corruption occurred at the same time is a mystery. But then so is life. Best Regards To All, JoeB

Hi Pete I have been using FSUIPC with FS9, version 3.98a for some time without any problems until recently when I downloaded and installed the Level-D B767-300ER winglet version. Since fsuipc.ini was becoming really messy, I decided to rebuild it from scratch. Reading the manual, I found that to start with a clean file one should remove it in the “modules” folder, and FSUIPC will recreate a clean copy on the next invocation of FS9. I did so, but the “old” assignments were still active although the file could not be found in the “modules” folder. Since Vista x64 is such a persnickety beast, I wondered if the OS had somehow moved the file elsewhere and created a hidden link. Thus, I turned on “Display Hidden Files” and performed an entire search of drive C:. Sure enough, the fsuipc.ini file was found in the, “C:\Users\Flight\AppData\Roaming\Microsoft\Windows\Recent” folder and a link file in the “C:\Users\Flight\AppData\Roaming\Microsoft\Windows” folder. Thinking this must be the problem; I deleted both, performed another search of C: without finding fsuipc.ini, and invoked FS9. The assignments were still active. My next step was to wonder if the fsuipc.ini had been memory cached by the OS. I rebooted the computer, performed a search for the file once again without it being found, and invoked FS9. All assignments, except one were reset/cleared, and only for the Level-D winglet version. This is yoke button 0, aircraft specific (the general assignment for the button is clear), which has the following message in the “status” window of the Button + Switches tab, “This has multiple actions already! Please edit it in FSUIPC.INI.” Well, I am now officially at a loss to explain this anomaly. Any suggestions that you have will be greatly appreciated. Thanks, Joe