目錄
1、問題現象
2、使用Process Explorer和System Informer（該工具原先叫Process Hacker）查看占用CPU高的線程
3、使用System Informer工具時發現了一個關鍵細節
4、將Windbg附加到軟件進程上，根據System Informer中顯示的線程id到Windbg中查看更準確的線程函數調用堆棧
5、通過比對，發現是視頻加水印功能導致CPU占用飆升
6、解決辦法
7、最后
C++軟件異常排查從入門到精通系列教程（核心精品專欄，訂閱量已達8000多個，歡迎訂閱，持續更新...）
https://blog.csdn.net/chenlycly/article/details/125529931C/C++實戰專欄（重點專欄，專欄文章已更新500多篇，訂閱量已達6000多個，歡迎訂閱，持續更新中...）https://blog.csdn.net/chenlycly/article/details/140824370C++ 軟件開發從入門到實戰（重點專欄，專欄文章已更新300多篇，歡迎訂閱，持續更新中...）https://blog.csdn.net/chenlycly/category_12695902.htmlVC++常用功能開發匯總（專欄文章列表，歡迎訂閱，持續更新...）https://blog.csdn.net/chenlycly/article/details/124272585C++軟件分析工具從入門到精通案例集錦（專欄文章，持續更新中...）https://blog.csdn.net/chenlycly/article/details/131405795開源組件及數據庫技術（專欄文章，持續更新中...）https://blog.csdn.net/chenlycly/category_12458859.html網絡編程與網絡問題分享（專欄文章，持續更新中...）https://blog.csdn.net/chenlycly/category_2276111.html? ? ? ?在排查C++軟件問題的過程中，可能會使用到一些軟件工具去輔助分析，比如SPY++、PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clumsy、Windbg、IDA Pro等。今天通過一個項目中遇到的問題實例，講解如何使用Process Explorer、System Informer（Process Hacker）和Windbg工具排查軟件高CPU占用問題。
關于如何使用SPY++、PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clumsy、Windbg、IDA Pro等這些常用工具，以及相關實戰分析案例，可以查看我的文章：
【C++軟件實戰問題排查經驗分享系列 ③】 Process Explorer | Process Monitor | API Monitor | Windbg | IDA 等常用工具的使用總結
1、問題現象
? ? ? ?測試人員發現，在SIP協議下加入會議后，會議中開啟水印，將視頻窗口最小化后，整個Windows系統會出現明顯的卡頓。于是打開系統的任務管理器，發現此時系統總的CPU基本達到100%，所以系統出現了明顯的卡頓，已經明顯影響電腦的使用！而我們的軟件進程占用的CPU居然高達60%-70%左右，異常的高！測試人員進一步發現，當將視頻窗口非最小化正常顯示時，軟件的CPU只會占到30%，如果將視頻窗口最小化，則軟件占用的CPU會一下飆升到70%左右，這明顯是不正常的。
2、使用Process Explorer和System Informer（該工具原先叫Process Hacker）查看占用CPU高的線程
? ? ? ?于是使用Process Explorer工具查看軟件進程中到底哪些進程占用的CPU比較高。問題復現后，我們看到多達20多個線程的CPU占用都達到3%或3%以上，這是明顯不正常的。于是想雙擊這些占用CPU高的線程，查看線程的函數調用堆棧，看看線程中都調用了哪些模塊中的哪些函數（主要看占用CPU高的線程是否調用了我們業務模塊的接口以及調用了哪些接口），嘗試去分析占用CPU高的原因。
? ? ? ?打開Process Explorer，在進程列表中找到我們的軟件進程，雙擊之，彈出進程的屬性窗口，在該屬性窗口中點擊Threads標簽頁，即可看到當前進程的所有線程信息。然后在線程列表中找到占用CPU較高的線程，但雙擊這些線程后查看到的函數調用堆棧不準。于是決定換工具，使用Process Hacker工具（該工具現在叫System Informer），這個工具查看線程的函數調用堆棧比較準確，這點比Process Explorer好用。
3、使用System Informer工具時發現了一個關鍵細節
? ? ? ?在使用System Informer過程中，觀察到一個很好用的細節。目前的問題現象是，入會后，不將視頻窗口最小化，即正常顯示，觀察Windows任務管理器，軟件的CPU只占到30%左右，但將視頻窗口最小化后，軟件占用的CPU會飆到70%左右。在任務管理器中可以看到，整個系統中的CPU使用總和到達100%，導致整個Windows系統出現明顯的卡頓。
? ? ? ?在System Informer工具中查看軟件進程中的線程，和使用Process Explorer工具查看方法是一樣的。打開System Informer，在進程列表中找到我們的軟件進程，雙擊之，彈出進程的屬性窗口，在該屬性窗口中點擊Threads標簽頁，即可看到當前進程的所有線程信息。然后在線程列表中找到占用CPU較高的線程：
? ? ? ? 首先要查看占用CPU最高的線程，雙擊之查看該線程的函數調用堆棧，通過堆棧中的函數調用確定當前線程屬于哪個模塊。在本例中，占用CPU最高的線程占用大概10%左右，雙擊之查看該線程中的函數調用堆棧，看到了ksproxy.ax模塊，找到該文件的路徑，查看文件的屬性屬性得知，該文件是金山毒霸殺毒軟件的模塊，在當前機器上安裝了金山毒霸軟件。
有人可能會問，金山毒霸殺毒軟件的ksproxy.ax模塊怎么會加載到我們軟件的進程空間中？這個模塊應該是金山毒霸的注入模塊，注入到我們的軟件進程中的。安全殺毒軟件正是通過遠程注入的方式，實時監控系統中軟件（進程）的行為，以起到實時安全監測的作用。
? ? ? ?在視頻窗口顯示時以及將視頻窗口最小化后，該ksproxy.ax注入模塊的線程都存在，且占用比沒有明顯的變化，所以該線程不是導致將視頻窗口最小化后CPU飆升的原因。當前軟件進程占用CPU高，應該是其他線程導致的。
?? ? ? ?在這里，給大家重點推薦一下我的幾個熱門暢銷專欄，歡迎訂閱：（博客主頁還有其他專欄，可以去查看）
專欄1：（該精品技術專欄的訂閱量已達到10000多個，專欄中包含大量項目實戰分析案例，有很強的實戰參考價值，廣受好評！專欄文章持續更新中，已經更新到200篇以上！歡迎訂閱！）
C++軟件調試與異常排查從入門到精通系列文章匯總https://blog.csdn.net/chenlycly/article/details/125529931
本專欄根據多年C++軟件異常排查的項目實踐，系統地總結了引發C++軟件異常的常見原因以及排查C++軟件異常的常用思路與方法，詳細講述了C++軟件的調試方法與手段，以圖文并茂的方式給出具體的項目問題實戰分析實例（很有實戰參考價值），帶領大家逐步掌握C++軟件調試與異常排查的相關技術，適合基礎進階和想做技術提升的相關C++開發人員！
考察一個開發人員的水平，一是看其編碼及設計能力，二是要看其軟件調試能力！所以軟件調試能力（排查軟件異常的能力）很重要，必須重視起來！能解決一般人解決不了的問題，既能提升個人能力及價值，也能體現對團隊及公司的貢獻！
專欄中的文章都是通過項目實戰總結出來的，包含大量項目問題實戰分析案例，有很強的實戰參考價值！專欄文章還在持續更新中，預計文章篇數能更新到200篇以上！
專欄2：（本專欄涵蓋了C++多方面的內容，是當前重點打造的專欄，訂閱量已達8000多個，專欄文章已經更新到500多篇，持續更新中...）
C/C++實戰進階（專欄文章，持續更新中...）https://blog.csdn.net/chenlycly/category_11931267.html
以多年的開發實戰為基礎，總結并講解一些的C/C++基礎與項目實戰進階內容，以圖文并茂的方式對相關知識點進行詳細地展開與闡述！專欄涉及了C/C++領域多個方面的內容，包括C++基礎及編程要點（模版泛型編程、STL容器及算法函數的使用等）、數據結構與算法、C++11及以上新特性（不僅看開源代碼會用到，日常編碼中也會用到部分新特性，面試時也會涉及到）、常用C++開源庫的介紹與使用、代碼分享（調用系統API、使用開源庫）、常用編程技術（動態庫、多線程、多進程、數據庫及網絡編程等）、軟件UI編程（Win32/duilib/QT/MFC）、C++軟件調試技術（排查軟件異常的手段與方法、分析C++軟件異常的基礎知識、常用軟件分析工具使用、實戰問題分析案例等）、設計模式、網絡基礎知識與網絡問題分析進階內容等。
專欄3：??
C++常用軟件分析工具從入門到精通案例集錦匯總（專欄文章，持續更新中...）https://blog.csdn.net/chenlycly/article/details/131405795
常用的C++軟件輔助分析工具有SPY++、PE工具、Dependency Walker、GDIView、Process Explorer、Process Monitor、API Monitor、Clumsy、Windbg、IDA Pro等，本專欄詳細介紹如何使用這些工具去巧妙地分析和解決日常工作中遇到的問題，很有實戰參考價值！
專欄4：???
VC++常用功能開發匯總（專欄文章，持續更新中...）https://blog.csdn.net/chenlycly/article/details/124272585
將10多年C++開發實踐中常用的功能，以高質量的代碼展現出來。這些常用的高質量規范代碼，可以直接拿到項目中使用，能有效地解決軟件開發過程中遇到的問題。
專欄5：?
C++ 軟件開發從入門到精通（專欄文章，持續更新中...）https://blog.csdn.net/chenlycly/category_12695902.html
根據多年C++軟件開發實踐，詳細地總結了C/C++軟件開發相關技術實現細節，分享了大量的實戰案例，很有實戰參考價值。
? ? ? ?于是用System Informer工具實時觀察視頻窗口從正常顯示（CPU占用正常）到最小化（最小化占用CPU高）這個過程中線程占用CPU比例的變化，發現將視頻窗口最小化后明顯多了幾個CPU占比比較高的線程（不確定這幾個線程在沒最小化視頻窗口時就有，還是最小化視頻窗口后新增的線程，當時沒關注這一點），大概10個左右，每個線程平均占用3%的CPU：
這個細節是個很關鍵的線索！雙擊這幾個線程，發現這幾個線程的函數調用堆棧中的函數都是系統函數，所以可以確實這幾個線程是系統線程。如果占用CPU高線程的函數調用堆棧中有調用業務模塊的接口，我們還可以進行針對性排查，而當前這幾個線程都是系統線程，可能是我們業務模塊調用系統庫的接口后，系統庫中創建的線程，但我們從這些線程的函數調用堆棧中看不出與哪些業務模塊有關，所以排查就陷入了僵局。
? ? ? ?至于為什么會出現系統線程呢？程序運行會依賴很多系統模塊，這些系統模塊中有線程。再就是我們調用到某些API接口或者使用到某些系統相關庫的接口，這些庫內部開啟了線程。
4、將Windbg附加到軟件進程上，根據System Informer中顯示的線程id到Windbg中查看更準確的線程函數調用堆棧
? ? ? ?上面講到System Informer中查看那幾個CPU占用高的線程函數調用堆棧，結果堆棧中調用的都是系統接口，所以線程都是系統創建的線程。是不是System Informer中顯示的線程函數調用堆棧不準確呢？將Windbg附加到軟件進程中去查看線程的調用堆棧肯定是準確的。
? ? ? ?將Windbg附加到進程上，輸入~*kn命令將當前進程的所有線程的函數調用堆棧都打印出來，然后根據System Informer中顯示的線程id，到Windbg中顯示的線程列表中去找對應的線程，就可以查看線程的函數調用堆棧了。System Informer中顯示的線程id是10進制的，要轉成16進制后，到Windbg中顯示的線程列表中查找就可以找到對應的線程了。
5、通過比對，發現是視頻加水印功能導致CPU占用飆升
? ? ? ?最近音視頻編解碼模塊那邊新增了在視頻畫面中添加水印的功能，是不是和這個水印功能有關？于是讓測試人員，對比一下關閉水印時最小化視頻窗口后的CPU占用比例。通過對比測試發現，關閉水印后最小化視頻窗口，軟件的CPU會達到40%左右；打開水印后，最小化視頻窗口，軟件的CPU占用會達到70%。CPU占用差額正好是30%左右，這和System Informer工具中顯示的增加的幾個高CPU占用線程的CPU占用總和是一致的。所以，基本可以確定是視頻中加水印功能導致的。
我讓測試人員看一下上一個沒加水印的老版本，入會后將視頻窗口最小化，沒有出現CPU飆升的問題，所以進一步確認CPU占用飆升與水印功能有關。
6、解決辦法
? ? ? ?音視頻編解碼模塊的開發同事，懷疑是當前sip協議下同時使用D3D9和D3D11庫導致的。sip協議入會和rtc協議入會，用的音視頻編解碼庫是不同的。SIP協議下用的是xxxxxsdk.dll庫，rtc協議下用的是xxxxxplayer.dll庫。當前出問題的場景就是sip協議入會的場景，用的就是xxxxxsdk.dll庫，在該庫中使用了D3D的兩個版本，繪制視頻畫面使用的是D3D9（當時為了兼容XP系統，使用了D3D9），繪制水印使用的是D3D11，可能是兩個版本同時使用導致的，后面需要將視頻畫面繪制與水印繪制都統一使用同一個版本的D3D。
7、最后
? ? ? ?有些問題很難找到排查的線索或入口，但通過觀察一些細節以及版本的對比，可能會從中發現一些端倪，從而找到一些線索。
?
)
