Jump to content

leo5now

Member
  • Posts

    15
  • Joined

  • Last visited

Posts posted by leo5now

  1. Well, it looks like my luck caught up to me, I had a WASM crash after 10 hrs of flying

    RKSI - KSFO, was planning for the arrival until Oakland recleared me to a visual. After changing from ILS to visual approach, the MFD froze and had a WASM crash, this is just insane now. Back to the drawing board, I guess...

    image.thumb.png.ef819d5a4a5c24f45551fdd2561d8186.png

  2. I'd recommend reinstalling the aircraft fully and clearing out the WASM folder for those experiencing the WASM module crash. Before, when a WASM crash happened, for me, it wouldn't indicate the cause in the debug menu, which was weird. If you've verified that it's a WASM crash with the message in the debug menu, then try clearing out the WASM folder or reinstalling the plane if the problem persists. That's what Inibuilds always recommends to users

    • Like 1
  3. 4 minutes ago, Eddie said:

    Thank you all for the very thorough testing. We'll take a look alongside you and see what conclusion we can reach. 

    Hello! Thanks for responding to the thread!

    I think I'm calling it here that the weather radar or any additional information on the ND that constantly adds to the WASM module doesn't affect the WASM crashes. It had before in previous versions, like the glitch in which the TRAF radar on the ND would cause a WASM crash, but in this version, nothing. The flight I am testing right now, RJTT-LFPG, has also reached the 11-hour mark, so this is likely due to user error, where users may not have optimized their settings to account for Virtual Memory usage. VRAM is important, but VM reaching its limit is where the majority of the WASM crashes happen. I'd just recommend users keep an eye on their VM, leave about a 4-5 GB buffer during mid-flight, and then they should be good. FG is also fine, but just make sure it doesn't max out the VM or the VRAM. 

    But feel free to test it out cause in my case, none of the systems here in the plane have any role in contributing to a WASM crash in V1.0.11 atm

  4. 6 minutes ago, ewozza said:

    Just curious, when you select W/X off where are you doing this? Are you turning the system off completely along with Predicted Windshear system within the SURV page? Or are you just not selecting WX on either Captain or FO's ND screen?

    This would bring up a amber warning on the EICAS I believe. 

     

    just the WX on the ND both off on CAPT and FOs

    • Like 1
  5. On 6/1/2025 at 7:52 AM, leo5now said:

    So I may or may not have narrowed down the cause of WASM crashes. 

    I tested this 6 times using a variety of methods using the famous YSSY - KLAX route and im on MSFS2024 SU2. The flight wouldn't last more than 4 hours without a WASM crash but after testing it 6 times I think I finally found the problem but it could be just out of sheer coincidence so I'll have to test it further. 

     

    The solution: OFF WX RADAR

    When I read previous accounts such as the bug in which you cannot use the traffic radar on the ND in previous versions, I focused back on the ND trying to find if there are other methods and I turned to the WX radar.

    My theory is that turning on the WX radar constantly feeds information or new info into the WASM slowly filling it up and causing it to crash especially if you have intense weather ahead. 

    Edit 1: So it turns out that inibuilds released an update months ago ensuring that the WASM module automatically deletes the unused data making space for new data to be allocated. So this can be potentially a bug or user error in the MSFS settings itself since WASM crashes is the behavior when virtual memory runs out completely or isn't allocated properly 😕

    Scenario 1: FG ON, RT SHADOWS OFF, W/X RADAR OFF and ARPT OFF - Completed no WASM crashes

    Testing soon same settings but with weather radar on and arpt on now to see if it will affect the flight

    also important to note that the OANS wasnt used in the departure airport so I will be doing a full typical setup on the A350, like what everyone does for a flight

  6. 3 hours ago, ewozza said:

    Positive move. I might try a flight tomorrow overnight with WX off completely and see how it behaves. Will make my own thread on findings (if any) and link you here @leo5now

    Happy to report that the flight im doing right now (EFHK-RJTT) with RT SHADOWS OFF, TAA, NVIDIA FG, and W/X OFF/, ARPT off, has reached the 11- hour mark!! but then i realized i didnt have real world weather on...y is this not on by default

  7. 21 minutes ago, ewozza said:

    Your findings are really important especially considering I cant get into the plane for long hauls massively regularly (and to be honest my enthusiasm is low to fly this), due to the WASMs I experience about 90% failure rate on this bird. 

    V1.0.10 was good, really stable but V1.0.11 is back to the same old same old. Mine is the same, very much around the 4-6 hour range where it'll WASM. So please do report back!

    In the first test run - FG OFF, RT SHADOWS OFF, DLSS DLAA enabled, and WX off and ARPT off using the YSSY - KLAX route, I was able to push the plane up to 10 hours and then I had to leave it cause I had something in the morning so I wasn't able to land. 

  8. 4 minutes ago, Xenon341 said:

    And don't forget to post the WASM logs as asked by ini in case of WASM crashes.

    Yep will do! Actually majority of my WASM crashes do not show the error message in the module which is more complicated since idk if it's from ini or MSFS or just when you ran out of virtual memory.

  9. 2 hours ago, ewozza said:

    Very interesting. Are you on 2024 by any chance? 

    yep! using 2024 and still ongoing testing, i did another flight (EFHK - RJTT) but I pushed my settings enabling AMD fg and RT Shadows and had a WASM crash 4 hrs into the flight. According to FSElite, it's when you run out of VRAM or when the VRAM isn't properly allocated. So right now im testing with RT shadows off and Nvidia FG on. As well inibuilds already released an update when it deletes previous data inside the WASM module so im not entirely sure if this is a random bug or it could be just user error in terms of the PC specs and how the user sets up the settings in MSFS that causes the Virtual Memory to run out.

    When im done with this flight right now which is (EFHK - RJTT again), I will do another one but this time with WX radar turned on keeping the settings the same. 

    Yes, I do have a lot of time on my hands to troubleshoot this cause I rlly wanna fly this bird hahahahaha

  10. So I may or may not have narrowed down the cause of WASM crashes. 

    I tested this 6 times using a variety of methods using the famous YSSY - KLAX route and im on MSFS2024 SU2. The flight wouldn't last more than 4 hours without a WASM crash but after testing it 6 times I think I finally found the problem but it could be just out of sheer coincidence so I'll have to test it further. 

     

    The solution: OFF WX RADAR

    When I read previous accounts such as the bug in which you cannot use the traffic radar on the ND in previous versions, I focused back on the ND trying to find if there are other methods and I turned to the WX radar.

    My theory is that turning on the WX radar constantly feeds information or new info into the WASM slowly filling it up and causing it to crash especially if you have intense weather ahead. 

    Edit 1: So it turns out that inibuilds released an update months ago ensuring that the WASM module automatically deletes the unused data making space for new data to be allocated. So this can be potentially a bug or user error in the MSFS settings itself since WASM crashes is the behavior when virtual memory runs out completely or isn't allocated properly 😕

    • Like 1
  11. RTX3050

    32GB RAM

    Intel i7-9700

    NAVIGRAPH 

    A350-900 

    MSFS2024

     

     

     

    Route: YSSY/16R DCT NOBAR A579 JORDY DCT 3040S15830E 2844S16301E 2730S16534E 2617S16747E 2256S17235E 1901S17650E 1450S17932W/N0494F370 1042S17621W 0706S17328W 0500S17147W 0327S17033W 0044N16710W 0453N16401W/N0486F390 0626N16245W 0934N15943W 1252N15601W 1455N15327W 1741N14953W 2101N14522W 2355N14118W/N0479F410 2704N13623W 2930N13139W 3136N12611W DCT EDSEL R577 ELKEY RYDRR2 KLAX/25L

    So stepped away from flight simming for a while and was excited to fly the A350 since I knew there were lots of updates until I got a WASM crash right before departure. Interestingly enough, it doesn't say in the log but the avionics, technically everything froze. This wasn't the first time that's happened to me. 

    It frustrated me since I thought after 11 updates, they fixed it but looks like it wasn't fixed yet, and with plans of the release of the ULR variant, concern is growing in me if the WASM crashes aren't fixed yet releasing the ULR will be a bit chaotic. But still appreciate all the work that's been done inibuilds, this aircraft was something I highly anticipated but it fell short with users not being able to enjoy the systems you've developed thanks to the WASM failure. 

    Screenshot_45.png

    • Like 1
  12. Hello! So I've had the A350 for a couple of weeks now and I'm just struggling to get more out of it specifically FPS wise. I recently learned that AMD FSR3 Frame Gen was coming with the SU2 Beta in MSFS. I tried it and it worked flawlessly with my RTX3050. I was able to double the frames The problem is that the A350 instruments freeze after about an hour or so. I checked the data log in FS24 if it was a WASM crash but it turns out it wasn't. Could be something different. I'm aware that inibuilds released a statement that the product may not work well in SU2 beta but this was frustrating to say the least. I tried it with the other planes such as the A330 and no issues with the instruments freezing. Not sure if it's the plane, my graphics card being it an nvidia card and im using AMD frame gen. Or given it's still in beta and propably it's just luck that the instruments didn't freeze on the other planes. 

×
×
  • Create New...