What is _invoke_watson in WinDbg?

Question

I found the trace "AKC!_invoke_watson" when I used WinDbg to analysis our issue. Could you please help me to explain what is the "_invoke_watson"? And how to know what is the root cause of the AKC app 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

Akanke

FFWD to 2020. There is a bit more to Hans answer. I assume you found out during last 5 years you can open the dmp file from Visual Studio 2019? And you know from there you can dive into "Native Debugging ..."? That should give you a much better idea of what went wrong v.s. poking around a dmp file. Core advice is: that is very likely an SEH being thrown. – Orient

Answer 1

_invoke_watson() is an internal Microsoft C runtime function that crashed your program. It is what made you look at this minidump. Does not tell you anything interesting, you have to look at the stack trace to see how it got there. The trouble started at:

   AKC!swprintf_s<260>+0x25 

Note the _s postfix of the function name, it is the secure version of swprintf(). It ensures that sprintf() cannot write past the end of the buffer. It did write past the end of the buffer, that's what triggered the crash. You can also see the buffer size from the template name, 260 characters.

That's a magic number in Windows, it is the value of MAX_PATH. Provides you with a pretty good theory why the program crashed, it was probably asked to deal with a filename that contains more than 259 chars. Not uncommon, C and C++ programs in general have a very hard time dealing with file systems on Windows being able to create paths with up to 32,767 characters. Backgrounder is here.

Beyond adding checks in your program to ensure this limit is not exceeded so you give a better diagnostic, telling the client to re-organize his data and avoid storing files in deeply nested directories is the simplest workaround.

Vasquez

Thanks for your answer. I would love to say thank you very much again. – Akanke