記一次 .NET 某工控視覺系統 卡死分析

来源:https://www.cnblogs.com/huangxincheng/archive/2023/07/04/17525483.html
-Advertisement-
Play Games

## 一：背景 ### 1. 講故事 前段時間有位朋友找到我，說他們的工業視覺軟體僵死了，讓我幫忙看下到底是什麼情況，哈哈，其實卡死的問題相對好定位，無非就是看主線程棧嘛，然後就是具體問題具體分析，當然難度大小就看運氣了。 前幾天看一篇文章說現在的 .NET程式員 不需要學習**WinDbg** ， ...


一：背景

1. 講故事

前段時間有位朋友找到我，說他們的工業視覺軟體僵死了，讓我幫忙看下到底是什麼情況，哈哈，其實卡死的問題相對好定位，無非就是看主線程棧嘛，然後就是具體問題具體分析，當然難度大小就看運氣了。

前幾天看一篇文章說現在的 .NET程式員 不需要學習WinDbg ，理由就是有很多好的分析工具諸如 VS，DnSpy，PerfView 可以替代，我也只能笑笑，在他們的認知中可能 .NET程式 是不需要和其他語言交互而獨成一體的。

話不多說，回到主題，上 WinDbg 說話。

二：為什麼會卡死

1. 主線程在做什麼

剛纔也說到了，卡死是比較好定位的，切到主線程看線程棧即可,簡化輸出如下：


0:000> ~0s;k
ntdll!NtDelayExecution+0x14:
00007ffc`7d45fcf4 c3              ret
 # Child-SP          RetAddr               Call Site
00 00000000`007fd628 00007ffc`79a15631     ntdll!NtDelayExecution+0x14
01 00000000`007fd630 00007ffc`40b7b116     KERNELBASE!SleepEx+0xa1
02 00000000`007fd6d0 00007ffc`40b7372e     cogxstd+0x13b116
03 00000000`007fd700 00007ffc`40b73ece     cogxstd+0x13372e
...
09 00000000`007fd9b0 00007ffc`7d1c77e3     CogDisplay!DllUnregisterServer+0x1833f
0a 00000000`007fdab0 00007ffc`7d16436c     rpcrt4!Invoke+0x73
0b 00000000`007fdb00 00007ffc`7cdbc473     rpcrt4!NdrStubCall2+0x42c
0c 00000000`007fe130 00007ffc`7c451bf0     combase!CStdStubBuffer_Invoke+0x73 [onecore\com\combase\ndr\ndrole\stub.cxx @ 1446] 
...
11 00000000`007fe230 00007ffc`7cdc2df6     combase!DefaultStubInvoke+0x1c4 [onecore\com\combase\dcomrem\channelb.cxx @ 1769] 
12 (Inline Function) --------`--------     combase!SyncStubCall::Invoke+0x22 [onecore\com\combase\dcomrem\channelb.cxx @ 1826] 
13 00000000`007fe380 00007ffc`7cd62e55     combase!SyncServerCall::StubInvoke+0x26 [onecore\com\combase\dcomrem\servercall.hpp @ 825] 
14 (Inline Function) --------`--------     combase!StubInvoke+0x265 [onecore\com\combase\dcomrem\channelb.cxx @ 2052] 
15 00000000`007fe3c0 00007ffc`7cd8ded2     combase!ServerCall::ContextInvoke+0x435 [onecore\com\combase\dcomrem\ctxchnl.cxx @ 1532] 
...
31 00000000`007fff60 00000000`00000000     ntdll!RtlUserThreadStart+0x21

從卦中看當前主線程正在 Sleep，這就很奇葩了，並且還是康耐視的 cogxstd 動態鏈接庫的邏輯，這裡我敢相信它不會有這麼低級的錯誤，接下來我們洞察下到底 Sleep 了多久，仔細觀察彙編代碼，精簡後如下：


    ntdll!NtDelayExecution:
00007ffc`7d45fce0 4c8bd1           mov     r10, rcx
00007ffc`7d45fce3 b834000000       mov     eax, 34h
00007ffc`7d45fce8 f604250803fe7f01 test    byte ptr [7FFE0308h], 1
00007ffc`7d45fcf0 7503             jne     ntdll!NtDelayExecution+0x15 (7ffc7d45fcf5)
00007ffc`7d45fcf2 0f05             syscall 
00007ffc`7d45fcf4 c3               ret     
00007ffc`7d45fcf5 cd2e             int     2Eh
00007ffc`7d45fcf7 c3               ret     
00007ffc`7d45fcf8 0f1f840000000000 nop     dword ptr [rax+rax]

    KERNELBASE!SleepEx:
00007ffc`79a15590 89542410         mov     dword ptr [rsp+10h], edx
00007ffc`79a15594 4c8bdc           mov     r11, rsp
00007ffc`79a15597 53               push    rbx
00007ffc`79a15598 56               push    rsi
00007ffc`79a15599 57               push    rdi
00007ffc`79a1559a 4881ec80000000   sub     rsp, 80h
00007ffc`79a155a1 8bda             mov     ebx, edx
00007ffc`79a155a3 8bf9             mov     edi, ecx
...
00007ffc`79a155f4 488b9424b8000000 mov     rdx, qword ptr [rsp+0B8h]
00007ffc`79a155fc 85db             test    ebx, ebx
00007ffc`79a155fe 0f8592000000     jne     KERNELBASE!SleepEx+0x106 (7ffc79a15696)
00007ffc`79a15604 83ffff           cmp     edi, 0FFFFFFFFh
00007ffc`79a15607 7443             je      KERNELBASE!SleepEx+0xbc (7ffc79a1564c)
00007ffc`79a15609 4869cf10270000   imul    rcx, rdi, 2710h
00007ffc`79a15610 48894c2420       mov     qword ptr [rsp+20h], rcx
00007ffc`79a15615 48f7d9           neg     rcx
...
00007ffc`79a15622 488d542420       lea     rdx, [rsp+20h]
00007ffc`79a15627 0fb6cb           movzx   ecx, bl
00007ffc`79a1562a 48ff15ef641400   call    qword ptr [KERNELBASE!__imp_NtDelayExecution (7ffc79b5bb20)]

再上一段 reactos 的 C++ 方法簽名。


DWORD
WINAPI
SleepEx(IN DWORD dwMilliseconds,
        IN BOOL bAlertable)
{}

NTSTATUS
NTAPI
NtDelayExecution(IN BOOLEAN Alertable,
                 IN PLARGE_INTEGER DelayInterval)
{}

我們要重點觀察 NtDelayExecution 方法中 rdx 參數是怎麼計算的，重點就是下麵的兩句彙編。


imul    rcx, rdi, 2710h
neg     rcx

這兩句彙編是什麼意思呢？ 轉成 C++ 代碼就是


interval = - (milliseconds * 0x2710);

在彙編中我們是知道 interval 的，它相當於是 milliseconds 計算後的補碼，即下麵的 Binary: 列。


0:000> r
rax=0000000000000034 rbx=0000000000000000 rcx=0000000000000000
rdx=00000000007fd650 rsi=0000000000000000 rdi=0000000000000001
rip=00007ffc7d45fcf4 rsp=00000000007fd628 rbp=00000000bf1efcf8
 r8=00000000007fd628  r9=00000000bf1efcf8 r10=0000000000000000
r11=0000000000000246 r12=0000000000000000 r13=0000000000000798
r14=000000003bd064b0 r15=00000000bf1efce0

0:000> dp 00000000007fd650 L1
00000000`007fd650  ffffffff`ffffd8f0

0:000> .formats ffffffff`ffffd8f0
Evaluate expression:
  Hex:     ffffffff`ffffd8f0
  Binary:  11111111 11111111 11111111 11111111 11111111 11111111 11011000 11110000
  ...

那怎麼求 milliseconds 呢？ 其實 補碼的補碼 就是原碼，然後再除以 0x2710 就可以獲取到 milliseconds 了哈。

  • 補碼：11111111 11111111 11111111 11111111 11111111 11111111 11011000 11110000
  • 反碼：00000000 00000000 00000000 00000000 00000000 00000000 00100111 00001111
  • 補補：00000000 00000000 00000000 00000000 00000000 00000000 00100111 00010000

0:000> .formats 0y0000000000000000000000000000000000000000000000000010011100010000
Evaluate expression:
  Hex:     00000000`00002710
  Decimal: 10000
  Decimal (unsigned) : 10000
  Octal:   0000000000000000023420
  Binary:  00000000 00000000 00000000 00000000 00000000 00000000 00100111 00010000

0:000> ? 00002710/ 2710
Evaluate expression: 1 = 00000000`00000001

從卦中看當前也就暫停了 1ms，如果想驗證對不對的話，仔細看mov edi, ecx 會發現做了一次備份，但不管怎麼說 Thread.Sleep(1) 應該問題不大，那問題在哪裡呢？

2. 問題到底在哪裡

既然問題不在 Sleep(1) 上那到底在哪裡呢？仔細觀察線程棧會發現底層做了一個 RPC 通訊，從 combase!SyncServerCall::StubInvoke 和 rpcrt4!NdrStubCall2 方法來看，它是 RPC 的 Server 端，既然是 Server 端就必然有 Client 端，根據經驗這個 RPC 應該是 命令管道 的方式，沒開 Windows 的RPC診斷所以不能100%確認。

接下來看下其他線程有沒有 RPC 的 rpcrt4!NdrpClientCall 請求，抱著試試看的態度搜一搜，我去，還真有10幾個，截圖如下：

仔細分析這 12 個 Reqeust，發現其中的 Cognex.VisionPro.Display.CogDisplay.set_Image 比較可疑，畢竟 Image 運作起來肯定是費時費力的。


0:543> k
 # Child-SP          RetAddr               Call Site
00 00000000`fc65def8 00007ffc`79a1c2ce     ntdll!NtWaitForMultipleObjects+0x14
...
04 (Inline Function) --------`--------     combase!CSyncClientCall::SwitchAptAndDispatchCall+0x34a
05 00000000`fc65e290 00007ffc`7cd9b015     combase!CSyncClientCall::SendReceive2+0x42c
06 (Inline Function) --------`--------     combase!SyncClientCallRetryContext::SendReceiveWithRetry+0x25 
07 (Inline Function) --------`--------     combase!CSyncClientCall::SendReceiveInRetryContext+0x25 
08 00000000`fc65e480 00007ffc`7cd8c55d     combase!DefaultSendReceive+0x65
09 00000000`fc65e4e0 00007ffc`7cd60a54     combase!CSyncClientCall::SendReceive+0x12d 
0a 00000000`fc65e710 00007ffc`7cdbc54e     combase!CClientChannel::SendReceive+0x84 
0b 00000000`fc65e780 00007ffc`7d151e93     combase!NdrExtpProxySendReceive+0x4e 
0c 00000000`fc65e7b0 00007ffc`7cdbae17     rpcrt4!NdrpClientCall2+0x463
0d 00000000`fc65edf0 00007ffc`7ce2ce92     combase!ObjectStublessClient+0x1d7 
0e 00000000`fc65f180 00007ffb`f1321db8     combase!ObjectStubless+0x42
0f 00000000`fc65f1d0 00007ffc`4002c906     0x00007ffb`f1321db8
10 00000000`fc65f2c0 00007ffb`f131d541     Cognex_VisionPro_Display_Controls_ni!Cognex.VisionPro.Display.CogDisplay.set_Image+0xb6

0:543> !clrstack
OS Thread Id: 0x2bbc (543)
        Child SP               IP Call Site
...
00000000fc65f208 00007ffbf1321db8 [InlinedCallFrame: 00000000fc65f208] Cognex.VisionPro.Interop.CogDisplayClass.set_Image(Cognex.VisionPro.Interop.ICogImage)
00000000fc65f1d0 00007ffbf1321db8 DomainBoundILStubClass.IL_STUB_CLRtoCOM(Cognex.VisionPro.Interop.ICogImage)
00000000fc65f2c0 00007ffc4002c906 Cognex.VisionPro.Display.CogDisplay.set_Image(Cognex.VisionPro.ICogImage)
00000000fc65f310 00007ffbf131d541 xxxx.SetDefaultRecord()
...
00000000fc65f680 00007ffc4bc17e46 System.Threading.ThreadPoolWorkQueue.Dispatch()
00000000fc65fb20 00007ffc4d706c93 [DebuggerU2MCatchHandlerFrame: 00000000fc65fb20]

根據卦中的托管方法 xxxx.SetDefaultRecord() ，讓朋友不要做 Image 賦值觀察下效果，朋友反饋說，這個 Image 不賦值問題就沒有了。

既然去掉就好了，到這裡只能推測當前主線程不是卡死，而是 RPC 請求過多Size過大，導致主線程一直忙碌中，具體為什麼會忙碌，這就需要逆向 cogxstd 來濾清業務邏輯了，這個就太費時費力了，還是先繞過去為好。

三：總結

還是回到文章開頭的那句話，這種 dump 問題，你能用 DnSpy，VS 調試出來嗎？說實話很難，雖然以 .NET 程式為出口，但考察了你很多基礎知識，諸如 RPC，COM，彙編，沒有這些基礎沉澱，這類dump很難摸清來龍去脈。

圖片名稱
您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • CakePHP教程_編程入門自學教程_菜鳥教程-免費教程分享
    ## 教程簡介 CakePHP是一個運用了諸如ActiveRecord、Association Data Mapping、Front Controller和MVC等著名設計模式的快速開發框架。該項目主要目標是提供一個可以讓各種層次的PHP開發人員快速地開發出健壯的Web應用，而 又不失靈活性。 Ca ...
  • Spring容器獲取Bean的9種方式
    本文為大家整理彙總了常見的獲取Bean的方式，並提供一些優劣分析，方便大家在使用到時有更好的選擇。同時，也會為大家適當的普及和拓展一些相關知識。 ...
  • Excel Dax教程_編程入門自學教程_菜鳥教程-免費教程分享
    ## 教程簡介 DAX代表 Data Analysis Expressions. DAX是一種公式語言，是函數，運算符和常量的集合，可以在公式或表達式中用於計算和返回一個或多個值. DAX是與Excel Power Pivot的數據模型相關聯的公式語言. 它不是一種編程語言，而是一種允許用戶在計算列 ...
  • Java 中使用 OkHttpClent 請求介面 get方式 post方式
    學習記錄，不喜勿噴 什麼是OkHttp 一般在Java平臺上，我們會使用Apache HttpClient作為Http客戶端，用於發送 HTTP 請求，並對響應進行處理。比如可以使用http客戶端與第三方服務(如SSO服務)進行集成，當然還可以爬取網上的數據等。OKHttp與HttpClient類似 ...
  • 聊聊JVM虛方法表和方法調用
    > 作者：小牛呼嚕嚕 | [https://xiaoniuhululu.com](https://xiaoniuhululu.com/) > 電腦內功、源碼解析、科技故事、項目實戰、面試八股等更多硬核文章，首發於公眾號「[小牛呼嚕嚕](https://www.xiaoniuhululu.com/i ...
  • spring啟動流程 (3) BeanDefinition詳解
    BeanDefinition在Spring初始化階段保存Bean的元數據信息，包括Class名稱、Scope、構造方法參數、屬性值等信息，本文將介紹一下BeanDefinition介面、重要的實現類，以及在Spring中的使用示例。 # BeanDefinition介面 用於描述了一個Bean實例， ...
  • 最簡單的人臉檢測（免費調用百度AI開放平臺介面）
    遠程調用百度AI開放平臺的web服務，快速完成人臉識別 ### 歡迎訪問我的GitHub > 這裡分類和彙總了欣宸的全部原創(含配套源碼)：[https://github.com/zq2599/blog_demos](https://github.com/zq2599/blog_demos) ### ...
  • C#百度地圖開放平臺211sn校驗失敗解決方法
    個人認為百度地圖開放平臺確實很好用但就是C#的SN校驗會出現以下幾個問題 一、官方的示例代碼說的不清不楚 獲取SN函數的Uri應該使用不帶功能變數名稱的Uri 比如：最終請求地址為https://api.map.baidu.com/location/ip?ip=119.126.10.15&coor=gcj0 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類