罪魁禍首竟然是它！——螃蟹？

01-27

1/29/2016

6.0.1.7734

這可能是我作為Insider、排查過的最難的bug……我想我會記一輩子……

這個故事也告訴我，有時候不只是排除bug需要靈感。其實排查bug更是需要靈感。

尤其是當你只是個Insider，沒有什麼技術支援或者是代碼可以查看時。

一切源自於好幾個月前，周年更新版的某個insider preview build。

那個時候我注意到，使用groove music播放音樂一段時間以後，我電腦的CPU會頻率降低到一個非常恐怖的水平，0.4GHz - 0.9GHz這樣，根本不超過1GHz。

你知道不超過1GHz的處理器是怎樣的使用體驗嗎？Welcome to Hell of Pentium III!

通常來說我會首先懷疑這是Windows的bug，因為這個問題在10586版本上就不存在。

但是後來隨著我調查的深入，事情變得越發奇怪起來。

一開始，我以為這個Bug是：網易雲音樂、Groove、微信UWP可能會造成CPU性能低下。

其中網易雲和Groove在在線播放音樂時尤其容易重現bug。並且，reddit網友指出，在在線播放音樂的最後十秒時，特別容易復現CPU頻率驟降的問題。而有的時候，CPU驟降完然後就不恢復成正常狀態了，必須要把應用給完全關閉才行！

但是疑點和難題很多啊——

首先，Windows Store App都是沙箱應用，理論上來說不大可能越過沙盒去干擾到CPU的性能。

其次，這些App看起來毫無共同點啊，而且出現bug的時機也很難歸類。

隨後，在調查深入一些以後，我發現Surface Pro 4和Book和一些OEM電腦、甚至是組裝機有這個Bug ，但是又有很多OEM設備一切正常！

還有一些朋友說，14955版本似乎沒有出現該問題；並且來自reddit的一個朋友也說最新的insider build似乎把毛病給修復了。

然後我就花了半個小時來解決vhd 安裝帶來的麻煩……總之最後折騰一番我還是毫無保留地從14393升級到了14955.

屁啊，根本就沒解決好嗎QAQ。。。測試一下明明問題毫無改進啊！！！老外不靠譜啊！！！都是大屁燕子！！！

因此我不得不去多收集更多、更多的資料和證據來推測問題可能的原因。

直到後來，我發現在reddit上主要有兩種關於1607更新後、CPU性能低下的反饋：一種是關於Groove Music的，一種是關於Edge瀏覽器的。新加入bug列表的Edge瀏覽器出現的問題和Groove它們一模一樣：CPU頻率鎖定在1GHz以下，一開始還好好的，後來就必須要把應用程序（如Edge、Groove）完全關閉，才能讓CPU返回到正常的狀態來！

也就是說，Groove、網易雲音樂UWP、微信UWP、Edge瀏覽器，居然有同一個bug，而且後兩者還不知道具體什麼時候能觸發！

如果說他們有什麼共同點的話，那就是，1. 他們都用網 2. 他們都可以出聲 3. 他們都有界面——但3是廢話，所以可以排除

這個時候你也就知道，肯定不是這些APP寫的問題了。而是操作系統或者其他更底層的部件有毛病。

此時我仍然在搜集資料。開始有一些朋友反饋給我他的硬體信息。但是，和Surface相似之處很多，例如，它們都是Skylake方案的設備。但它們的差異更大，有的是台式機，有的是筆記本，根本無從下手。

@叛逆者提醒我檢查一下離線播放有沒有問題。起初受到國外網友誤導，我一直以為播放本地音樂是沒問題的——直到我親自測試了，才發現不管是離線播放還是在線播放，都會有bug。這樣，就排除掉了網路相關的可能性，只留下了音頻方面的問題。

然而在這個測試過程中，我又有了新的發現：Groove在播放一些音樂時完全沒有降頻；在播放另一些音樂時卻總會降頻——我開始猜測會不會是文件比特率的原因。也許是因為有的文件比特率高，導致系統CPU佔用比較高，或許就不會降頻？——為此我分別查看了會降頻和不會降頻的兩種音樂文件，最後總結出來的根本規律是：Groove在播放flac文件時不會降頻，但在播放MP3時會，而且不管MP3碼率多高多低都是一樣降頻。

一下子豁然開朗！立刻向叛逆者彙報了一下我的新進展，然後再到網易雲音樂去做測試。眾所周知，網易雲音樂UWP是可以播放flac文件的。

可隨即有趣的事情又出現了：網易雲在播放flac文件和mp3文件時，都會出現CPU降頻現象。我和龔大因此猜測網易雲UWP可能是沒有老老實實地解flac，而是採用了什麼投機取巧的辦法。

隨後為了驗證是系統在播放MP3文件時就會固定出現該bug，我又用Edge瀏覽器打開了網易雲音樂的web版。果然不出所料的是，在每首歌的最後十秒，CPU都出現了顯著的降頻現象！

所以一定是系統用來給UWP播放MP3的什麼玩意壞掉了！！！！

而微信UWP呢？在接收消息時，微信UWP有可能會通過API播放MP3格式的消息提示音，很可能就是因為這個導致有時候微信也讓整個系統卡住的。但是為了以防萬一我還是重新安裝了一下微信UWP，然後找到了提示音文件。

欸，怎麼是個wav……

。。。

好吧沒關係，說不定是同一個bug呢！開開心心地把微信的提示音.wav（一千多kbps，一個鈴聲有必要嗎……）放到了groove播放列表裡，開始循環播放——果然不出幾遍，CPU就開始劇烈降頻了……

所以果然是同一個bug啊摔！！！但是為毛Groove放flac就沒bug啊！！！不能理解啊！！！算了我不管了！！！

(╯‵□′)╯︵┻━┻

放好放好……小破出租屋就一張桌子，掀了就從25樓飛下去了可能會出事兒的……這個點富士康員工都開始從我家樓下路過吃完早飯去上班了……

總之在明白這是系統在播放特定類型音樂文件才有的問題時，一切就已經簡單多了。叛逆者說已經可以去找人踹門了（逃。但我還是有些地方沒搞明白：

為什麼有的電腦會出問題，有的電腦就不會呢？都是全新安裝的系統，驅動也是齊備的啊。

這時候我所能收集到的出問題的電腦的硬體信息越來越多了，有一台電腦引起了我的注意：它是唯一一台我收集到的沒用skylake晶元卻也出現了這個毛病的電腦，這裡我要著重感謝@Neon LYC 同學，是他的Acer Aspire E1-472G讓我徹底擺脫了對Skylake的懷疑。

E1-472G是一台採用了三代酷睿的電腦。如果它也出現了這個毛病的話，只能說Skylake應該是無辜的，而是什麼其他的共同點使他們出現了一樣的問題。

我和叛叛開始懷疑起了音效卡驅動。別問我為什麼之前沒懷疑到這裡。因為我覺得任何智商正常的廠商應該不會推出有這種明顯bug的驅動。

然後呢，我開始發現所有出現這個問題的電腦其實只有兩個真正的共同特徵：1. 軟體上跑的是Win10 1607 2. 硬體上音效卡用的是Realtek ALC系列。

不是所有的ALC音效卡都會出問題；但是所有出問題的似乎都是ALC音效卡。這……這不禁讓我浮想聯翩，但是我一想到網友小鍵的悲慘遭遇就不敢多想多說什麼了。

和叛叛又彙報了一下進展，同時他也告訴我他從公司借到的SB跑10586時確實沒有降頻問題；升級到14393以後問題立刻復現了，這下真的可以去踹門了……哈哈哈哈

最後我突然想起來，要驗證到底是不是音效卡驅動的問題，我只要再接一塊音效卡然後用外接的音效卡來輸出看看還降頻與否——不就好了嗎？媽呀我怎麼這麼蠢？居然才想到這個辦法？

然後三下五除二接上我的創新E5，換成E5輸出，然後不管是Groove還是網易雲音樂都正常了。如果它倆正常了的話，Edge和微信應該也不會出問題。Another case solved！

真兇就是你！死螃蟹！！！

別以為我驅動版本老，實際上我在截完這張圖以後又去裝了realtek今年10月出的一款新驅動，結果問題沒有絲毫改善。。。

總之這個故事告訴我們：

1. 排查bug有時候需要的是靈感

2. 排查bug有時候不能太相信經驗

3. 排查bug的時候，不能總覺得大家都是按規矩辦事的

4. 排查bug的時候，要考慮每一個環節可能都會出現傻逼

5. 真相永遠只有一個，可可蘇瑪才是最忠誠的軟狗！Voila！

所以下一步就等著@叛逆者去踹門了, 踹完門後的流程,我估計要不就是微軟脅迫realtek趕緊寫修復驅動,要不就是微軟自己回退一些東西到10586時候的狀態.總之這不再是一個"謎",而是一個我們確切知道由什麼引起的可復現問題了. 作為一個Insider,我感到非常滿意. 因為我這瞎搗鼓一宿,就能改善數百萬人的使用體驗——而且這還只算上了Surface用戶，還有更多的OEM用戶在不知不覺中受影響。

心滿意足！作為軟狗的三件小事以後又豐富了一些，啊哈(??????) ?！

最後配圖：