What is _invoke_watson in WinDbg?

Question

I found the trace "AKC! _Invoke_watson" when I used WinDbg to analyze our problem. Could you help me explain what "_invoke_watson" is? And how do you know what is the root cause of an AKC application based on this trace?

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() is the internal Microsoft C runtime function that crashed your program. This is what made you take a look at this mini pump. Doesn’t tell you anything interesting, you need to look at the stack to see how it got there. The problem started with:

  AKC!swprintf_s<260>+0x25 

Note the posttext _s the function name, this is a protected version for swprintf (). This ensures that sprintf () cannot write beyond the end of the buffer. He wrote down the end of the buffer, which caused a crash. You can also see the buffer size on behalf of the template, 260 characters.

This is a magic number on Windows, this is the value of MAX_PATH. It provides you with a pretty good theory of why the program crashed, it was probably suggested that you deal with a file name containing more than 259 characters. Not infrequently, C and C ++ programs in general are very difficult to work with file systems in Windows, capable of creating paths up to 32,767 characters in length. The backgrounder is here .

In addition to adding checks to your program, to ensure that this limit is not exceeded, you will give better diagnostics by telling the client about the re-organization of your data and avoiding storing files in deeply nested directories, this is the easiest workaround.