Assetto Corsa EVOでエンジン音が出ない|Windows Update後に発生した不具合と復旧まで

Assetto Corsa EVOでエンジン音が出ない|Windows Update後に発生した不具合と復旧まで

Assetto Corsa EVO(以下ACE)を起動して走ろうとしたところ、エンジン音が聞こえない不具合に遭遇しました。

前日までは普通にプレイできていて、こちらでACEの設定を変更した記憶もありません。思い当たる変化といえば、前夜にWindows Updateが自動で入っていたこと。

最初はゲーム側のファイル破損などを疑いましたが、Steamの整合性チェックなどでは改善せず、Windows側のログまで確認することになりました。

結論からいうと、自分の環境では「KB5127648」をアンインストールして再起動した後、エンジン音が正常に戻りました。ただし、KB5127648そのものが原因だったとまでは確認できていません。

この記事では、実際に発生した症状から復旧するまでに確認したことを、順番に残しておきます。

この記事の追記

  • 追記1|2026年10月21日:同じWindows更新相当が再適用された状態で再検証。ACEのエンジン音とREDLINEの起動はいずれも正常でした。
  • 追記2|2026年10月24日:ACE本体は正常なまま、REDLINE 1.3.7のSmart App Controlによるブロックが再発しました。

初回の症状、10月21日の再検証、10月24日の追加調査を時系列で記録しています。

目次

今回の症状とプレイ環境

発生したのは2026年10月17日。ゲーム自体は動くのに、走行時にエンジン音が鳴らない状態でした。昨日まで普通に遊べていたので、まずは「直前にPC側で何か変わっていないか?」と考えました。

Assetto Corsa EVOの正しくないイメージ:fmod_distance_filter.dll、エラー状態0xc0e90002
当時表示された「正しくないイメージ」。対象はfmod_distance_filter.dll、エラー状態は0xc0e90002。(画像をタップして拡大)

そこで気づいたのが、前夜に動いていたWindows Updateです。ただ、この時点では関連が分からなかったので、まずはACE側から確認しています。今回の環境をまとめると、以下のとおりです。

項目今回の環境・確認条件
発生・復旧確認日2026年10月17日
ゲームAssetto Corsa EVO/Steam版
ゲームのバージョン0.9.1+release.6(当日のゲームログで確認)
OSWindows 11
更新履歴の表示KB5127648(26200.9711)/インストール日:2026年10月17日
関連環境REDLINEを使用。Smart App Controlは当日一度もオフにしていない
復旧時の確認REDLINEを起動せず、SteamからACEを起動。純正車のエンジン音が戻った
検証範囲自分のPC 1台。他の環境は確認していない。再適用後の結果は記事後半に追記

「前夜に更新が動いていた」という記憶と、更新履歴に表示された日付は分けて記録しています。履歴のインストール日は10月17日でした。

最初に試したこと

まず行ったのがSteamのファイル整合性チェックです。ゲームファイルの破損などであれば、ここで修復されるかもしれないと思ったのですが、今回は改善しませんでした。

その後、REDLINEでもゲームデータのチェックを行いましたが、こちらでも症状は変わりませんでした。設定ファイルやmodsの切り分けも試したものの、音は戻らず。

Audio-based FFB Effectsの設定も確認しましたが、当時の画面では0%でした。この設定を変更して直った、というケースではありません。

少なくとも自分の環境では、ここまでの確認だけでは復旧しませんでした。「ファイルをチェックすればすぐ直るだろう」と思っていたのですが、もう少し調べる必要がありそうです。

ACEのログにオーディオ関連のエラーが出ていた

さらにACE側のログを確認したところ、音声に関係しそうなエラーが残っていました。当日の「log-261017-230935.txt」から、該当する部分を抜き出すと以下です。

23:09:38.654  An API call returned FMOD_ERR_FILE_BAD
23:10:03.652  still no audio engine!

エンジン音が出ない症状と、音声処理に関するエラー。調べる方向は少し見えてきましたが、これだけでは「なぜ正常に動かないのか」までは分かりません。そこでWindows側のログも確認してみました。

WindowsのイベントログでCodeIntegrity 3077を確認

CodeIntegrity 3077:2026年10月17日22:54:40、AssettoCorsaEVO.exeとfmod_distance_filter.dllの記録
CodeIntegrity 3077の記録。ユーザー名・PC名は黒塗りしています。(画像をタップして拡大)

Windowsのイベントビューアーを確認すると、2026年10月17日22時54分40秒に、CodeIntegrityのイベントID 3077が記録されていました。

記録にあったのは、ACEの実行ファイルAssettoCorsaEVO.exeがfmod_distance_filter.dllを読み込もうとした際に、署名要件を満たさない、またはコード整合性ポリシーに違反したという内容です。

つまり、ゲーム自体は起動していても、DLLの読み込みがWindows側で拒否されていた記録が見つかったわけです。ACE側の音声エラーともつながりそうですが、これだけでエンジン音が消えた原因のすべてを説明できるとは限りません。

Microsoftの説明でも、3077は適用中のApp Controlポリシーによるブロックを示すイベントです。確認する場合は、番号だけでなく、日時・実行ファイル名・DLL名まで合わせて見てください。
Microsoft:App ControlイベントIDの説明

イベントビューアーでは「アプリケーションとサービス ログ → Microsoft → Windows → CodeIntegrity → Operational」から確認できます。ここまで来て、直前に入っていたWindows Updateを改めて調べることにしました。

KB5127648のアンインストール・再起動後に復旧した

Windowsの更新履歴を見ると、KB5127648がインストールされていました。そこで、切り分けのためにこの更新プログラムをアンインストールしました。

KB5127648(26200.9711)のインストール日が2026年10月17日と表示された更新履歴
当時の更新履歴。KB5127648のインストール日は2026/10/17と表示。(画像をタップして拡大)

操作したのは「設定 → Windows Update → 更新の履歴 → 更新プログラムをアンインストール」です。対象のKB5127648を選び、アンインストール後にPCを再起動しました。

更新を削除する前に:セキュリティ更新を削除すると、その更新で提供された保護も失う可能性があります。ここは自分が行った操作の記録で、同じ症状なら一律に削除すればよいという話ではありません。標準の操作方法と、削除できない更新についてはMicrosoftの案内も確認してください。

すると再起動の途中で、再びWindowsの更新処理の表示が出てきました。この時点では「これで本当に元へ戻ったのか?」という状態です。表示だけでは同じ更新が再インストールされたかも分からないので、ひとまず処理が終わるのを待ちました。

再起動完了後、REDLINEは起動せず、SteamからAssetto Corsa EVOを起動して純正車で確認すると、エンジン音が正常に鳴るようになりました。今回、自分の環境で実際に復旧したのはこのタイミングです。

なお、Smart App Controlは当日一度もオフにしていません。保護機能を無効にして復旧させたわけではなく、オンのまま音が戻っています。

復旧までに試したことと結果を振り返る

同じ症状が出たときに見比べやすいよう、今回の確認と結果を表にまとめました。全員がこの順番で全部試す必要がある、という意味ではありません。

確認・操作自分の環境での結果
Steamのファイル整合性チェック改善なし
REDLINEのゲームデータチェック改善なし
設定ファイル・modsの切り分け症状は変わらなかった
Audio-based FFB Effectsの確認当時の画面では0%。この値を変更して復旧したわけではない
ACEのログを確認FMOD_ERR_FILE_BAD、still no audio engine!を確認
Windowsのイベントログを確認CodeIntegrity 3077に、ACEの実行ファイルと対象DLLの読み込み拒否を確認
KB5127648をアンインストールし、PCを再起動その後の確認で復旧
REDLINEを起動せずSteamからACEを起動純正車のエンジン音が正常に戻った

Windows Updateが原因だったのか?

ここは少し注意が必要です。時系列だけを見ると、Windows Updateが動いた後に不具合に気づき、DLLの拒否記録を確認して、KB5127648のアンインストールと再起動の後に復旧しています。そのため、Windows側の更新が影響した可能性は考えられます。

ただし、KB5127648をもう一度同じ状態で適用して、不具合が再発するかまでは確認していません。再起動だけで直ったのか、それまでの設定の切り分けが影響したのかも、個別には確かめていません。

さらに、アンインストール後の再起動中には更新処理の表示も出ています。「KB5127648だけが直接の原因だった」「Windows Updateが確定原因だった」と断定できる状態ではありません。

区分今回分かったこと
確認できた事実対象DLLのCodeIntegrityブロックが記録されていた。KB5127648のアンインストールと再起動の後、純正車のエンジン音が戻った
考えられる関連Windowsの更新や再起動に伴う状態変化が、症状や復旧に関係した可能性
今回だけでは分からなかったことKB5127648単独での原因確定/再起動だけでの復旧/他PCでの再現
この結果だけでは言えないこと同じ症状なら同じ操作で直ること、REDLINEの関与の有無

原因を確定させるために、わざと不具合を再現するところまでは行っていません。せっかく直ったので、そこまではやりたくないです(笑)。

同じようにエンジン音が出なくなった人へ

ACEで突然エンジン音が出なくなった場合も、いきなりWindows Updateを削除するのではなく、まずSteamの整合性チェックなど、基本的な確認から始めるのがいいと思います。

それでも改善せず、ACEのログにFMOD関連のエラーがあり、Windows側にも同じ実行ファイルとDLLを対象にしたCodeIntegrity 3077が残っているなら、今回の記録が切り分けの参考になるかもしれません。別のソフトに対する3077では、今回のケースと一致しているとはいえません。

Windows Update直後から症状が出た場合は、更新履歴も確認してみる価値はありそうです。ただ、Windows Updateの削除はPC全体に関係する操作なので、同じ症状だからといって無条件にKB5127648を削除することは勧めません。

まずはログと更新履歴を残して、自分の症状と今回のケースがどこまで一致するかを見てください。改善しない場合は変更を重ねず、記録を添えて公式サポートへ相談するのも一つの方法です。

今回はかなり原因を追いかけることになりましたが、最終的にはエンジン音が戻り、また走れる状態になりました。同じように「昨日まで普通だったのに、突然ACEのエンジン音が出なくなった」という人の参考になればと思います。

今後のゲームやWindowsの更新で再発したり、新たに分かったことがあれば追記します。今回の復旧だけを理由に、Windows Updateや保護機能を恒久的に止めるつもりはありません。

追記:翌日、KB5127648が再び更新待ちになった

翌日の2026年10月18日、Windowsをシャットダウンしようとしたところ、再びWindows Updateが入る状態になっていました。

Windows Updateを確認すると、前日にアンインストールしたKB5127648(26200.9711)が再び表示されており、「再起動が必要です」「再起動の保留中」となっていました。

2026年10月18日:KB5127648(26200.9711)が「再起動の保留中」と表示された画面。
2026年10月18日:KB5127648(26200.9711)が「再起動の保留中」と表示された画面。(画像をタップして拡大)

つまり、前日にKB5127648をアンインストールしてACEの音声が復旧したあとも、Windows側では同じ更新が再び適用される状態になっていたようです。

このまま再起動して更新を適用すると、せっかく復旧した状態が再び変わってしまい、原因の切り分けが難しくなるため、今回はいったんWindows Updateを一時停止しました。

2026年10月18日時点では、2026年11月22日まで更新を一時停止しています。

2026年10月18日:更新プログラムを2026年11月22日まで一時停止した画面。
2026年10月18日:更新プログラムを2026年11月22日まで一時停止した画面。(画像をタップして拡大)

ただし、これはKB5127648が不具合の原因だと確定したために恒久的に更新を止めたわけではありません。

今回確認できたのは、KB5127648をアンインストールして再起動した後にACEの音声が復旧し、その翌日に同じKB5127648が再び更新待ちになったというところまでです。

今後、更新を再開した際にACEの症状が再発するかどうかも確認できれば、この記事へ追記する予定です。

追記1|10月21日:同じWindows更新が入った状態で再検証

前回は、Windows 11の更新後にACEのエンジン音が出なくなり、Code IntegrityのログではFMOD関連DLLがブロックされていました。その状態で更新をアンインストールすると音が復旧したため、当時はWindows Updateとの関連を強く疑いました。

ただ、2026年10月21日に改めて確認すると、同じ更新相当がすでに再適用されているにもかかわらず、エンジン音は正常に出ています。つまり、このWindows更新が入っているだけで、必ずACEの音が出なくなるわけではありませんでした。

同じWindows更新がすでに再適用されていた

Windowsの状態を確認すると、Windows 11 25H2/OSビルド26200.9711になっていました。PowerShellでも「RollupFix 26100.9711 = Installed」を確認し、インストール日時は2026年10月19日00時51分30秒でした。

前回は更新をアンインストールしてACEの音が復旧していますが、その後、同じ更新相当が再び入っていたことになります。そこで、この状態でもう一度ACEを起動しました。

再適用された状態でもエンジン音は正常だった

今回はSteamからACEを直接起動しました。ゲームの起動、エンジン音、走行はいずれも正常でした。Code Integrityのログも更新して確認しましたが、前回問題になったfmod_distance_filter.dllに対する新しいイベント3077/3033は出ていません。

前回確認した「更新後にDLLがブロックされ、音が消え、更新のアンインストール後に復旧した」という流れは変わりません。ただ今回は、同じ更新相当が入っていても正常です。KB5127648相当の更新そのものが、恒常的にACEの音声不具合を起こすとは言えない、という結果になりました。

では最初の不具合は何だったのか

最初に症状が出たときは、Windows Update直後にエンジン音が消え、ACEのログにFMOD_ERR_FILE_BADとstill no audio engine!が残り、Windows側ではFMOD関連DLLのブロックも確認しました。そして更新のアンインストール後に復旧しています。この事実自体は変わりません。

ただ、その後同じ更新が入っても問題が起きていないため、Smart App Control/Code Integrityの一時的な判定、Windows Update直後のシステム状態、Microsoft側のクラウド評価や署名確認のタイミングなど、別の条件が重なっていた可能性も考えられます。ここから先は特定できていません。

Microsoftの説明では、Smart App Controlはアプリのインテリジェンスとコード整合性機能を組み合わせ、信頼できない、または署名を確認できないコードをブロックします。イベント3077は適用中のApp Controlポリシーによるブロック、3033は署名要件に関係する記録です。今回もこの仕組みが動いた記録はありますが、なぜ初回だけ音声DLLが止められたのかまでは分かりません。
Microsoft:Smart App Controlの概要
Microsoft:App ControlイベントIDの説明

REDLINE 1.3.6はSmart App Controlにブロックされた

今回もう一つ変化があったのがREDLINEです。前回使用していたREDLINE 1.3.6は、WindowsのSmart App Controlから「発行元を確認できないためブロック」と表示され、RedlineStudio.exe自体が起動できなくなりました。Code Integrityのログにも、REDLINE本体に対するイベント3077が残っています。

REDLINE 1.3.7では現在正常に起動できている

その後、2026年10月20日に公開されたREDLINE 1.3.7を導入しました。10月21日に確認した状態では、Smart App ControlをオンにしたままREDLINE 1.3.7が正常に起動し、そこからACEを起動できました。ACEのエンジン音も正常で、新しいCode Integrity 3077/3033は出ていません。

ただし、REDLINE 1.3.7の公式変更履歴には、Smart App Control対策、コード署名、Code Integrityに関する修正とは書かれていません。「1.3.6ではブロックされたが、1.3.7では今回の環境で正常に起動できた」という結果までに留めます。
REDLINE公式変更履歴

「Engine update available」という表示も一度出た

REDLINE 1.3.7を起動したときに、一度だけ「Engine update available」という通知も表示され、その後は消えました。公式変更履歴では、新しいACEビルドへの対応がアプリ本体とは別の署名済みengineファイルとして配信される場合があると説明されています。

ただ、今回表示された通知が具体的に何を変更したのか、ACEの音声問題やSmart App Controlと関係していたのかまでは分かりません。表示が出た事実だけ記録しておきます。

Windows Update後にPIN画面の挙動も変わった

ACEとは別に、Windows起動時のPIN表示にも変化がありました。更新の再適用後はPIN関連の画面が再び表示されていますが、実際にPINを入力しなくても先へ進みます。

設定を確認すると、「更新後に自動的にセットアップを完了するには、サインイン情報を使用します」はオンになっていました。

Windowsのサインインオプションで、更新後のセットアップにサインイン情報を使用する設定がオンになっている画面
更新後のセットアップにサインイン情報を使う設定はオンでした。個人情報が映る部分は切り取っています。(画像をタップして拡大)

同じ起動時刻のWinlogonログでは認証開始と終了が記録され、終了側のResultは0でした。

Winlogon Operationalログのイベント2で、認証を停止しました、結果0と表示された画面
同時刻のWinlogonログでは認証処理が結果0で終了していました。個人情報が映る部分は切り取っています。(画像をタップして拡大)

Windowsには、更新後の処理を完了するため自動的にサインインするARSO(Automatic Restart Sign-On)という仕組みがあります。今回の挙動とは合いますが、当時はARSO固有のログを記録していなかったため、この仕組みが働いたとまでは言い切れません。ACEのエンジン音とは別の補足として残します。
Microsoft:Automatic Restart Sign-On

10月21日時点での結論

最初の記事を書いた時点では、Windows Updateの後にACEの音が出なくなり、FMOD関連DLLがCode Integrityにブロックされ、更新のアンインストール後に復旧するところまでを実際に確認しました。だからこそ、当時はWindows Updateとの関連を強く疑いました。

その後、同じ更新相当が再適用された現在は、ACEのエンジン音が正常に出ており、新しいCode Integrityエラーもありません。Smart App Controlはオンのままで、REDLINE 1.3.7も正常に起動しています。

10月21日時点では、KB5127648相当の更新が入っているだけで、必ずACEのエンジン音が消えるわけではない、というのが今回の環境で分かったことです。初回の更新時には、Code Integrity/Smart App Controlの判定や、更新直後のシステム状態など、別の条件が重なっていた可能性がありますが、そこまでは特定できていません。

今回あらためて確認して感じたのは、「更新を削除したら直った」だけで原因を決めつけず、その後に同じ更新が入った状態でも再現するのかを見ることが大事だということでした。また状況が変われば、この記事にも追記していきます。

追記2|10月24日:REDLINE 1.3.7のブロックが再発

10月21日の再検証では、REDLINE Studio 1.3.7はSmart App Controlをオンにしたまま正常に起動できていました。REDLINEからAssetto Corsa EVOを起動しても問題はなく、ACEのエンジン音も正常。その時点では新しいCode Integrityの3077/3033も確認されませんでした。

ところが10月24日、同じREDLINE 1.3.7が再びSmart App Controlにブロックされ、起動できなくなりました。

バージョンを変更したわけではなく、10月21日には動いていた1.3.7が、3日後には再び止められた形です。ACE本体は現在もSteamから直接起動でき、エンジン音も正常です。

今回はREDLINE側で何が起きているのか、Code IntegrityのログとWindows上の署名状態をもう少し詳しく確認しました。

Code IntegrityでもREDLINEのブロックを確認

イベントビューアーのMicrosoft → Windows → CodeIntegrity → Operationalを確認すると、REDLINEがブロックされた2026年10月24日17時37分18秒にイベント3077が記録されていました。

対象はRedlineStudio.exeです。explorer.exeがREDLINEを読み込もうとした際に、Enterprise signing level requirementsを満たさない、またはCode Integrity Policyに違反したとして拒否されていました。

REDLINE Studioの実行が拒否されたWindows Code Integrityイベント3077
Smart App Controlの警告だけでなく、Code IntegrityログにもREDLINEのブロックが記録されていた。

Smart App Controlの警告画面だけではなく、Windows側のログにも実際にブロックされた記録が残っています。

REDLINEは完全な「未署名アプリ」ではなかった

さらに同時刻のイベント3089を確認すると、次の情報が残っていました。

  • TotalSignatureCount = 1
  • SignatureType = 1
  • ValidatedSigningLevel = 1
  • VerificationError = 18
  • PublisherName = Redline Studio

ここで分かったのは、REDLINEには署名そのものは存在しているということです。Smart App Controlの表示だけを見ると、単純に「署名されていないアプリなのでは」と考えたくなりますが、実際にはそうではありませんでした。

REDLINE Studioの署名情報を示すCode Integrityイベント3089
署名数1、PublisherName Redline Studio、VerificationError 18を確認。

そこでPowerShellから、現在インストールされているRedlineStudio.exeのAuthenticode署名も直接確認しました。

署名はあるが、Windowsから信頼されていない状態だった

PowerShellで確認すると、SubjectとIssuerはいずれもCN=Redline Studioで、有効期間は2026年9月29日から2036年9月29日、ThumbprintはD47115839CE6055FAC4CC7A896F1A1CE82A4F950でした。

署名自体は存在しています。一方、StatusはUnknownErrorで、Windowsが信頼していないルート証明書で証明書チェーンが終了したと表示されました。

今回の状態は、「署名がない」ではなく、「署名はあるものの、Windowsが信頼する証明書チェーンとして検証できていない」という表現が近そうです。

Mark of the Webも確認したが、Zone.Identifierはなかった

念のため、インターネットからダウンロードしたファイルなどに付くZone.Identifierも確認しました。PowerShellでRedlineStudio.exeのストリームを調べましたが、Zone.Identifierは存在していませんでした。

少なくとも今回確認したファイルでは、Mark of the Webが残っている状態ではありませんでした。

10月21日は動いて、10月24日は止められた

今回一番分からないのはこの部分です。10月21日は、REDLINE Studio 1.3.7をSmart App Controlオンのまま起動でき、REDLINEからACEを起動してもエンジン音は正常でした。新しいCode Integrityエラーも出ていません。

ところが10月24日には、同じREDLINE 1.3.7がSmart App Controlにブロックされています。

REDLINE側の署名は存在しますが、Windowsが信頼する証明書チェーンとしては検証できていません。Smart App Controlではクラウド側の評価も判定材料になりますが、10月21日から10月24日の間に実際に何が変わったのかまでは特定できませんでした。

ここでは原因を決めつけず、同じ1.3.7でも、起動できる時とSmart App Controlに止められる時が実際にあったという結果までにしておきます。

1.3.7でSmart App Control問題が解決したわけではなかった

10月21日時点では、1.3.6でブロックされていたREDLINEが1.3.7では正常に起動できたため、アップデートによって状況が改善した可能性も考えていました。しかし10月24日に同じ1.3.7で再発しました。

そのため、「REDLINE 1.3.7でSmart App Controlの問題が修正された」とは言えなくなりました。REDLINE 1.3.7の公式更新内容にも、Smart App ControlやWindowsのコード署名問題を修正したという記載は確認できていません。

ACE本体は現在も正常なので、Smart App Controlはオフにせず様子を見る

Assetto Corsa EVO本体は、現在もSteamから直接起動できます。エンジン音も正常です。Windows 11 25H2/OSビルド26200.9711で、Smart App Controlはオンのまま使っています。

  • Assetto Corsa EVO:正常
  • エンジン音:正常
  • Smart App Control:オン
  • REDLINE Studio 1.3.7:Smart App Controlにブロックされ起動不可

REDLINEを起動するためだけにSmart App Controlをオフにすることはせず、今のところはREDLINE側のアップデートや署名方式の変更、Windows側の判定変化を待つことにしました。

今回の件はまだ状況が動いているので、また変化があれば追記します。

検証日・更新履歴

更新日:2026年10月24日
検証日:2026年10月17日(初回)/2026年10月21日(再検証)/2026年10月24日(REDLINE再確認)
結果:ACE本体とエンジン音は正常。Smart App Controlはオンのまま。REDLINE Studio 1.3.7はSmart App Controlによるブロックが再発

現時点で分かっていないのは、初回だけACEの音声症状が出た条件、10月21日にREDLINE 1.3.7を起動できた理由、10月24日に再びブロックされた理由、Engine updateの内容、PIN表示とARSOの関係です。

Translate »