Jump to content
The simFlight Network Forums

Make Rwys not running


Recommended Posts

Hello, Make Rwys has stopped working properly.  When I start it I get the windows user account control box, press run and the MakeRwys grey box appears for about a second and then disappears.

I am using MSFS and it has worked correctly in the past.

The only file generated in the MakeRwys folder is the Runways.txt file.

Link to comment
Share on other sites

10 hours ago, Tigerhawk said:

The only file generated in the MakeRwys folder is the Runways.txt file.

And what does that say (the clue will likely be in there)? What has changed since it worked for you? Have you added scenery to MSFS since then? And what exactly is this "windows user account control box"?

Don't forget -- you must run it "as administrator", otherwise it probably won't be able to access the scenery files (depending how you installed MSFS).

Pete

 

Link to comment
Share on other sites

Thank you Pete,

I believe all that has changed is the recent MSFS SU5 and WU6, that was why I was running it as the airports needed updating for PF3.

I have attached the file.

Yes, I was running it as Admin, and the User Account box is the "Do you want to allow this app from an unknown........ etc etc

The following was in the Windows Event Viewer:-

- <System>
  <Provider Name="Application Error" />
  <EventID Qualifiers="0">1000</EventID>
  <Version>0</Version>
  <Level>2</Level>
  <Task>100</Task>
  <Opcode>0</Opcode>
  <Keywords>0x80000000000000</Keywords>
  <TimeCreated SystemTime="2021-09-13T13:51:47.3186544Z" />
  <EventRecordID>25497</EventRecordID>
  <Correlation />
  <Execution ProcessID="0" ThreadID="0" />
  <Channel>Application</Channel>
  <Computer>255329-1-1</Computer>
  <Security />
  </System>
- <EventData>
  <Data>MakeRwys.exe</Data>
  <Data>5.1.2.7</Data>
  <Data>60bf66cb</Data>
  <Data>ucrtbase.dll</Data>
  <Data>10.0.19041.789</Data>
  <Data>2bd748bf</Data>
  <Data>c0000409</Data>
  <Data>0000000000071208</Data>
  <Data>3e5c</Data>
  <Data>01d7a8a67e291090</Data>
  <Data>C:\FS_Addons\MakeRwys\MakeRwys.exe</Data>
  <Data>C:\Windows\System32\ucrtbase.dll</Data>
  <Data>54429960-59e5-4bd3-9b4f-70c74e232e9e</Data>
  <Data />
  <Data />
  </EventData>
  </Event>


The ucrtbase.dll file has a date modified of 25/02/21 so has not changed recently.

Hope this helps.

Runways.zip

Edited by Tigerhawk
Link to comment
Share on other sites

8 hours ago, Tigerhawk said:

Hope this helps.

Thanks. This is identical to a problem reported in the Pilot2ATC forum on AVSIM.

The problem is that your Windows 10 (I assume?) appears not to have long pathnames allowed.

The normal maximum is 260 characters, but this restriction can be overridden by using the \\?\ prefix.  You'll see that in the list of folders to be scanned in your Runways.txt file.

I'll reproduce my answer given to that other user. If this turns out to be a common occurrence I will probably have to add this advice to the documentation.

----------------------------------

From Windows documents I'd assumed the \\?\ prefix would work no matter which build of Windows is being used -- it was okay on three different versions on PC's I have. However, comparing the last line logged on your system with the file generated on mine, the very next line which should have been logged would show a pathname longer than 260 (discounting the "" envelope, which isn't used in the actual windows calls). And that's the first path longer than 260, at just 261 characters!

Perhaps I should log also the version and build number of the Windows version in use. But could you tell me (use WinVer) please? And maybe try to update.

Using Google I have found this:

4.3 Enabling Windows Long Path (Windows 10 - 1803 build)
  1. Click Window key and type gpedit. msc, then press the Enter key. ...
  2. Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem.
  3. Double click Enable NTFS long paths.
  4. Select Enabled, then click OK.

Could you try that please?

There's also a way of editing the Registry instead. See

https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/

Let me know please.

Pete

 

Link to comment
Share on other sites

Hi Pete,

No, sorry, exactly the same result after making that change. The last file entered in the runways.txt was the same as previously so I haven’t attached it this time  

I am on Windows 10 Pro - build 19043.1202 in case that makes a difference?

I last run MakeRwys successfully in July (after the last MSFS World Update) so I presume it may be Windows updates that have caused this as there have been several since July?

 

Edited by Tigerhawk
update
Link to comment
Share on other sites

1 hour ago, Tigerhawk said:

I am on Windows 10 Pro - build 19043.1202

Hmm. It is working here with the latest MSFS WU6 and Windows 19043.1165. I'll try updating to 1202 (or later?) to see if that makes any difference, but to be honest I'm perplexed. It is definitely related to long pathnames, but what the steps outlined in the Mcrosoft help on that don't help i don't understand.

Did you try both suggestions? if not, please do try the other.

Meanwhile i'll investigate whether I can "fiddle" it by changing "current directory" and using just the local path, or maybe automatically creating linked folders with shorter names.  In fact you could try that manually. See

https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/

A symbolic link to "C:\Users\David Hawxwell\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe" might work.

Otherwise, the changes I would have to make to MakeRunways to use partial pathnames are rather complex, as the files it generates go locally.  I'll have to "tread carefully". So it may take a week or so before I have anything to test for you, but I'll definitely take a look at this.

Pete

 

Link to comment
Share on other sites

Thanks for your efforts Pete. 
I did use the gpedit  method first, though when that didn’t work I also checked the registry method and there was a “1” entry against the long file names entry. 
I’ll have a look at resetting the gpedit back to off and set it using the registry method tomorrow afternoon. 
I’ll also have a look at the symbolic link method as well and report back. 

Link to comment
Share on other sites

22 hours ago, Pete Dowson said:

 

A symbolic link to "C:\Users\David Hawxwell\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe" might work.

 

 

Hi Pete,

I have updated Windows to 19043.1237 also.

I've tried using both the gpedit and registry methods of enabling long path names, but still with exactly the same outcome.

I've had a look at the symbolic link instructions.  I don't know if I'm being dense, but I'm afraid I haven't a clue how to do this to enable MakeRwys to use the link, or even how to even create the link or which type!

Any advice?

Link to comment
Share on other sites

1 hour ago, Tigerhawk said:

I've had a look at the symbolic link instructions.  I don't know if I'm being dense, but I'm afraid I haven't a clue how to do this to enable MakeRwys to use the link, or even how to even create the link or which type!

I'm not too sure either as I've never had a call to use them. John knows about them, so I'll ask if he can help.

I've had a look at possible changes in MakeRwys to use relative paths, but it's going to be very difficult, affecting so many different things -- so very error prone.

I really don't understand what has changed since you used the same version ofMakeRwys separately. I'm sure it isn't a Windows update. Could you be now using different security settings or anti-virus programs?

Pete

 

Link to comment
Share on other sites

56 minutes ago, Pete Dowson said:
2 hours ago, Tigerhawk said:

I've had a look at the symbolic link instructions.  I don't know if I'm being dense, but I'm afraid I haven't a clue how to do this to enable MakeRwys to use the link, or even how to even create the link or which type!

I'm not too sure either as I've never had a call to use them. John knows about them, so I'll ask if he can h

To create links, the easiest method is to install the Link Shell extension, which will enable you to create links using windows Explorer. See https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html

John

 

Link to comment
Share on other sites

23 hours ago, John Dowson said:

To create links, the easiest method is to install the Link Shell extension, which will enable you to create links using windows Explorer. See https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html

 

Thanks for your input John,

Unfortunately I find that even more obscure than Pete's suggestion.

I sort of get what a symbolic link is - I presume I need to create a link (e.g - "D/New Link" linked to "C:\Users\David Hawxwell\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe") in order for the file name length to be much shorter?

But what I don't understand is what type of link I need, nor how MakeRwys would then use the "D/New Link" rather than the original as I assume MakeRwys gets the location of MSFS from the Windows registry.

Sorry to being a little confused, like Pete I just cannot understand what has caused this issue?

Link to comment
Share on other sites

6 hours ago, Tigerhawk said:

But what I don't understand is what type of link I need, nor how MakeRwys would then use the "D/New Link" rather than the original as I assume MakeRwys gets the location of MSFS from the Windows registry.

No, not the registry, but the last line in the UserCfg.Opt file, found within the MSFS setup. For example, in my case the last line reads:

InstalledPackagesPath "C:\Users\Pete\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages"

That's what MakeRwys looks for to get the path. It is normally set when you install MSFS according to the location you choose at the time. I expect you could edit that to point to the link instead, but I've never tried it.

But if you don't mind waiting a few more days, I am working on a version of MakeRwys which uses local paths, changing the "current" directory to the main part of the path first. As I said, it's a bit complicated and quite error prone, so after I've tested it here as much as I can I'll send you a version to test.

Pete

 

Link to comment
Share on other sites

5 hours ago, Pete Dowson said:

But if you don't mind waiting a few more days, I am working on a version of MakeRwys which uses local paths, changing the "current" directory to the main part of the path first. As I said, it's a bit complicated and quite error prone, so after I've tested it here as much as I can I'll send you a version to test.

Pete

 

Thanks Pete.
Under the circumstances that seems like the best thing to do! 
I’ll leave it in your capable hands!

Link to comment
Share on other sites

10 hours ago, Pete Dowson said:
17 hours ago, Tigerhawk said:

But what I don't understand is what type of link I need, nor how MakeRwys would then use the "D/New Link" rather than the original as I assume MakeRwys gets the location of MSFS from the Windows registry.

No, not the registry, but the last line in the UserCfg.Opt file, found within the MSFS setup. For example, in my case the last line reads:

InstalledPackagesPath "C:\Users\Pete\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages"

That's what MakeRwys looks for to get the path. It is normally set when you install MSFS according to the location you choose at the time. I expect you could edit that to point to the link instead, but I've never tried it.

Yes, this is what you should try. Create the link as a 'junction' and then update your UserCfg.opt to use this instead of the original full path.

John

Link to comment
Share on other sites

Here is a test version of MakeRwys (5.128). Please try this. It attempts to fix the overlong pathnames problems by changing the current directory before scanning the BGL files. It is working okay here on both my MSFS setups. If this doesn't work then I think there must be something else wrong on your system. But it did all point to pathname length as the crash is occurring when procesing the longest pathname (as far as it gets).

Please run it and let me know. I'd like to see the resulting SceneryList.txt (if one is produced) and the Runways.txt file. Please ZIP these as they will be quite large.

Pete

 

MakeRwys5128_Test.zip

Link to comment
Share on other sites

5 hours ago, Tigerhawk said:

Runways.txt is too big to attach, even after zipping (67.3mb), I've attached the scenery list. I Could send you a OneDrive link for runways.txt if you need to see it?

No, that's okay -- it would only have been important if it hadn't worked. The SceneryList.txt proves it all okay.

I'll release it properly over the weekend.

Thanks,

Pete

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.