MakeRwys 5.12 Crashing

[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

[Pete Dowson]

2 minutes ago, Gil said:

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?

I don't know. Did you run it "as administrator"? If not you'll need to.

And please check with the Windows Event Viewer. Look in the Windows logs -- Application to see if there are any entries for MakeRwys. If so, copy the details to a reply here for me, please.

Pete

 

[Gil]

Just now, Pete Dowson said:

I don't know. Did you run it "as administrator"? If not you'll need to.

And please check with the Windows Event Viewer. Look in the Windows logs -- Application to see if there are any entries for MakeRwys. If so, copy the details to a reply here for me, please.

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

[Pete Dowson]

The crash itself is type 0xC0000409. That isn't in the official reference list, so I had to google it. This turned up:

Error code 0xc0000409 can be the result of a known issue with the new Windows 10 Insider Preview Build 19624. ... Error code 0xc0000409 may also refer to a critical error in Windows 10 and usually has to do with a registry entry that might have become corrupted.13 May 2020

which is rather worrying.  Further searching suggests:

When you launch an application, you may encounter an exception error 0xc0000409. This error means that there is a malfunction in your system operation. The common reasons always include following:

• The incorrect or failed installation of application that may have left invalid entries in your Windows registry;
• The virus or malware attack;
• The improper system shutdown;
• Corrupted or deleted system files.

There are some good ideas for trying to fix your system there. Here's the link:
https://www.minitool.com/news/0xc0000409.html

Another site says

Seems to be a registry issue for sure. Have you tried or considered a repair install? Heres a tutorial on how to do that if you haven't : Repair Install Windows 10 with an In-place Upgrade - Windows 10 Forums

but that seems to only relate to the error when trying to update win10. In fact many of the references I got were related to Windows Update, but the Registry corruption seems common to many.

The fact that MakeRwys is crashing with this error without even starting to do much, means there's not a lot of trouble-shooting I can do. If trying all the suggestions your find above( or by further Googling) doesn't help the only thing I could consider would be adding logging to zero in on the actual Windows call which is causing the crash, but i'm not sure what that would tell us. I can do that, but it is going to take quite a few iterations -- different builds you download and test.

Pete

 

 

[Gil]

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

[Pete Dowson]

1 hour ago, Gil said:

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. 

Hmm. Very odd. Makerwys doesn't attempt to use the Registry at all, itself. It works by looking in various folders till it finds something it recognises. For example:

%APPDATA%\Microsoft Flight Simulator

%LOCALAPPDATA%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache

I wonder if it actually finds it but it's a SymLink and it is looking that up which is referring to the Registry?

1 hour ago, Gil said:

I guess that Windows is trying to access a file that MakeRwys is requesting through a sym link, and is coming up short.

Ah! Your thoughts followed the same pattern! Seems like you are quite experienced with Windows! Wish I was! 😉

 

1 hour ago, Gil said:

I'll let you know how it goes once the program is fully restored.

Yes, please do!

Pete

 

[Gil]

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 Dowson]

12 minutes ago, Gil said:

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.

Interesting, but you'd think if it was a problem during files processing, assuming it was whilst MakeRwys was reading the data, the error would be a more ordinary crash, like an access violation (0xC0000005). I've not seen the error you did get before. Maybe it's related to a data protection system.

13 minutes ago, Gil said:

I haven't reinstalled that package yet, so that hasn't been tested.

If anything else comes up, I'll let you know.

Okay. Thanks.

Pete

 

[Gil]

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.

[Pete Dowson]

5 hours ago, Gil said:

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?

Is that greater than the MAX_PATH, which is always the size I allow, as it is supposed to truly be the MAX path.

Just checked: yes, the defined MAX_PATH in the default Windows headers is 260. I'm not sure if all the C++ library and Windows API functions will deal with paths longer that MAX_PATH either.  More probably those would blow up with an overlong parameter  -- my code would get a plain ordinary access violation or stack overflow, not that strange 409..

I could probably determine if the path is going to be too long and skip that folder. That's okay if there's never going to be scenery BGLs there.

Pete

 

[Pete Dowson]

I found this:

https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation

Apparently you can change the Registry to enable paths to be longer than MAX_PATH. Only trouble there is that I don't see a way of determining what that max path then is. If there's no limit that won't work for the way MakeRwys builds its tables in memory, and I'm not changing the whole thing.

So i'll go ahead with my proposal -- limiting the paths to MAX_PATH and avoiding any which appear to be longer. I'll log anything like that I see in Runways.txt, and the length of the Max Path seen along with the max actually used, at the end.

Pete

 

[Gil]

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 Dowson]

1 hour ago, Gil said:

I think your method is the best method. Checking for possible overruns and excluding those directories that are too long

Well, I'm not sure I've done this completely. But I've gone through the code using strcpy_s and strcat_s, specifying MAX_PATH as the maximum, rather than my older simple code. This should avoid overruns in my code and also avoid calling the FindFirstFile and FindFile API functions with an overlong path -- I would guess the latter would have been causing the 409 crashes as the stack overrun wouldn't have been detected till the exit from the containing function.

I've not been able to test the changes with an overlong path as Windows stops me adding more subfolders when it detects the path would be too long. So, I have attached the latest version (5.122) for you to check for me, please.

If the program does get one where it cannot append the *.BGL for the individual search, or the path plus a specific BGL file name is too long, there'll be a message about "too long" in the Runways.txt log. It logs the length of the longest path used for a BGL search in any case -- my attempt to make one too long resulted in that being 253. Windows wouldn't allow me to lengthen any of the folder names beyond that. I assume because it needs at least 7 for some system added file just in case.

Pete

 

MakeRwys.exe

[Gil]

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. 

[Pete Dowson]

8 minutes ago, Gil said:

I ran the new MakeRwys.exe and it appears to fail at the same point with the same error.

What were the last lines in the log (Runways.txt)?

I'll check, but I think the fault offset is in an API function.

It may just be that requesting the File find functions to look for the next matching file will cause it to crash unless the provided owning folder has enough room within the MAX_PATH size to accommodate the actual BGL filename.

If that is the case i'm not sure what i can do. set my path limit to MAX_PATH - n where n is the maximum likely file name? and what would that be?

If may be that your only solution is to make that Registry change so those API functions don't crash.

Pete

Pete

 

[Gil]

Runways.txt was empty.

[Pete Dowson]

1 minute ago, Gil said:

Runways.txt was empty.

So it was in the scan to find the correct folders to look in, as I expected. It wasn't in those then found to contain BGL files (as you also surmised).

Pete