Skip to main content
Participant
January 22, 2024
Answered

AcroCEF.exeの挙動について

  • January 22, 2024
  • 1 reply
  • 3493 views

Windows11のPCでAcrobat Readerを起動し、社内の共有フォルダにあるPDFのファイルを編集・保存した後に、該当PDFファイルを格納しているフォルダの名称を変更しようとすると、「別のプログラムがこのフォルダーまたはファイルを開いているので、操作を完了できません。フォルダーまたはファイルを閉じてから再実行してください」とメッセージが出ます。

Acrobat Readerは表面上終了しているように見えるのですが、Windowsのリソースモニターを起動し、CPUのタブで「関連付けられたハンドル」を観察していますと、AcroCEF.exeが表示され、これが消えるまでは使用中の扱いとなって、フォルダの名称は変更できませんでした。

リソースモニターで都度プロセスを強制的に終わらせるのは運用上支障があるので、何か解決策があれば、ご教示ください。

 

Acrobat Readerのバージョン:2023.008.20470

事象が発生した時期:2024/1/5以降に確認(複数のユーザーで頻発しています)

    This topic has been closed for replies.
    Correct answer Quick Timer

    クラッシュ時の情報収集系の

    Adobe Crash Processor
    Adobe Crash Reporter
    AdobeCRDaemon
    LogTransport

    以下のリソース毎に合計6ファイルあります
    AdobeCrashReporter.framework
    AdobeResourceSynchronizer
    RdrCEF
    RdrCEF Helper
    RdrCEF Helper (Renderer)
    RdrCEF Helper (GPU)

    フィアル共有系って事なら
    AdobeResourceSynchronizerに内包されている
    Adobe Crash Processor
    Adobe Crash Reporter
    AdobeCRDaemon
    LogTransport
    のログを優先して調べてみるといい『かも』しれません

     

    留意点としては

    私の環境依存の可能性もありますが

    AdobeCrashReporter.frameworkと

    AdobeResourceSynchronizer.appは

    アプリケーションを終了しても残ります。

    なので

    Adobe Crash Processor
    Adobe Crash Reporter
    AdobeCRDaemon
    LogTransportはアプリケーションを終了していても

    起動される事があると『私は』思っています。

    なので

    Adobe Crash系のプロセスがアプリ終了後に残るのは『ありえる』

    もちろん、終了しないのは不具合ですよね…うーん

    私は今

    Acrobat Readerは最新版を利用していますが

    AcrobatProは旧バージョンの22xを利用しているので

    最新の環境ではないので

    あくまでも
    参考まで

     

    1 reply

    Quick Timer
    Inspiring
    January 23, 2024

    AcroCEF
    中身はChromiumブラウザだから
    目につく処理としては『ホーム画面=ようこそ画面』の描画かな?
    あとは、クラウドとのファイルのやりとり?もになっている『かも』
    ブラウザなのでキャッシュを持ちますし
    ログも吐きますので
    利用者の『ディスク性能』に若干の依存があるかな…

    共有フォルダ=ファイルサーバーなら
    サーバー側が、セッションを離さないとか
    サーバー側のディスクの書き込み遅延も想定内だから
    サーバー側のディスク関係のログは見ておいた方が良いかな

    あと、クライアント側のアンチウィルス等が
    セッションの終了を待たせているのも想定範囲なので
    監視の除外設定ができるならAcroCEFを除外するとか?
    アンチウィルスのクライアント側のログ見た方が良いかも?

    私はMacユーザーなのでアレですが
    試してみてもいいかもしれないのが
    設定>一般の ホーム画面を表示 をしない設定に
    起動時のメッセージを表示 しない設定に
    クラッシュレポートを送信 しない設定
    最後のセッションから開かない
    オンラインストレージ非表示
    とか?
    かなぁ
    あと、キャッシュされているファイル数が多くなり過ぎているようなら
    キャッシュのクリアしてもいいかも(でもこれが原因だと定期的となるな…)
    参考まで

    Participant
    January 23, 2024

    返信をありがとうございました。

    記載されている内容を試して改善されるか試してみます。

     

    その後も観察を続けていると、AcroCEF.exe以外にAdobe Crash Processor.exeが残ってフォルダ名称の変更を阻害する場合もあるようです。
    エンドユーザーの声を集めると、今月に入ってから気になるようになったとの事で、23.008.20458(1/4リリース)以降で何かが変わっているのかもしれません。

    Quick Timer
    Quick TimerCorrect answer
    Inspiring
    January 23, 2024

    クラッシュ時の情報収集系の

    Adobe Crash Processor
    Adobe Crash Reporter
    AdobeCRDaemon
    LogTransport

    以下のリソース毎に合計6ファイルあります
    AdobeCrashReporter.framework
    AdobeResourceSynchronizer
    RdrCEF
    RdrCEF Helper
    RdrCEF Helper (Renderer)
    RdrCEF Helper (GPU)

    フィアル共有系って事なら
    AdobeResourceSynchronizerに内包されている
    Adobe Crash Processor
    Adobe Crash Reporter
    AdobeCRDaemon
    LogTransport
    のログを優先して調べてみるといい『かも』しれません

     

    留意点としては

    私の環境依存の可能性もありますが

    AdobeCrashReporter.frameworkと

    AdobeResourceSynchronizer.appは

    アプリケーションを終了しても残ります。

    なので

    Adobe Crash Processor
    Adobe Crash Reporter
    AdobeCRDaemon
    LogTransportはアプリケーションを終了していても

    起動される事があると『私は』思っています。

    なので

    Adobe Crash系のプロセスがアプリ終了後に残るのは『ありえる』

    もちろん、終了しないのは不具合ですよね…うーん

    私は今

    Acrobat Readerは最新版を利用していますが

    AcrobatProは旧バージョンの22xを利用しているので

    最新の環境ではないので

    あくまでも
    参考まで