Filemon And FSUIPC constant acess

[JRui]

Hi,

In FSX using the latest version of FSUIPC, during the simulation I See a constant acess to the file FSUIPC.ini. Having some impact in the performance of the system. Allways accessing. Try filemon and apply the filter "FSX" and see for your selfs.

And yes I have the registered version.

My question, is, Is this normal? Is this necessary?

[Pete Dowson]

In FSX using the latest version of FSUIPC, during the simulation I See a constant acess to the file FSUIPC.ini. Having some impact in the performance of the system. Allways accessing. Try filemon and apply the filter "FSX" and see for your selfs.

Really? There's certainly no explicit code in it which does this -- the parameters are read initially (a module which is never called again), and when requested in some of the Options pages (a module only used when the Options dialogue is showing), and finally when a flight or aircraft is loaded (to check for aircraft-specific keys, buttons, axes or calibrations.

My question, is, Is this normal? Is this necessary?

I'll check it here and get back to you.

Regards

Pete

[Pete Dowson]

I'll check it here and get back to you.

Okay, I cannot make that happen here. It is as I said. To make it clear I set the FileMon filter to "FSUIPC4.INI;FSUIPC.INI" not just "FSX" because the latter gets thousands of FSX file accesses too.

The FSUIPC4.INI file (never FSUIPC.INI) is accessed initially, during FSX loading, quite a bit (naturally), then when a flight or aircraft is loaded, again when you explicitly reload values in the Options, and when you close the options (to save changes), and finally when FSX is closed.

If something different is happening on your system, can you please show me the FSUIPC4.LOG -- maybe some aircraft or flight is being constantly reloaded? -- and perhaps save the FileMon log so I can see what you see. ZIP them and send to petedowson@btconnect.com.

Regards

Pete

[BC_Holger]

Hi Pete,

just wondering whether you and/or IMM22 found out more about this because I get those constant FSUIPC4.ini logs with Filemon as well; hundreds per minute and not just during those times you named as "normal".

Cheers, Holger

[Pete Dowson]

just wondering whether you and/or IMM22 found out more about this because I get those constant FSUIPC4.ini logs with Filemon as well; hundreds per minute and not just during those times you named as "normal".

If you have problems with SimConnect causing a reconnection every few seconds then this will cause FSUIPC to also see an aircraft reload every few seconds, and each time that happens the INI file will be scanned for aircraft-specific settings.

That is the only way I know of which could cause what you are suggesting. And if this was happening the clearest indication would not be in Filemon logs but in the FSUIPC4 log itself.

There is absolutely no access to the INI file by FSUIPC4 excepting in the circumstances I already expounded. If you have more information and evidence please provide it, but I think you are looking in the wrong place. Try the FSUIPC4 Log and do a Simconnect log.

Regards

Pete

[BC_Holger]

Hi Pete,

thanks for the quick response.

Attached are sample FSUIPC and simConnect log files. Unfortunately, I don't have the knowledge about either module to be able to diagnose the output. I appreciate your help with this.

Cheers,

Holger Sandmann

FSUIPC_logs_Holger_March7.zip

[Pete Dowson]

Attached are sample FSUIPC and simConnect log files. Unfortunately, I don't have the knowledge about either module to be able to diagnose the output. I appreciate your help with this.

There are no problems shown in either log. But the filemon log also only shows a period of just under 4 seconds altogether, so it really shows nothing significant. If you enably filemon logging for all of the FSX activity you'll find lots of non-FSUIPC4.INI access too.

Each of the sequences of "IRP MJ CREATE" to "IRP MJ CLOSE" are, I believe, cause by a single "GetPrivateProfileString", one of the standard Windows API's to read parameters from CFG and INI files. FSUIPC4 does no file I/O on the INI file directly. The entire 6399 lines in the log you provided therefore contains just 914 such reads, which are probably scans for any assignment parameters in the many possible sections in the INI.

I'm not sure what it is that is worrying you. Your INI file is remarkably short, of course, because you are not user-registered. Possibly I should remove some of the INI file interrogation for non-registered users. I will certainly consider that, but it hasn't been a problem in any version of FSUIPC over the last 7 years or so, and I'm not sure what you think the problem is right now.

Incidentally, version 4.072 is no longer supported. Version 4.08 was released last week and there's already an update to 4.081 available above.

If you have any more comments or logs to offer, please do so with 4.08 or later installed.

Regards

Pete

[Pete Dowson]

Attached are sample FSUIPC and simConnect log files.

Further to my last reply, there's something I don't understand, that's for sure.

First, contrary to what I said before, I've checked and done tests (yes, with Filemon too), and, in fact, if you are not user-registered, there is no access whatsoever made to the INI files on any regular basis, not even when you change aircraft or load flights. In fact only changing the front-tab or logging options would cause an access.

Second, my logging (under winXP SP2) shows all the accesses to the FSUIPC4.INI file to be composed of this sequence:

OPEN	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Options: Open  Access: Read	
OPEN	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Options: Open  Access: 00100080	
QUERY INFORMATION	G:\FSX\Modules\FSUIPC4.ini	BUFFER OVERFLOW	FileFsVolumeInformation	
QUERY INFORMATION	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	FileInternalInformation	
QUERY INFORMATION	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Length: 3163	
CLOSE	G:\FSX\Modules\FSUIPC4.ini	SUCCESS		
LOCK	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Excl: No Offset: 0 Length: -1	
QUERY INFORMATION	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Length: 3163	
READ 	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Offset: 0 Length: 3163	
READ 	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Offset: 0 Length: 4096	
UNLOCK	RANGE NOT LOCKED	Offset: 0 Length: -1	
CLOSE	G:\FSX\Modules\FSUIPC4.ini	SUCCESS		

and in the initialisation phase, just the early few seconds, this is repeated about 180 times, producing 2000+ log lines, a long way short of your example which seems to contain the following sequence repeated many more times:

IRP_MJ_CREATE 	X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini	SUCCESS	Options: Open  Access: Read	
FASTIO_LOCK	X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini	SUCCESS	Excl: No Offset: 0 Length: -1	
FASTIO_QUERY_STANDARD_INFO	X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini	SUCCESS	Length: 282	
IRP_MJ_READ 	X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini	SUCCESS	Offset: 0 Length: 282	
FASTIO_UNLOCK	X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini	RANGE NOT LOCKED	Offset: 0 Length: -1	
IRP_MJ_CLEANUP	X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini	SUCCESS		
IRP_MJ_CLOSE 	X:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini	SUCCESS		

So, how do these logs manage to look so completely different? The only two Windows commands used to access the INI file are GetPrivateProfileString and, much less often of course, WritePrivateProfileString.

Are you setting some special options in FileMon to get a completely different level of logging?

My Filemon version is 7.03, what's yours?

Are you using Windows XP SP2 or some other operating system?

Is your drive X: a "normal" hard disk partition, or is it mapped elsewhere? I have a drive X: but it refers to an external hard disk on my Network, used for back-ups in a distant room.

I am rather puzzled as to how you produced that FileMon log.

Regards

Pete

[BC_Holger]

Hi Pete,

I don't have any evidence that those frequent FSUIPC4.ini accesses have any impact on FSX performance. That is to say I haven't done any systematic comparison of FSX perf with and without FSUIPC4.dll. I use FSUIPC as an interface to the SBuilder design utility only, which doesn't require a registered version.

I run Windows XP SP2 and Filemon 7.04 and the X: drive is a 250GB USB2 external HD mounted as a regular drive (without partitions).

The reason I noticed the issue was because I do regular Filemon checks for potential memory leaks of my landscape design projects. For these checks I set Filemon filter options to log errors only and limit the scan to the X and C drives.

When I did a scan of a recent project I got so many FSUIPC4.ini errors (the FASTIO_UNLOCK lines show up as log errors) that I could hardly spot any other read errors. The reasons this "worries" me are (a) the frequency of logs; (b) I don't know whether these file activities are an indication of a more general issue; © frequent file read errors are potential causes of microstutters and memory "leaks" (though I've only know this for a fact with certain texture and effects files); and (d) I never had these kinds of logs with SBuilder and FS9.

BTW, it doesn't make a difference whether SBuilderX is loaded or not; the Filemon logs are the same.

I only sent you four seconds worth of my Filemon log because it just goes on like this forever. How strange that an unregistered version of FSUIPC shouldn't even access the .ini file during flight operations. I'm happy to purchase a registration for FSUIPC if you think that may make a difference.

I will install the latest version of FSUIPC and repeat the tests.

Cheers, Holger

[Pete Dowson]

I run Windows XP SP2 and Filemon 7.04 and the X: drive is a 250GB USB2 external HD mounted as a regular drive (without partitions).

AhI wonder if that makes a crucial difference! Certainly the internal file access routines aren't the same as those, at the level being logged, as external ones.

When I did a scan of a recent project I got so many FSUIPC4.ini errors (the FASTIO_UNLOCK lines show up as log errors) that I could hardly spot any other read errors. The reasons this "worries" me are (a) the frequency of logs; (b) I don't know whether these file activities are an indication of a more general issue; © frequent file read errors are potential causes of microstutters and memory "leaks" (though I've only know this for a fact with certain texture and effects files); and (d) I never had these kinds of logs with SBuilder and FS9.

Well, there's no difference between FSUIPC's INI file access methods between FSUIPC3 and FSUIPC4, and, as I say, for an unregistered install like yours the INI file is only accessed (by FSUIPC) on initialisation and when/if you ever change the few options available to you.

I'm happy to purchase a registration for FSUIPC if you think that may make a difference.

I don't think that will make any difference. I just checked and a filemon log supplied by another user (registered) had the same type of accesses listed as your log. I am now assuming it must be mostly to do with using an external drive, though why the system should continue to access a file which is completely unused, after initialisation, by FSUIPC is beyond me.

If you have an FSX installation you can check on a local hard disk I'd be interested to see the results with that. I'm now suspicious that there are some hideous problems in Windows' own PrivateProfile APIs when on external drives -- maybe most of what you are seeing are automatic retries going on because of those "errors".

Meanwhile I'll try upgrading to filemon 7.04 (instead of 7.03) to see if that makes any difference here.

Regards

Pete

[Pete Dowson]

Meanwhile I'll try upgrading to filemon 7.04 (instead of 7.03) to see if that makes any difference here.

No, 7.04 shows exactly the same as 7.03.

I've tried it also with Wideclient.EXE running from a folder on my Networked backup hard disk, and FileMon's logging for the WideClient.INI (which is accessed via the same API) is also the same. So that strange sequencing your logging shows doesn't apply over networks either.

I have one little portable USB hard disk, which I'll plug in now and try WideClient on that ...

... It's the same on that one too. I simply cannot make FileMon show me anything like the types of operations you have in your log. It's a total mystery! :-(

Pete

[Pete Dowson]

I simply cannot make FileMon show me anything like the types of operations you have in your log.

Aha! Found the "Advanced" option in FileMon. That makes the logging look a bit more like yours, though it makes it totally confusing to me as I don't know what most of the lines really mean. I assume you do and that's why you use the advanced logging? The filemon Help says "The Options|Advanced menu item will satisfy users, such as file system filter driver developers, that want the "raw" view of file system activity shown by previous Filemon versions."

Anyway, enabling this mode has not produced any real differences. The typical sequence now, during FSUIPC4 initialisation only, again, is like this:

IRP_MJ_CREATE 	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Options: Open  Access: Read	                 
IRP_MJ_CREATE 	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Options: Open  Access: 00100080	            
IRP_MJ_QUERY_VOLUME_INFORMATION	G:\FSX\Modules\FSUIPC4.ini	BUFFER OVERFLOW	FileFsVolumeInformation
IRP_MJ_QUERY_INFORMATION	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	FileInternalInformation	         
FASTIO_QUERY_STANDARD_INFO	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Length: 282	                 
IRP_MJ_CLEANUP	G:\FSX\Modules\FSUIPC4.ini	SUCCESS		                                         
IRP_MJ_CLOSE 	G:\FSX\Modules\FSUIPC4.ini	SUCCESS		                                         
FASTIO_LOCK	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Excl: No Offset: 0 Length: -1	                 
FASTIO_QUERY_STANDARD_INFO	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Length: 282	                 
IRP_MJ_READ 	G:\FSX\Modules\FSUIPC4.ini	SUCCESS	Offset: 0 Length: 282	                         
FASTIO_UNLOCK	G:\FSX\Modules\FSUIPC4.ini	RANGE NOT LOCKED	Offset: 0 Length: -1	         
IRP_MJ_CLEANUP	G:\FSX\Modules\FSUIPC4.ini	SUCCESS		                                         
IRP_MJ_CLOSE 	G:\FSX\Modules\FSUIPC4.ini	SUCCESS		                                         

For an unregistered install with no prior INI file (so it creates one) I get a grand total of 1515 entries, all during FSX loading, and nothing thereafter, at all.

So, the mystery persists. Sorry, I've no idea why your system is so different, nor what is actually accessing FSUIPC4.INI when FSUIPC4 is doing nothing.

Maybe I'll need to log each of my accesses to the INI so we can compare FileMon's results to FSUIPC's logs. I'll wait to see what other results you can get first, though.

Regards

Pete

[BC_Holger]

Hi Peter,

well, I'll be darned! After installing 4.081 all the FSUIPC4.ini logs have disappeared from Filemon. In fact, at first I thought that the installation must have been unsuccessful because I couldn't get a single entry during flight loading and operation, even with a specific filter setting of "fsuipc*". However, I then tested SBuilderX and its FSUIPC link works just fine (and at that point a few file I/Os got logged by Filemon).

Don't have a clue why the issue got resolved. I did try before to let FSUIPC re-build an ini file but that didn't make any difference.

I'll keep an eye out for Filemon logs and will let you know if the issue pops up again.

Thanks for your quick help and guidance; much appreciated.

Cheers, Holger

[BC_Holger]

Me again,

if you'd like me to I could re-install 4.072 to double-check whether the logs return; let me know.

Cheers, Holger

[Pete Dowson]

well, I'll be darned! After installing 4.081 all the FSUIPC4.ini logs have disappeared from Filemon.

Aha! In that case it is probably this bug which was responsible, fixed in 4.073:

* The ‘READY’ parameter on the [Programs] section “Run…” parameter in the INI file now does not cause the loaded program to be continually re-loaded after it has terminated.

That would have been trying to read 8 parameters from the INI file quite frequently. The bug was the omission of a flag being set for when it had been done once, reported here in the thread Problems with RUNoptions in FSUIPC4.07 at the end of January.

http://forums.simflight.com/viewtopic.php?t=59973

I should have stuck to my guns, requesting reports only from currently supported versions, instead of wasting three hours on it last night before going to bed at 03:30 am! It was the peculiarly different Filemon logging which misled me completely!

;-)

Regards

Pete