Title
CTD (SEH 0xC0000005) in Aircraft Configurator when selecting a livery of a third‑party aircraft while “Airshow Assistant” (Marketplace, streamed) is active
Summary
Selecting a specific livery variant of a locally‑developed third‑party aircraft in the Aircraft Configurator (WORLDMAP_AIRCRAFTCONFIGURATOR) reliably crashes the sim to desktop with an access violation (SEH 0xC0000005). The crash is 100% reproducible and always occurs at the same instruction address, regardless of changes made to the aircraft’s own model/livery data. Disabling the Marketplace add-on Airshow Assistant (developer: touchingcloud, package touchingcloud-util-airshow-assistant) makes the crash disappear completely, with no other change.
Environment
- Sim build: 1.8.14.0, GameBranch “LIVE1.0”
- Platform: PC, MSIX/Marketplace install
- CPU: Intel Core i7-13700KF
- GPU: NVIDIA GeForce RTX 5070 Ti, driver 58129
- Renderer: D3D12, VR inactive
- DevMode: enabled
Packages involved
classicshangar-kl25d(manifest 000.001.000.000) — locally developed third‑party aircraft, package type “Edition” (dev project, not yet published)touchingcloud-util-airshow-assistant(manifest 004.000.007.000) — Marketplace add-on, streamed (not fully downloaded locally)
Steps to reproduce
- Have the Marketplace add-on “Airshow Assistant” installed/streamed and active (it registers a SimConnect connection and a WASM module that stays resident, e.g.
airshowassistant.wasm). - Open the World Map → Aircraft Configurator.
- Select the affected aircraft and pick a specific livery/variant (in our case a custom livery using aircraft-specific attached SimObjects / a “required_tags” based modular-livery model-swap setup — one that had NOT been selected yet in the current session).
- Sim crashes to desktop immediately.
- Disable “Airshow Assistant” in the Content Manager / Community add-ons → the same livery selection now works without any issue.
We also tested with the rolling cache cleared and with a clean rebuild of the aircraft package — the crash persisted identically until the add-on was disabled, and the crash callstack never changed across any of these attempts.
Observed crash signature (identical across 5 separate crash reports)
[OnCrash]
Msg="ThreadProc"
Type="SEH"
Code=0xC0000005
[RawCallstackWin64]
0=["KittyHawkx64_PCSUB.pdb","9EF92434A0857545AD930FC88DD13058",2,74935429]
1=["KittyHawkx64_PCSUB.pdb","9EF92434A0857545AD930FC88DD13058",2,74916939]
2=["KittyHawkx64_PCSUB.pdb","9EF92434A0857545AD930FC88DD13058",2,74912421]
3=["KittyHawkx64_PCSUB.pdb","9EF92434A0857545AD930FC88DD13058",2,74906575]
4=["KittyHawkx64_PCSUB.pdb","9EF92434A0857545AD930FC88DD13058",2,66448590]
5=["KittyHawkx64_PCSUB.pdb","9EF92434A0857545AD930FC88DD13058",2,66449652]
6=["KittyHawkx64_PCSUB.pdb","9EF92434A0857545AD930FC88DD13058",2,63624774]
7=["kernel32.pdb","2CF112889719B5B39B6C71E3E126FD25",1,183479]
8=["ntdll.pdb","46DBF91D5DD5866B9568C9F6E9287DE4",1,699756]
At the moment of every crash, the WASM module list in the report shows:
1=[1,"airshowassistant.wasm","touchingcloud-util-airshow-assistant",8454144,"Dirty",<frame>,3765269347,"SimConnect Dispatch","CallingCallback",<frame>]
i.e. the add-on’s WASM module is in a “Dirty” state with an active SimConnect callback in flight at the time of the crash, every single time.
LastStates at crash time: MainState:GAME SubState:GAME_WORLDMAP MainState:WORLDMAP SubState:WORLDMAP_AIRCRAFTCONFIGURATOR, UI_Scene CurrentScene="PlaneConfig/Variant".
What we ruled out on the aircraft-content side
Before isolating the add-on as the trigger, we did a thorough pass on the aircraft’s own data (this may be irrelevant to the actual engine bug, but is included for completeness since it consumed most of the investigation):
- Verified/fixed real mismatches between glTF node
nameand theASOBO_unique_idextension on a livery-exclusive attached part (leftover artifacts from a 3ds Max clone operation). - Verified all glTF internal references (skin joints, mesh↔material, node↔mesh/skin, accessor/bufferView indices, buffer byteLength vs actual file size) — all internally consistent.
- Verified texture dimensions/formats — all valid.
- Cleared the sim’s rolling cache and did full aircraft rebuilds between attempts.
None of these changes altered the crash signature at all — same callstack, same offsets, every time — which is what led us to suspect an external trigger rather than the aircraft’s own data, and ultimately to the add-on.
Suspected root cause (unconfirmed, for Asobo triage)
It looks like there may be a race/lifetime bug in how the Aircraft Configurator handles attached SimObjects / model swapping (e.g. livery variants using multiple attached parts selected via tags) while a resident community/Marketplace WASM module has an in-flight SimConnect callback (“CallingCallback” / “Dirty” state). We cannot see inside KittyHawkx64_PCSUB.pdb without symbols, so we can’t point to the exact function, but the reproducibility and the consistent “Dirty”/“CallingCallback” state of the add-on’s WASM module at the exact moment of every crash strongly suggests a genuine interaction/lifetime bug rather than coincidence.
Attachments available on request
- Full
AsoboReport-Crash.txt(and 5 matching entries underAsoboReport-OldCrashes\) from%LOCALAPPDATA%\Packages\Microsoft.Limitless_8wekyb3d8bbwe\LocalState\ - Aircraft project (
classicshangar-kl25d) available for repro if needed