Gil

Runways.txt was empty.

Pete, I ran the new MakeRwys.exe and it appears to fail at the same point with the same error. The last action Procmon captured was a directory query of the same directory as before. The event log shows pretty much the same error.

Windows is a strange animal when it comes to path length. Some parts of the OS seem to allow paths of any length (NTSF doesn't care), but others balk at anything over a certain limit. MSFS has exasperated this problem by putting its data files in a folder that's already long: D:\WpSystem\S-1-5-21-1756615077-2606723803-1545869702-1003\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe I've had any number of programs complain about path length when trying to install software within those directories. If the program allows me to specify the install path, I have a sym link defined to shorten the path to something a lot more reasonable. For example: mklink /D D:/msfs "D:\WpSystem\S-1-5-21-1756615077-2606723803-1545869702-1003\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe" That creates a soft link in the root of the D drive called "msfs" that looks and acts exactly like the long path name. The path to the community folder becomes" D:\msfs\LocalCache\Packages\Community That helps a lot of programs, but doesn't complete solve the issue. It's still possible other programs will create long directory paths that exceed a program's limits. I think your method is the best method. Checking for possible overruns and excluding those directories that are too long shouldn't hide too many scenery files or else other programs would he having these issues already.

Pete, I am fairly sure that I know the cause of my problem, now that I've been able to reproduce it. It was at least partly due to an error on my part, but I think my error may have exposed a problem with the MakeRwys.exe utility. Somehow (though it escapes me how this happened) I ended up with a copy of the WorkingTitle source files in my Communities folder. So when MakeRwys searched the directories within the Communities folder, it recursed the folders with those source files looking for files it would normally read for runway data. The folder structure within those source files is deep. The last folder MakeRwys searched was 294 characters long: D:\WpSystem\S-1-5-21-1756615077-2606723803-1545869702-1003\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\Community\fspackages-main\src\workingtitle-vcockpits-instruments-navsystems\html_ui\WorkingTitle\Pages\VCockpit\Instruments\NavSystems\Shared\Templates MakeRwys did a directory query on the directory and found four child directories: 1: Altimeter 2: AttitudeIndicator 3: HSIndicator 4: XMLEngineDisplay The next directory the program would have searched would likely be 304 characters long. I'm just guessing here, but that might be a problem. Is it possible a variable field overflowed? That might have corrupted other data, or even the stack, if the variable was stored on or near the stack. If so, that could have caused the fault that was reported.

It took almost a whole day to download MSFS, but that's done, and MakeRwys.exe now runs just fine. As to the cause, I'm stumped. The mangled reg key call still exists even when MakeRwys works, so that apparently was a false lead. The only thing I can think of now is that perhaps a file that MakeRwys depends on was corrupted. I noticed this morning when I looked at the Procmon log from yesterday that MakeRwys had opened a file within fspackages-main within the Community folder last before the fault, so maybe there was a bad file there. I haven't reinstalled that package yet, so that hasn't been tested. If anything else comes up, I'll let you know.

Pete, I thought I'd let you know my status as I'm working to resolve my issue. I used procmon.exe to see what MakeRwys was accessing when it stopped working, and it appears that it was trying to read a registry key named HKLM\Software\Microsoft\Windows\CurrentVersion\Appx\PackageSidRefMicrosoft.FlightSimulator_8wekyb3d8bbwe Of course there is no such key since it appears that the name is missing a slash between "PackageSidRef" and "Microsoft.FlightSimulator_8wekyb3d8bbwe." There are other similarly named keys, but even that one does not exist. I guess that Windows is trying to access a file that MakeRwys is requesting through a sym link, and is coming up short. I couldn't find where the mangled registry key name came from, but I suspect some registry magic going wrong. So, I'm reinstalling MSFS to see if that will correct the problem. The reinstall seems to be taking longer than the original install because the download speed is a little sluggish. So far I have about 10 out of 154Gb downloaded, so it's going to be a while. I'll let you know how it goes once the program is fully restored. Gil

Yes, I'm running as admin. And I was just looking at the event log and see two entries each time I run the app. One event is at an "Error" level: The other is at an "Information" level. I had to take two screen shots for it to get all of the "General" data. Gil

MakeRwys 5.12 is failing to create files from MSFS 2020 system. When I run the application a dialog box appears that looks like this: This dialog box promptly disappears. (The first run after resetting the system seems to go a little longer than subsequent runs before the next reboot.) The application creates a zero length Runways.txt file in the current directory, but nothing else. I may be the only one having this problem, but what can I do about it, if so? Gil Yoder

I am having a problem using FCR MSFS in which recordings are not being saved. This happened after installing the update to v. 4.5.2102.26. While in a flight I press the red circle button to start a recording. At the bottom of the window I see "Recording..." Then I can press either the red circle button or the white square button, and then I see "Load Flight file for play a situation." There is no prompt anywhere at anytime to save a file or give it a name. This occurs whether or not I run FCR MSFS in admin mode. What can I do to fix this?

@crbascott, It's not so much something I know of that I want or need. Rather it's something I noticed that I'd like to know what it does. If it satisfies a need so much the better. It took me awhile through experimentation to determine what all of the other dials did. I am just wondering if there is something I've missed with this dial or if it's simply nonfunctioning. Gil

I don't think so. The manual mentions the Control window, but does not describe each option. I agree. I suspect it is the right answer. Unfortunately, it doesn't go well. I set the range rings to 10 miles and the variable range to 15 miles. This is the result. If the range ring exists it would show between the 10 and 20 mile rings, but nothing I do makes it appear. Gil

Thank you. I'll give that a try.

Bump. Can anyone answer regarding the "variable range" knob in the above post?

Thanks to everyone with all the suggestions. I just handled about one hour at LAX at 1600 and managed to land all of the aircraft during that period with only one or two goofs. Slowing the planes at first to 200 kts helped me to build up confidence at the final sequence of commands.

Reducing speed is a good idea. I hadn't thought of that. As for traffic so far I haven't been successful enough with a little bit of traffic to allow more than a small handful of approaches to be generated. It might help though for me to create a very light schedule similar to Mark's second approach tutorial. That might help me become more familiar with the terminology before dealing with more traffic. Mark mentioned the CROSS AT AND MAINTAIN command in the third approach tutorial, so I have been using it. Thanks for your suggestions.