Windows10でRuntime Brokerがメモリを食い潰す(追記有)

 Windows 10へUpgrade後のASUS TAICHI21で、Runtime Brokerがメモリを食い潰す事象が散発的に発生しています。
f:id:kachine:20160608090455p:plain
 

 Runtime Brokerについて調べてみると、Microsoft公式に以下の記載が見つかります。
Runtime Broker が大量のメモリを使用している - Windows ヘルプ -

  • Runtime Broker はタスク マネージャーに表示される Windows プロセスの 1 つで、お使いの PC で、Windows ストア アプリのアクセス許可の管理に役立ちます。通常、使用するメモリは数 MB のみですが、場合によっては、障害のあるアプリが原因となって、Runtime Broker が最大で 1 GB 以上の RAM を使用する可能性があります。
  • RAM の使用量が高く、お使いの PC の動作が遅い場合、アプリが問題の原因である可能性があります。Ctrl キーと Shift キーを押しながら Esc キーを押してタスク マネージャーを表示し、 [プロセス] タブで、Runtime Broker が使用しているメモリの量を確認します。Runtime Broker の使用しているメモリが全容量の 15% を超えている場合、PC のアプリに問題がある可能性があります。Runtime Broker が大量のメモリを使用するのを停止するには、一覧で [Runtime Broker] を選び、 [タスクの終了] を選んで Runtime Broker を終了した後、コンピューターを再起動します。

 要約するとRuntime Brokerは、

  • Windows Storeアプリに関するプロセスである。
  • 通常は数MBしかメモリ消費しない。
  • メモリ容量の15%以上消費していれば障害の可能性。
  • その場合はRuntime Brokerプロセスをkillしてrebootせよ。

といった感じのようです。
  

 そう言われても、問題発生時にWindows Storeアプリは使用していません。
 体感的には、Adobe Lightroomで大量にRAW現像している際に発生することが多く、Google Chromeを立ち上げたまま放置しているだけでも発生します。
 

 もう少し調べてみると、以下の投稿が見つかりました。
What is RuntimeBroker.exe and Why is it Running?

So what does it do? Well, the Runtime Broker handles checking if a Metro app is declaring all of its permissions (like accessing your Photos) and informing the user whether or not its being allowed. In particular, it is interesting to see how it functions when paired with access to hardware, such as an app’s ability to take webcam snapshots. Think of it as the middleman between your apps and your privacy/security.

By removing all directories in photo and groove applications Runtimebrooker stops utilizing my CPU !

Solved Runtime Broker Process - Windows 10 Forums

Runtime broker is part of the security subsystem of Universal Apps (then called Metro apps). Essentially, all access to files and other resources goes through the Runtime broker.. so what this means is that it's only accessing files on the behalf of another Universal app. This is probably something like the Photos app or something that searches through indexed files and catalogs them, or indexes them.

 ざっくりと要点を抜粋すると、

  • Windows StoreアプリというかMetroアプリがファイルなどのリソースにアクセスする際にはRuntime Brokerを経由する。
  • PhotosやGrooveアプリの読み込み元ディレクトリを削除すれば、Runtime Brokerによるリソース消費が止まる。

ということのようです。
 

 なるほど、Windows Storeアプリは使っていないが、確かにフォト(Photos app)ならスタートメニューにタイル表示されているから、バックグラウンドで動作しているのでしょう。
f:id:kachine:20160608094557p:plain
 

 さらに、Lightroomで現像したファイルの書き出し先ディレクトリが、フォト(Photos app)の読み込み元になっているため、Lightroomで大量にRAW現像するとRuntime Brokerがメモリを食い潰すという因果関係なら理解できます。
 

 ということで、フォト(Photos app)を立ち上げて設定画面からソースディレクトリを削除しようと思います。
f:id:kachine:20160608094639p:plain
 ディレクトリ名の右に表示された×ボタンから削除できますが、以下のようなダイアログが表示されます。
f:id:kachine:20160608094836p:plain
 [フォルダーの削除]を押下しましたが、「ピクチャには表示されなくなる」とありますが、ピクチャフォルダー(C:\Users\%USERNAME%\Pictures)には何ら変化はありませんでした。恐らく「フォトアプリには表示されなくなる」の誤記ではないかと推測されます*1
 (もちろん、当該ディレクトリや、その内部ファイルは削除されません。)

(追記ここから)
 ややこしいのですが、前述の通りピクチャフォルダー(C:\Users\%USERNAME%\Pictures)は以下の通り、何も変化していません。
f:id:kachine:20160608190205p:plain
 ですが、ライブラリのピクチャはフォト(Photos app)のソースディレクトリを全削除したことに伴い、何もなくなりました。
f:id:kachine:20160608190120p:plain

 ファイルの読み込み/保存ダイアログなどで、ライブラリ経由で画像ファイルにアクセスしている場合には、ファイルが無くなったかと焦るかもしれませんが、実体はピクチャフォルダー(C:\Users\%USERNAME%\Pictures)等のディレクトリに格納されているため、ファイルは無事です。
(追記ここまで)
 

 一旦、この設定でRuntime Brokerが落ち着くか様子を見たいと思います。
 

(2016/6/11追記ここから)
 再度Runtime Brokerが同様にメモリを食い潰す事象が発生した。
 フォト(Photos app)の設定を確認したところ、ピクチャフォルダー(C:\Users\%USERNAME%\Pictures)とOneDriveの写真の2つのソースディレクトリが何故か勝手に復活していた。
 何をトリガにしてソースディレクトリが復活(or 追加)されるのかは特定できていない。
 とりあえず、再度ソースの設定を削除したうえで、今度はスタートメニューへのピン留めも外して、様子を見ることにする。
(2016/6/11追記ここまで)
 

(2016/6/12追記ここから)
 再度Runtime Brokerが同様にメモリを食い潰す事象が発生した。
 また、前日同様のフォト(Photos app)のソースディレクトリが勝手に復活していた。
 いい加減に我慢ならないのでフォト(Photos app)の削除することにする。
(2016/6/12追記ここまで)
 



以上。

*1:PhotosやPicturesといった一般名詞をアプリ名やシステムフォルダー名に利用した弊害で、ローカライズが混乱しているのではと憶測。と、思ったらライブラリのピクチャのことかもしれない。一般名詞の濫用で何を指しているのか解りにくいことになっています。