Opening my place causes Studio to crash every time, with no user interaction.
The place file itself loads correctly. At the moment load completes, memory is
normal (~3.8 GB). Over the following ~45 seconds, while the main thread is
resolving assets, private memory climbs to 14-18 GB and Studio dies with:
RBXCRASH: FatalRuntimeError (RSL - panic: failed to spawn a fiber)
RBXCRASH: FatalRuntimeError (RSL - panic: 02f8dfb-Kernel,1409)
The main thread is not deadlocked. It keeps logging asset errors right up to the
panic; the hang monitor fires only because the thread is busy, not dead.
This is not system out-of-memory. Machine A has 64 GB of RAM and panics at 14 GB
with plenty free. The panic is a fiber stack allocation failure.
FREQUENCY: 100%. 12 of 12 attempts, two machines, four Studio builds.
FIRST OBSERVED: 2026-07-17, approx. 18:00 GMT+7 (11:00 UTC). Log timestamps
below are UTC as written in the logs.
I believe this place opened normally before this date, but I cannot prove it.
Studio’s log folder on both machines only contains sessions from 2026-07-17;
older logs were removed by the updater. I am NOT claiming a specific version
introduced this – I have no pre-2026-07-17 logs to support that.
— AFFECTED PLACE —
Also reproduces on local .rbxl copies of the same place, including a copy saved
two days earlier and untouched since.
A different, unrelated place opened on Machine B in the same Studio session
loads normally (18 asset failures, no crash). Only this place is affected.
— REPRODUCTION STEPS —
- Open place 97434089875505 in Studio (or a local .rbxl copy of it).
- Do not interact. Do not click anything.
- Watch private memory in Task Manager.
- Place finishes loading at ~3.8 GB, then climbs continuously.
- Studio panics at 14-18 GB, 48-545 seconds after launch.
— REPRODUCTION FILE —
I do not have a minimal repro file, and I want to explain why rather than just
omit it.
The crash needs the full place content, and I cannot reduce the place inside
Studio because Studio panics before the place is usable (roughly 40 seconds of
window, during which the UI is unresponsive). I tried to strip the file offline
with rbx-dom via Lune 0.10.5 (the current release). Its reflection database is
behind the current place format: it cannot read Content-typed properties
(“Failed to get property ‘ColorMap’ - missing default value”), and files it
re-serializes open as an EMPTY DataModel in Studio 0.730. I confirmed this with
an unmodified round-trip control file, which also opened empty – so the failure
is in the round-trip, not in my edits.
I have no way to produce a reduced repro from outside Studio. The full place
file is available on request.
— CRASH DATA, TWO INDEPENDENT MACHINES —
Machine A Machine B
RAM 64 GB 16 GB
GPU RTX 5070 Ti RTX 4060 Laptop
Private commit @ crash 13.0 - 14.5 GB 16.4 - 18.1 GB
Threads @ crash 202 - 204 133 - 136
VAD regions 76,565 - 84,103 95,663 - 102,863
260 KB blocks ~14,600 ~16,000
4 KB regions ~36,000 - 48,900 ~45,400 - 48,900
Reserved ~53.3 GB ~53.4 GB
Crash time 48 - 62 s 100 - 545 s
Machine B commits 17-18 GB on a 16 GB machine (paging heavily). Machine A has
64 GB free and dies EARLIER, at 14 GB. The failure point is not a fixed memory
ceiling.
The dominant allocation band on both machines is ~260 KB (256 KB + 4 KB guard
page), which matches a fiber/thread stack and is consistent with the
“failed to spawn a fiber” panic: the allocator appears unable to place another
stack despite available physical memory.
— CRASH TIMES OBSERVED —
Machine A (local .rbxl, current): 49.2s, 51.6s, 60.8s, 61.8s, 64.6s
Machine A (local .rbxl, 2 days older): 48.5s, 51.2s
Machine A (cloud place): 119.0s
Machine A (0.727, Vulkan session): 84.2s (“failed to spawn a fiber”)
Machine A (0.729): 126.6s
Machine B (cloud place): 100.0s, 102.7s, 119.7s, 131.6s,
349.9s, 544.7s
— ALREADY RULED OUT —
Not the Studio version:
Reproduces on 0.727.0.7271200, 0.729.0.7290838, 0.730.0.7300790,
0.730.0.7300791. Rolling back did not help. (Noting FFlags are
server-delivered, so a rollback does not roll back flag state – mentioning
in case it matters for triage.)
Not plugins:
Reproduces with zero plugins loaded – no user plugins, no cloud plugins,
builtins only. Verified in the log.
Not graphics mode:
Reproduces on Direct3D11 (“Video memory size: 2147483648”,
“[FLog::CreateGraphicsEngine] - 2-Direct3D11”).
Not Team Create:
Reproduces on local files and on the cloud copy.
Not recent edits:
A local backup saved 2 days earlier, untouched, crashes identically and
slightly faster (48.5s).
Not injected overlays:
An early 0.727 dump showed six capture/overlay hooks injected (Overwolf, OBS,
Wallpaper Engine, Medal, TikTok LIVE Studio, and an implicit Vulkan layer
from Cheat Happens/Aurora). I removed all of them. The newest dump confirms
zero overlay DLLs present. It still crashes.
Not machine-specific:
Two unrelated PCs, different GPUs, different RAM, same panic.
Not place-agnostic:
A different place opens fine on Machine B on the same Studio build.
Not an empty-place issue:
A Baseplate opens at ~1.4 GB and is stable.
— PLACE CONTENT STATS —
Read from the .rbxl with rbx-dom. Whole DataModel: 568,689 instances.
Workspace: 1,695 children, 505,318 descendants.
201,237 Part
54,319 Texture
53,768 MeshPart
42,869 Model
37,520 BlockMesh
36,666 Weld
18,813 UnionOperation
16,958 Decal
16,175 SpecialMesh
14,471 SurfaceAppearance
7,821 CylinderMesh
CSG PhysicalConfigData: 72,587 instances, 358.4 MB total
Largest Workspace subtrees by descendant count:
125,671 PUlau Bernadote (Folder)
92,070 Sandy Shores (Folder)
38,692 Model Rumah (Folder)
33,143 Map (Folder)
32,224 WO ElButfly (Folder)
This is a large place. It was working previously at 4-5 GB. 14-18 GB is a 3-4x
increase on content that did not change.
— ASSET RESOLUTION ERRORS (correlation only, cause NOT confirmed) —
Each crashing session logs 120-180 asset load failures across ~57 unique asset
IDs, each retried 5 times (retries are bounded, not looping):
[DFLog::AssetProvider] AssetResolutionWorkflow to get assetid:
.../v1/asset?id=98316804 failed!!
adIndividualItemFailureReason: AssetDelivery403Moderated
adResolutionErrorMessage: Asset is not approved for the requester
adResolutionErrorMessage: Requested asset is archived (AssetDelivery403)
adResolutionErrorMessage: Request asset was not found (AssetDelivery404)
These occur on the same thread and in the same window as the memory growth. I
report this as correlated observation only – I have NOT confirmed it is the
cause. The comparison place that opens fine on Machine B logs only 18 such
failures.
— SYSTEM INFORMATION —
Machine A: Windows 11 Pro 10.0.26200, 64 GB RAM,
NVIDIA GeForce RTX 5070 Ti (Vendor 000010de, Device 00002c05),
Direct3D11
Machine B: Windows 11, 16 GB RAM,
NVIDIA GeForce RTX 4060 Laptop GPU (Vendor 000010de,
Device 000028e0), Direct3D11
Studio versions affected: 0.730.0.7300791, 0.730.0.7300790, 0.729.0.7290838,
0.727.0.7271200
Expected behavior
The place should finish loading and remain open, with memory staying near its
post-load level (~3.8 GB) instead of climbing to 14-18 GB. Studio should not
panic while resolving assets, and a fiber stack allocation should not fail on a
machine with 50 GB of free RAM.
Previously this place opened and was editable at roughly 4-5 GB of memory usage.
A private message is associated with this bug report
