この質問は、以下のスレッドに関連して作成されました: [Content removed]
<br/>
お世話になっております
<br/>
以前質問させていただきまして、ご提示いただいたCLの内容をマージしたんですが
<br/>
表題の通りFRayTracingGeometryManager.cppのcheckfに引っかかってしまいます
<br/>
checkf(GFrameCounterRenderThread != PreviousFrameCounter, TEXT(“FRayTracingGeometryManager::Tick() should only be called once per frame”));
<br/>
こちらを解消したいのですが確認の方をお願いできないでしょうか？
ご報告ありがとうございます。
checkf(GFrameCounterRenderThread != PreviousFrameCounter, TEXT("FRayTracingGeometryManager::Tick() should only be called once per frame"));は CL#51377533 が追加したものではなく5.6時点ですでに存在しているものであるため、CLによる副作用か、別の問題が表面化した可能性があります。また、このチェックは5.8でも同じ形で残っており、「Tick() が 1 フレーム中に 2 回呼ばれてしまう呼び出し側を修正する」必要があると考えております。Tick() の呼び出し経路については、 FRayTracingGeometryManager::Tick() の呼び出し元は1箇所のみで、これが発生する可能性は以下のどちらかが推測されます。
1.エンジンフレーム内で PostRenderAllViewports() が 2 回実行されている（独自の描画ループ、ローディング／ムービー再生まわりの描画パス、Movie Render Queue 系の再入、RedrawViewports() の明示呼び出し等）
2.GFrameCounterRenderThread が進まないまま 2 回目の呼び出しが来ている（通常は FEngineLoop::Tick 内で GFrameCounter とともに更新されますが、HighResScreenshot 経路や PreLoadScreen 経路など、別途 GFrameCounter を進める処理が絡むケースがあります）
切り分けのため、以下をご確認いただけますでしょうか？
1. checkf 発火時のコールスタック
UGameEngine::Tick / UEditorEngine::Tick のどちらから来ているかをご教示ください。可能であれば、1 フレーム内の 1 回目・2 回目それぞれのコールスタックがいただけると確実です。
2. FRendererModule::PostRenderAllViewports() の冒頭にログを追加
下記のようなログを仕込んでいただき、同一の GFrameCounter 値で 2 回出力されるかをご確認ください。
UE_LOG(LogTemp, Log, TEXT("PostRenderAllViewports GFrameCounter=%llu"), GFrameCounter);3. 発生タイミング
起動直後か、ゲームプレイ中か、特定の機能使用時か（SceneCapture、Movie Render Queue、ローディングムービー、ハイレゾスクリーンショット等）をご教示ください。
4. エンジン改造の有無
独自のエンジンループ、RedrawViewports() の明示呼び出し、描画スレッド周りの改造など、標準のフレーム進行から外れる実装が入っていないかをご確認ください。
・暫定的な回避について
特にこのコールスタックに関する回避策の情報が社内に今のところ見つかっておらず、該当の checkf は DO_CHECK ブロック内にあるため、コメントアウトすることで起動自体は可能になります。ただし、その場合 1 フレームに 2 回 Tick() が走る状態はそのまま残るため、以下の副作用が発生し得ます。
・LastReferencedFrame の更新および参照ベース residency（BLAS の常駐／エビクト判定）の計算が不正確になる
・ReferencedGeometryHandles / ReferencedGeometryGroups が想定外のタイミングで Reset される
・ストリーミングリクエストの発行・完了処理が二重に走る
結果として、BLAS のストリームイン／アウトのタイミングずれに起因する別のクラッシュやアサートを誘発する可能性がありますので、恒久対処としてはお勧めできません。そのため、上記 1〜4 の情報をいただけましたら、エンジン側で追加の対処が必要かどうかを含めて引き続き確認いたします。お手数をおかけしますが、よろしくお願いいたします。
お世話になっております。
breadcrumb の共有ありがとうございます。あわせて、これまでの分析をコードベースで再確認した結果、こちらの前提に誤りがありましたので、まず訂正させてください。
・前回までの分析の訂正
10/5 に「同一 GPU フレームに Scene が 2 本載ることが原因」とお伝えしましたが、これは breadcrumb の読み方が誤っていました。Frame NのbreadcrumbはFEngineLoop::Tickの開始／終了でのみ開閉され、WaitForMovieToFinishループ内のEndFrame()では閉じられません。そのため、ローディング画面中にエンジン Tick が走る構成では、同一Frame Nの下に SceneRender が複数並ぶのは必然であり、RHIフレームが分かれているかどうかとは無関係でした。今回ご共有いただいた breadcrumb の並び（Scene → Slate → WorldTick → SendAllEndOfFrameUpdates → Scene → Slate）は、前回のパッチが意図どおり動作している状態と整合しています。また、9/18 に「v1 のフレームカウンタ前倒しがハングの原因」とお伝えしましたが、その後のパッチでもハングが解消されずこの推測も誤りがあり、推測ベースのパッチを3回お試しいただく形になってしまい、申し訳ございません。
・UE-254119 の修正（CL#51377533）について
社内で改めて確認したところ当該チケットに更新がありまして、当初ご案内した CL#51377533 は、現時点では本件の完全な対策になっておらず、現在の最新6.0で確認された際もこの CL はWaitForMovieToFinishのループ内でGEngine->Tick()の「後」にフレームカウンタを進めるため、直前にFEngineLoop::Tick側で実行された Tick と、ループ 1 周目の Tick が同じカウンタ値で実行され、1 周目で checkf に到達してしまうことが確認されました。弊社内部の検証でも同じ checkf が再現しており、UE-254119 は現在も未解決（今後のバージョンに向けて対応中）の状態です。不完全な修正をご案内してしまったこと、お詫び申し上げます。
・現在の見立て
2回のGPU ハングログには共通点があります。Graphics キューは Scene の PostProcessing 内、AsyncCompute との同期点（InitBloomKernel / LocalExposure）で停止し、AsyncCompute キューは先に進み切っています。XSX の HIX 診断も present queue sync とコマンドリストフェンスの待ちを指しており、Ray Tracing の BLAS 処理ではなく、フレーム境界まわりの同期の問題と考えています。その上で、パッチv1〜v3 のすべてで共通して残っているのはbAllowEngineTick=true+bWaitForManualStop=true
によるネストしたGEngine->Tick()の経路です。この経路では、通常のFEngineLoop::Tickが 1 フレームの前後で行う処理（フレームカウンタ更新、RHITick、Scene の StartFrame、各種 BeginFrame/EndFrame 処理）の大半が省略されたまま Scene 描画が走ります。v1 以前は checkf で先に停止していたため、ハングが観測できていなかっただけである可能性が高いと見ています。
・推奨する対応（構造の変更）
ネストループ内でWorldをTickする構成をやめ、以下の形にすることを推奨します。
これにより1フレーム=Scene1本+Slate となり、フレームカウンタも正規の経路で更新されるため、checkf の問題も含めて解消されます。この構成であれば、これまでお渡ししたFRayTracingGeometryManager::Tickの二重呼び出しスキップやDefaultGameMoviePlayer.cppへの変更はすべて不要になりますので、取り除いていただいて問題ありません。
なお、エンジン側でも将来のバージョンでは、手動停止＋エンジン Tick のローディング画面について、ゲームスレッドをループ内で待機させない方式へ移行する見込みです。ネストループでエンジン Tick を行う現行方式は、今後も安定性の面で推奨できません。
・原因確定のための切り分け
上記の対応と並行して、もし可能であれば現在のパッチ構成のまま、以下を 1 項目ずつお試しいただき、結果をお知らせいただけますと幸いです。こちらで原因を確定するための材料になります。
お時間を頂いており、ご不便をおかけし申し訳ございません。引き続きよろしくお願いいたします。
ご確認いただきありがとうございます、根本的な対応ではなくお手数をお掛けして恐縮ですがどうぞよろしくお願いします。
また、追加でご確認頂いた情報につきましてもお知らせ頂きありがとうございました。情報として追加しておきたいと思います。
お世話になっております、ご確認ありがとうございます
提示いただいた内容についての回答になります
1. checkf 発火時のコールスタック
UnrealEditor-Engine.dll!FRayTracingGeometryManager::Tick(FRHICommandList & RHICmdList) 行 582 C++
[インライン フレーム] UnrealEditor-RenderCore.dll!UE::Core::Private::Function::TFunctionRefBase<UE::Core::Private::Function::TFunctionStorage<1>,void __cdecl(FRHICommandListImmediate &)>::operator()(FRHICommandListImmediate &) 行 471 C++
UnrealEditor-RenderCore.dll!FRenderThreadCommandPipe::EnqueueAndLaunch::__l5::<lambda_1>::operator()() 行 1547 C++
[インライン フレーム] UnrealEditor-RenderCore.dll!UE::Core::Private::Function::TFunctionRefBase<UE::Core::Private::Function::TFunctionStorage<1>,void __cdecl(void)>::operator()() 行 471 C++
[インライン フレーム] UnrealEditor-RenderCore.dll!TFunctionGraphTaskImpl<void __cdecl(void),1>::DoTaskImpl(TUniqueFunction<void __cdecl(void)> & Function, ENamedThreads::Type) 行 1111 C++
[インライン フレーム] UnrealEditor-RenderCore.dll!TFunctionGraphTaskImpl<void __cdecl(void),1>::DoTask(ENamedThreads::Type) 行 1104 C++
UnrealEditor-RenderCore.dll!TGraphTask<TFunctionGraphTaskImpl<void __cdecl(void),1>>::ExecuteTask() 行 706 C++
UnrealEditor-Core.dll!UE::Tasks::Private::FTaskBase::TryExecuteTask() 行 527 C++
[インライン フレーム] UnrealEditor-Core.dll!FBaseGraphTask::Execute(TArray<FBaseGraphTask *,TSizedDefaultAllocator<32>> &) 行 505 C++
UnrealEditor-Core.dll!FNamedTaskThread::ProcessTasksNamedThread(int QueueIndex, bool bAllowStall) 行 779 C++
UnrealEditor-Core.dll!FNamedTaskThread::ProcessTasksUntilQuit(int QueueIndex) 行 668 C++
UnrealEditor-RenderCore.dll!RenderingThreadMain(FEvent * TaskGraphBoundSyncEvent) 行 318 C++
UnrealEditor-RenderCore.dll!FRenderingThread::Run() 行 451 C++
UnrealEditor-Core.dll!FRunnableThreadWin::Run() 行 159 C++
UnrealEditor-Core.dll!FRunnableThreadWin::GuardedRun() 行 79 C++
１フレーム内の１回目・２回目ではなくcheckで止まったタイミングでのコールスタックになります
2. FRendererModule::PostRenderAllViewports() の冒頭にログを追加
ログを追加した所、GFrameCounterが同じ値で二回出力されている事が確認できました
[2026.08.21-09.43.24:642][ 25]LogTemp: Verbose: PostRenderAllViewports GFrameCounter=3025
[2026.08.21-09.43.24:798][ 25]LogTemp: Verbose: PostRenderAllViewports GFrameCounter=3025
3. 発生タイミング
こちらですが以下設定でローディングスクリーンを手動で停止させるようにしているのですが
FLoadingScreenAttributes loadingScreen;
loadingScreen.bAutoCompleteWhenLoadingCompletes = false;
loadingScreen.bWaitForManualStop = true;
loadingScreen.bAllowEngineTick = true;
loadingScreen.MinimumLoadingScreenDisplayTime = 2.f;
loadingScreen.WidgetLoadingScreen = _nowLoadingSlateWidget->TakeWidget();
ログから察するにローディングスクリーン自体は終わっていて、蓋をしている時のアプリケーション側の処理中にcheckに引っかかっているみたいです
4. エンジン改造の有無
複数のCLを取り込んではいますが、エンジンの改造は行っておりません
以上です、引き続きよろしくお願いします
ご返答にお時間を要しており、申し訳ございません。
ここで問題になっているのは、やはり同一フレームで FRayTracingGeometryManager::Tick が2回キューされていることが原因です。PostRenderAllViewports が同じ GFrameCounter で2回呼ばれているログを示すように、bWaitForManualStop + bAllowEngineTick のローディングスクリーンでは、LaunchEngineLoop が先に GEngine->Tick() した直後に WaitForMovieToFinish(true) が再度 Tick するため、1周目だけフレームカウンタが進まないということが推測されます。
この問題はこちらの環境で再現できていないため、修正確認ができておりませんが、おそらく対応は次の2点が必要です。
こちらについては、一例の修正パッチを作成しましたので、こちらが適用可能かどうかご確認いただけますと幸いです。
確認が遅れて申し訳ありません
頂いた修正パッチを適応した所、該当のcheckfには引っかからなくなったのですが
CS機（PS5、XSX）にてGPUハングが起きてしまうようになりました（ハングする絵面はローディングスクリーンで蓋されている場面でタイミングは不定）
[2026.09.10-03.30.32:803][496]LogD3D12RHI: Error: GPU crash detected:
- Device 0 OK (no device removed reason)
[2026.09.10-03.30.32:803][496]LogRHI: Error: Active GPU breadcrumbs:
Device 0, Pipeline Graphics: (In: 0x8122bc48, Out: 0x8122bc47)
(ID: 0x8122b9a4) [ Active] Frame 45496
(ID: 0x8122bb88) [ Active] SceneRender - ViewFamilies
(ID: 0x8122bc5c) [ Active] RenderGraphExecute - %s
(ID: 0x8122bb9e) [ Active] Scene
(ID: 0x8122bc41) [ Active] PostProcessing
(ID: 0x8122bc47) [ Active] Bloom %dx%d
(ID: 0x8122bc48) [ Active] InitBloomKernel
(ID: 0x8122bc4d) [Not Started] VirtualTextureUpdate
(ID: 0x8122bc4e) [Not Started] Submit Lumen surface cache feedback
(ID: 0x8122bc5f) [Not Started] WorldTick
(ID: 0x8122bc68) [Not Started] RenderGraphExecute - Slate
(ID: 0x8122bc67) [Not Started] SlateUI Title = %s
(ID: 0x8122bc6a) [Not Started] RenderGraphExecute - Slate
(ID: 0x8122bc69) [Not Started] SlateUI Title = %s
Device 0, Pipeline AsyncCompute: (In: 0x8122bc6a, Out: 0x8122bc68)
(ID: 0x8122b9a4) [ Active] Frame 45496
(ID: 0x8122bb88) [ Finished] SceneRender - ViewFamilies
(ID: 0x8122bc5c) [ Finished] RenderGraphExecute - %s
(ID: 0x8122bb9e) [ Finished] Scene
(ID: 0x8122bc41) [ Finished] PostProcessing
(ID: 0x8122bc47) [ Finished] Bloom %dx%d
(ID: 0x8122bc48) [ Finished] InitBloomKernel
(ID: 0x8122bc49) [ Finished] FFTBloom SurveyKernel(TexelDiameter=%f)
(ID: 0x8122bc4a) [ Finished] FFTBloom SumScatterDispersionEnergy %dx%d
(ID: 0x8122bc4b) [ Finished] FFTBloom PreprocessKernel
(ID: 0x8122bc5f) [ Active] WorldTick
(ID: 0x8122bc68) [ Active] RenderGraphExecute - Slate
(ID: 0x8122bc6a) [ Active] RenderGraphExecute - Slate
[2026.09.10-03.30.32:803][496]LogD3D12RHI: Error: Shader diagnostic messages and asserts:
Device: 0, Queue 3D:
No shader diagnostics found for this queue.
Device: 0, Queue Copy:
No shader diagnostics found for this queue.
Device: 0, Queue Compute:
No shader diagnostics found for this queue.
[2026.09.10-03.30.32:815][496]LogD3D12RHI: Error: GPU Crashed or D3D Device Removed.
Check log for GPU state information.
[2026.09.10-03.30.34:035][496]LogD3D12RHI: Error: XHIT Log Message:
+-----------------------------------------------------------------------------+
| Writing GPU hang dump |
+-----------------------------------------------------------------------------+
Capturing a subset of MMIO registers at the start...
Capturing SQ dump...
Capturing screenshot...
Capturing GPU state...
Capture was taken from an Xbox Project Scarlett console.
No GCVM protection faults
No MMVM protection faults
No DCN VM protection faults
No ATC faults
No GCEA errors
No CP*_UTCL1_STATUS errors
No CP_HPD_UTCL1_ERROR errors
Capturing graphics command buffers...
Capturing SDMA...
Capturing async compute...
Capturing async compute hwpipe 1 hwqueue 1: size 512 dwords, IB1 0x01000a3f40 RPTR 0x00000024 dwords processing 0
Capturing DDID buffers...
Capturing API objects...
Capturing runtime compiled PDBs...
Capturing SRA history...
Capturing a subset of MMIO registers at the end...
+-----------------------------------------------------------------------------+
| HIX GPU Hang High Level Summary |
+-----------------------------------------------------------------------------+
Hang Type: HIX Internal Error: no human-readable name for Bucket 0x00
Hang Bucket for Automation: HwHangBucket__HixInternalError__Bucket0x00 (0x00000000)
--------------------------------------------------------------------------------
Old/Deprecated Hang Diagnosis follows.
It may provide some additional useful information, but may not be as reliable
as the Autocategorized Hang information provided above.
Old Autocategorized Hang Bucket: 0xffffffff; Name 'Unknown'
The GPU hang dump data was written to file "d:\HIX\gpuhang-2026-09-10-03-30-32.hix".
The GPU hang dump data was also written to development kit file "d:\gpuhang-latest.hix".
You can load the HIX file into PIX to do deeper postmortem analysis.
Note that the ID3D12Device::SetHangCallbacksX API can be used to automate collection of GPU hang data.
The title command processor ME engine was waiting in an infinite loop for a memory location to
change value. The location is 0x0000c00010, and the wait was until the 32-bit value
at that location was != the reference value (23807 (0x5cff))
AND the mask (0xffffffff).
The current value at that memory location is 23807 (0x5cff).
This could be caused by a fence deadlock, memory corruption, usage of the
InsertWaitOnMemory/Wait64BitValueX/Wait32BitValueX APIs, or a driver bug.
The fence memory location 0x0000c00010 corresponds to the present queue sync object 0.
Check for improper resource transition barriers on swap chain resources.
Present queue sync waits can also be a GPU hang false positive caused by failure to progress
on the CPU due to debugger activity or a CPU deadlock in the title.
In IB1 at VA 0x000000aeb6
The title command processor CE engine was waiting in an infinite loop for a memory location to
change value. The location is 0x020036e000, and the wait was until the 32-bit value
at that location was >= the reference value (3 (0x3))
AND the mask (0xffffffff).
The current value at that memory location is 0 (0x0).
This could be caused by a fence deadlock, memory corruption, usage of the
InsertWaitOnMemory/Wait64BitValueX/Wait32BitValueX APIs, or a driver bug.
The fence memory location 0x020036e000 corresponds to the command list fence writeback
within command list API object 0x00007FF430E3AEA0.
This could be caused by problems with resource barrier GPU pipeline synchronization,
or improper reuse of command list allocators.
+-----------------------------------------------------------------------------+
| Next Steps |
+-----------------------------------------------------------------------------+
This GPU hang should be looked at by Xbox Developer Support. Please send the
HIX file and any relevant details to [Content removed].
[2026.09.10-03.30.34:035][496]LogD3D12RHI: Error: XHIT Crash Dump: d:\HIX\gpuhang-2026-09-10-03-30-32.hix
分かりやすくログが出ていたXSXの物を添付させていただいますので、ご確認の方よろしくお願いします
まだコンソールにおいて問題が発生する旨、ご不便をおかけしまして申し訳ございません。ご共有いただいた XSX ログを確認しました。
前回お渡ししたパッチのうち、WaitForMovieToFinish で GFrameCounter / GFrameCounterRenderThread を GEngine->Tick() より前に進めた変更が、コンソール機のGPUハングの原因です。checkf が消えたのはその副作用で、正しい修正ではありません。
対応としては、1つ前のパッチにおいて以下を変更して頂くことになるかと思います。
1. DefaultGameMoviePlayer.cpp の変更は元に戻す
2. FRayTracingGeometryManager::Tick の二重呼び出しスキップだけ残す
先にパッチ A、未適用ならパッチ B のみ適用してください。v1 の GeoManager 側が残っていればパッチ B は不要です。お手数おかけしますが、これでもまだ問題が発生するようでしたら、同様にログを添付していただき、ご連絡頂けますと幸いです。
Patch2.zip(1.79 KB)
ご共有の GPU ログを確認しましたが、前回の v2（FRayTracingGeometryManager::Tick の二重実行スキップ）を入れてもハングが残るのは想定どおりで、今回のログは Ray Tracing ではなく同一 GPU フレームに Scene が2本載っていることが原因です。
これは LaunchEngineLoop が GEngine->Tick()（1本目の Scene）した直後に WaitForMovieToFinish(true) し、待機ループ1周目で再度 GEngine->Tick()（2本目の Scene）しているためです。この2本は RHI EndFrame 前に同じ GPU フレームへ載ります。Graphics が1本目、AsyncCompute が2本目にいる状態で Present 待ちになると、XSX/PS5 でハングします。v1 でフレームカウンタを Tick 前に進めたのは、EndFrame なしでフレーム ID だけ変えたため別のハングになりました。v2 の GeoManager skip は checkf 用で、二重 Scene 自体は止まりません。
対応として、WaitForMovieToFinish(true) の呼び出し元は LaunchEngineLoop の Tick 直後だけです。待機ループの 最初の GEngine->Tick() をスキップしてください。2周目以降は従来どおり Tick します。1フレームあたり Scene 1本 + Slate になり、蓋中の world tick も維持できます。v2 の GeoManager skip はそのままで問題ありません。
最新で充てて頂きたい修正は、添付のパッチファイルだけの部分となります。適用後、同じローディング蓋中の PS5/XSX ハングが消えるか確認をお願いします。残る場合は、そのときの breadcrumb に SceneRender - ViewFamilies が同一 Frame で何本あるかを共有頂けますと幸いです。お手数おかけしますが、よろしくお願いします。
お世話になっております
頂いたパッチを適応したところ、まだGPUハングが起きてしまっています
breadcrumbの情報を添付しますので、ご確認よろしくお願いします
breadcrumbs.txt(14.5 KB)
お世話になっております、推奨する対応で何とかなりそうな目途が立ちました
情報の提供ありがとうございます
原因確定のための切り分けのを試してみた結果ですが以下の通りになります
以上になります、ご確認のよろしくお願いします