Hi there. I am experiencing crashes many times whenever i fly a long distance (>400nm). RAM is healthy. It always happen during approach when I am near to the runway.
Ans: Run FG.
How did you expect FlightGear to respond?
Ans: Work normally.
What did you see instead?
Ans: FG crashed when approaching a runway during flaring.
What version are you using?
Ans: FlightGear 2020.4.0
What operating system?
Ans: Windows 11 Home
Event Viewer:
Faulting application name: fgfs.exe, version: 0.0.0.0, time stamp: 0x6405b145
Faulting module name: ucrtbase.dll, version: 10.0.22000.1, time stamp: 0x00e78ce9
Exception code: 0xc0000409
Fault offset: 0x000000000007c648
Faulting process id: 0x2c40
Faulting application start time: 0x01d9503f724fc045
Faulting application path: D:\Games\FlightGear 2020.4\bin\fgfs.exe
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: 9d8bdf5c-1129-4722-beb3-99d01a22ea52
Faulting package full name:
Faulting package-relative application ID:
Aircraft: CRJ 700 - Family
Routes: A few examples:- EDDM->EPWA and EDDM -> LIRN
Attempt:
1. Replaced FlightGear 2020.4\bin\ucrtbase.dll with Windows\system32\ucrtbase.dll.
2. Remove FlightGear 2020.4\bin\ucrtbase.dll.
3. Windows Update.
4. Install latest nighly.
Thank you.
Not sure if this is helpful, but this is taken from the dump file. Thank you.
When we've had this before, it's been related to interfaction of some particular Windows service packs, and UCRTBase.dll : normally remove the one from FlightGear helps. Did any of the 4 things you tried help?
Hi James, hope you are well.
Unfortunately no, none of them helps. I just tested on 2020.3.17 but didn't have the same problem Are you able to recall what are the service packs? I'm considering whether to remove other related .dll files in bin folder, eg msvcp, vcruntime...etc.
Yes, I'd try removing all the runtime DLLs from the FlightGear bin folder : 99% chance, the issue is one of 'our' ones is wrong for you. Move them to a temp folder on the Desktop, so if you find one which is not in Windows System dir, you can move it back. All the vcXYZ and msvcXYZ ones are worth a try,
Hi James, I removed the runtime DLLs but still getting the same issue, There must be something wrong with the 2020.4 nightly build since it works perfectly on 2020.3.17.
Thank you, James.
We do use different C++ compiler for 2020.4, but we switched that over more or less the day 2020.4 was created, so more than two years ago now. Do you know if 2020.4 used to work for you?
It's worrying if it crashes using the 'correct' system versions of the DLLs, becuase I don't know what the next debugging step might be. Do you get the same crash dump when using all the system DLLs
Hi James, I can't remember when it used to work for me off the top of my head. Probably last year June. And yes, same crash dump when all the system DLLs are used.
Thank you for always helping out, James.
VT,
ucrtbase is the "universal c runtime" module. So the problem is likely an incompatibility between the compiled code you downloaded and the runtime module you have installed on your Windows 10 system.
Appears that you are running the Windows SDK 11 on your Windows 10 system. That shouldn't be a problem as long as your Windows 10 is a supported configuration.
Also appears that your version of the SDK is not the latest version, so I recommend you upgrade it as your SDK version had known issues. If the upgrade fails to resolve the issue, then I would recommend you revert back to the latest version of Windows SDK 10.
As a last resort, you may have better stability if you compile the binaries yourself.
Hi xDraconian, I am thinking of compiling the binaries. Referring to https://wiki.flightgear.org/Building_using_CMake_-Windows, may I know if the repositories mentioned in this article are the nightly or the latest stable version?
Thank you so much.
Hi VT,
Those will retrieve the nightly... i.e. branch 'next'.
On 5/2/23 11:03 AM, VT wrote:
Related
Tickets:
#2795Hi xDraconian, I was able to compile the binaries and did a flight test. However, it crashed halfway. I have attached a screenshot of the debug log. Hope you could help me out with it. Thank you man!
Last edit: scarymovie 2023-05-03
Oh, that's bad. That code is the Nasal garbage collector. PTR(r).obj is set to -1, which is an invalid pointer. So when it tries to read -1->mark , it fails.
This is likely an issue with the CRJ; specifically, an issue within its Nasal code.
This will need to be diagnosed and resolved by the aircraft team.
I'd recommend search through the Nasal code looking to see where that (-1) value is coming from.
A workaround (not a permanent fix, but an attempt to eliminate the crash):
change lines 248/49 from:
change to this:
The above code is located within file simgear/nasal/gc.c
I wouldn't want to make this a permanent fix, because:
- it hides the really problem
- it may just move the crash to occur somewhere else.
So the long-term fix will need to be made by the aircraft team.
Last edit: xDraconian 2023-05-04
Thank you for pointing that out, xDraconian. Shouldn't the value be "1" rather than "-1" as shown in the screenshot? I apologize if I didn't understand correctly. Not sure if your "-1" indicates that something was flagged.
@VT, my apology for the late reply. No, "1" is not the correct value either. The value is expected to be some memory address, so expect some very large number (e.g. 0x3D704469). The number you received was 0xFFFFFFFFFFFFFFFF, which in computer speak is the value "-1". The memory location containing the code that saw the error is that first big number (i.e. 0x00007FF...), so the memory location of the data is often somewhere close to that code location.
Did you give the workaround a try?
Hi xDraconian, I did not try the workaround since you mentioned it would be better to fix the aircraft issue.
However, I'm getting a different error now. Please see the attached image. :)
And below is the debug log. Looks like it is the same issue (please check out the last line) I encountered before this. Thank you so much.
Hi xDraconian, I hope you are doing well.
I have new finding about the issue. Seems like it only happens when I make use of the Route Manager.
I believe the exception occurred in "fgfs.exe!flightplanGhostSetMember(Context * c, void * g, naRef field, naRef value) Line 704 C++" is the culprit.
Thank you, xDraconian.
Hi James. I managed to correct the code of the aircraft which fixed the issue. Please go ahead and close this ticket. Thank you so much for the help, James and xDraconian.