謎案探討：Runtime Broker大量耗用CPU的問題
今天工作的時候發現，自己的電腦背景被一隻叫做Runtime Broker的處理程序大量耗用CPU運算資源，到網路上發現這隻程式原來是微軟的UWP用來進行背景處理時，會去調用的執行續，他會針對不同的UWP下所建立的Thread，自己一直建立新實體出來。在2015年Windows 10剛發表的時候，據說是設定＞系統＞通知與動作下的「顯示關於Windows的提示」這個設定發生問題，關掉就好（網路上大概找到的都是這個解答）。可是時至2016年了，該修正的東西早就修正完成了，那麼為何還是出現這個看似錯誤的誤動作呢？
打開工作管理員，東想西找，最後才發現我好像是開了Groove程式才開始發生這些問題，在網路找一下果然有人提出這個問題來，可是沒有人有解答。
接下來就是Debug的時間了！
打開工作管理員後，發現Runtime Broker如圖，但是也有另外發現，我並沒有在進行檔案異動的OneDrive好像也默默的在消耗我的CPU運算資源。
再把工作管理員往拉一看，發現不得了，一大堆稱為「Microsoft OneDriveFile Co-Authoring Executable」的處理程序一直不斷的產生與消失，這表示極有可能是Runtime Broker這隻程式去不斷的調用所致。
有了這樣的懷疑推論，直接開「資源監視器」看一下，果然發現兇手，答案就是Runtime Broker在對我OneDrive的音樂檔案進行雜湊（猜測），或許是在建立manifest或index之類的檔案吧。
Don't Worry, you should do nothing!
有了這樣的推論之後就放心了，放給他跑一陣子，在Intel i7 CPU的加持下，過不到30分鐘，我的OneDrive雲端音樂檔案（大約快50GB）就處理完了。一旦處理完成，Runtime Broker耗用CPU的程度就馬上變成0%了。
謎案解除！
後記１
結至2016-12-20為止，微軟仍然沒有針對OneDrive存放大量音樂檔案時，與Groove音樂播放器互動時產生的大量RuntimeBroker.exe，提出有效的修正方案。
若想要針對每次重新開機引發這樣高CPU、高耗能的暫時解決方案，最有可能的方式就是請將OneDrive裡面的音樂利用Script等級的方式複製一份到本地端的音樂資料夾，然後再將Groove APP裡面的音樂資料夾指向到該本地端資料夾，接著在Groove APP中「移除OneDrive音樂資料夾」的參考，如此一來可以先解決目前的困境。
後記２
2017-04 / After Microsoft Creator Update 15063.13 and Windows 10 Version 1703 HotFix（KB4015583），the RuntimeBroker issues seems to fixed.