什麼是WinDbg中的_invoke_watson？

Question

當我使用WinDbg分析我們的問題時，我找到了跟蹤「AKC！_invoke_watson」。 你能幫我解釋什麼是「_invoke_watson」？ 以及如何根據此跟蹤瞭解AKC應用程序的根本原因是什麼？

DEFAULT_BUCKET_ID: NULL_POINTER_READ_IN_CALL 

LAST_CONTROL_TRANSFER: from 00007ff713fe047e to 00007ff713fe03f4 

STACK_TEXT: 
00000000`0274efe0 00007ff7`13fe047e : 00000000`024a36d8 00000000`ce9f27b4 00000000`024a1ac0 00007ff7`13fe3162 : AKC!_invoke_watson+0x18 
00000000`0274f010 00007ff7`13fe0499 : 00000000`00000130 00000000`0274f190 00000000`ffffffff 00000000`0274f120 : AKC!_invalid_parameter+0x6e 
00000000`0274f050 00007ff7`13fe28a6 : 00000000`00000068 00000000`00000000 00000000`00000225 00000000`0000002a : AKC!_invalid_parameter_noinfo+0x19 
00000000`0274f090 00007ff7`13fdab91 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : AKC!_woutput_s_l+0xb42 
00000000`0274f5b0 00007ff7`13fdac52 : 00000000`024a36d8 00000000`00000409 00000000`00000000 00000000`00000000 : AKC!_vswprintf_helper+0x9d 
00000000`0274f620 00007ff7`13fdac9d : 00000000`024a34b0 00000000`00000000 00000000`00000000 00000000`00000000 : AKC!_vswprintf_s_l+0x42 
00000000`0274f660 00007ff7`13fd7885 : 00000000`0000003e 00000000`024a34b0 00000000`00000000 00000000`00000409 : AKC!vswprintf_s+0x11 
00000000`0274f6a0 00007ff7`13fd40a1 : 00000000`024a34b0 00000000`0274f730 00000000`024a3f90 00000000`024a1a70 : AKC!swprintf_s<260>+0x25 
00000000`0274f6d0 00007ff7`13fd48b6 : 00000000`00000026 00000000`024a34b0 00000000`024a34b0 00007ff7`13ff0550 : AKC!Capture::initTag+0xf1 
00000000`0274f980 00007ff7`13fd345e : 00000000`00000000 00000000`024a34b0 00000000`00000026 00000000`000000c8 : AKC!Capture::funcShow+0x56 
00000000`0274f9b0 00007ffc`21e815dd : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : AKC!Capture::Loop+0x50e 
00000000`0274fa50 00007ffc`229d43d1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd 
00000000`0274fa80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d 


FOLLOWUP_IP: 
AKC!_invoke_watson+18 [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\invarg.c @ 156] 
00007ff7`13fe03f4 ff159ebe0000 call qword ptr [AKC!_imp_GetCurrentProcess (00007ff7`13fec298)] 

FAULTING_SOURCE_LINE: f:\dd\vctools\crt_bld\self_64_amd64\crt\src\invarg.c 

FAULTING_SOURCE_FILE: f:\dd\vctools\crt_bld\self_64_amd64\crt\src\invarg.c 

FAULTING_SOURCE_LINE_NUMBER: 156 

FAULTING_SOURCE_CODE: 
No source found for 'f:\dd\vctools\crt_bld\self_64_amd64\crt\src\invarg.c' 


SYMBOL_STACK_INDEX: 0 

SYMBOL_NAME: akc!_invoke_watson+18 

Answer 1

_invoke_watson()是一個內部的Microsoft C運行時功能，它會導致程序崩潰。這是什麼讓你看看這個小轉儲。沒有告訴你任何有趣的事情，你必須看看堆棧跟蹤，看看它是如何到達那裏。麻煩始於：

AKC!swprintf_s<260>+0x25 

注意_s後綴的函數名，它是標準的swprintf的secure version（）。它確保sprintf（）不能寫入超過緩衝區的末尾。它確實寫過緩衝區的末尾，這就是觸發崩潰的原因。您還可以從模板名稱中看到緩衝區大小，260個字符。

這是Windows中的幻數，它是MAX_PATH的值。爲您提供一個非常好的理論，說明程序崩潰的原因，可能會要求您處理包含超過259個字符的文件名。並不少見，C和C++程序通常很難處理Windows上的文件系統，能夠創建多達32,767個字符的路徑。 Backgrounder is here。

除了在程序中添加檢查以確保不會超出此限制以便您提供更好的診斷，告訴客戶重新組織他的數據並避免將文件存儲在深層嵌套目錄中是最簡單的解決方法。