WinGDKビルドを長時間プレイしておりロード中にクラッシュしました。
コールスタックは FIoRequest::GetResultOrDie() で、
UE_LOG(LogIoDispatcher, Fatal, TEXT("I/O Error '%s'"), *Status().ToString());
このFatalログによりクラッシュしていたのですが、Shippingビルドのためログを見ることが出来ませんでした。
CrashContext.runtime-xml を見ると
<MemoryStats.TotalPhysical>10413916160</MemoryStats.TotalPhysical>
<MemoryStats.TotalVirtual>29741268992</MemoryStats.TotalVirtual>
<MemoryStats.PageSize>4096</MemoryStats.PageSize>
<MemoryStats.TotalPhysicalGB>10</MemoryStats.TotalPhysicalGB>
<MemoryStats.AvailablePhysical>43618304</MemoryStats.AvailablePhysical>
<MemoryStats.AvailableVirtual>2820870144</MemoryStats.AvailableVirtual>
<MemoryStats.UsedPhysical>4100075520</MemoryStats.UsedPhysical>
<MemoryStats.PeakUsedPhysical>6275411968</MemoryStats.PeakUsedPhysical>
<MemoryStats.UsedVirtual>16823275520</MemoryStats.UsedVirtual>
<MemoryStats.PeakUsedVirtual>17225940992</MemoryStats.PeakUsedVirtual>
<MemoryStats.bIsOOM>0</MemoryStats.bIsOOM>
<MemoryStats.OOMAllocationSize>0</MemoryStats.OOMAllocationSize>
<MemoryStats.OOMAllocationAlignment>0</MemoryStats.OOMAllocationAlignment>
となっており、bIsOOMは0であるもののAvailablePhysicalが41MB程度しかないためメモリ不足を疑っております。
bIsOOMが1になっていなくてもメモリ不足が原因でここでFatalに来てしまうことはあるでしょうか。
お手数ですが、ご確認いただけますと幸いです。
[Attachment Removed]
お世話になっております。
夏期休暇に伴いご連絡が遅くなりまして申し訳ございません。
"bIsOOM=0 でもメモリ不足でこのFatalに来るか？"については、メモリ不足でこのFatalに来る可能性はあります。bIsOOM=1 は UE のアロケータが malloc 失敗を検知して OOM ハンドラを起動した場合にのみ立つフラグで、今回の Fatal は FIoRequest::GetResultOrDie() が I/Oリクエストの失敗ステータスを検出したもので、アロケーション失敗の経路とは別となります。メモリ逼迫はバッキングバッファ確保やデコンプレッションを間接的に失敗させ得るため、bIsOOM が立たないままここに落ちることは起こり得ます。
Shippingではログが取れないため、Shipping以外のビルドで LogIoDispatcher の出力が出ていないか、またはメモリオーバーが出ていない状況かどうかをご確認いただけますと幸いです。
[Attachment Removed]
お世話になっております。ご返答ありがとうございます。
ログ付きShippingビルドで再現させることができました。ご指摘通り
[2026.07.15-01.36.43:465][130]LogIoDispatcher: Warning: Failed reading 262144 bytes at offset 7261126656 (Retries: 0)
[2026.07.15-01.36.43:465][130]LogIoDispatcher: Warning: Failed reading 262144 bytes at offset 7261126656 (Retries: 1)
といったログが出続けておりました。この再現では最終的にGPUクラッシュになりましたが状況を考えるとメモリ不足と思われます。
CrashContext.runtime-xmlのAvailablePhysicalは459MBはあったので256KBぐらいなら取れそうに思えるのですが、断片化しているでしょうか。
[2026.07.15-01.36.43:682][130]LogContentStreaming: Warning: [TextureName] Texture stream in request failed due to IO error (Mip 0-2).間に上記のようなテクスチャロード失敗のWarningもありましたのでVRAMだと連続領域が確保出来なくなっているなどでしょうか。
メモリ不足な状況には間違いなさそうなのですが、何かヒントがあると助かります。
またこの現象が起きている端末は Xbox ROG Ally になります。
[Attachment Removed]
459MBあれば256KBの確保自体はまず失敗しませんが、今回のログは確保失敗ではなく「読み取り失敗」です。offset 7261126656（約6.76GB）から262144バイト（=256KB、IoDispatcherの標準リードブロックサイズ）を読もうとして、プラットフォームの非同期リードAPIがエラーを返し、リトライして最終的に ReadError ステータスに落ちています。つまり、切り分けとしては、CPUヒープの断片化ではない（256KBの IoBuffer は取れているか、取れていても読み込み先のストレージ操作が失敗している）か、ファイル/チャンク層の読み取り失敗（該当オフセットのpak/iostoreチャンクの読み出しがOS/ストレージレベルで返ってこない）のどちらかと推測されます。
WinGDK（Xbox系OS）では、非同期I/Oのバッキングやファイルマッピング、デコンプレッションのために OS/カーネル側のリソースやタイトルメモリ予約を使います。物理空きが極端に逼迫すると、このプラットフォームのリードAPI自体がメモリ関連の理由で失敗を返すことがあり、それが Retries 付きWarningとして表れます。Texture stream in request failed due to IO error というログについても、I/Oエラー起因と明記されている点がポイントで、VRAMの連続領域確保失敗（アロケーション側）ではなく、同じ根本原因のI/O失敗が別サブシステム（テクスチャストリーミング）にも波及していることを示します。つまりシェーダーチャンクもテクスチャMipも、同一時間帯にストレージ読み取りが軒並み失敗している状態です。これは単発のVRAM断片化よりもシステム全体のメモリ逼迫でI/Oパスが崩れているという可能性が高いです。
[Attachment Removed]
ご返答ありがとうございます。
調査したところご指摘通りシステム全体のメモリ逼迫となっていそうでした。
ファストトラベル時だったため、テクスチャの読み込み等でVRAMが不足しメインメモリ側も使おうとしてメモリ不足になった可能性がありそうです。
対応自体はメモリ削減以外になさそうですが、他のPFとの兼ね合いからテクスチャの削減自体は難しいかもしれないため、ファストトラベル前にワーキングセットを解放して物理メモリを確保してみようと思います。
よろしくお願いいたします。
[Attachment Removed]