drrun fails on windows without YMM support

[bugger15]

Describe the bug

Originally, I was trying to get WinAFL working on windows 10. Down the rabbit hole I ended up here, as a dry run without any client cannot be competed without an error.

I tried the the latest version, stable version and previous stable version with no luck.
I compiled a debug build from source, with the same results.

This is the command I ran:, but every single program i run ends the same:

drrun.exe -debug -- ipconfig

And this is the output

<Starting application C:\Windows\system32\ipconfig.exe (5160)>
<Running on newer-than-this-build "Microsoft Windows 10-2009 x64">
<Early threads found>
<Initial options = -no_dynamic_options -code_api -probe_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct >
<CURIOSITY : instr_get_opcode(instr_new) != instr_get_opcode(instr_old) in file C:\tools\src\dynamorio\core\win32\callback.c line 2082
version 10.0.19818, custom build
-no_dynamic_options -code_api -probe_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct
C:\tools\src\dynamorio\build/lib64\debug\dynamorio.dll=0x0000000015000000>
<CURIOSITY : instr_new == instrlist_first(ilist) || instr_new == instr_get_next(instrlist_first(ilist)) in file C:\tools\src\dynamorio\core\win32\callback.c line 2085
version 10.0.19818, custom build
-no_dynamic_options -code_api -probe_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct
C:\tools\src\dynamorio\build/lib64\debug\dynamorio.dll=0x0000000015000000>
<Cleaning hooked Nt wrapper @0x00007ffc465b0800 sysnum=0x1c2>
<Application C:\Windows\system32\ipconfig.exe (5160).  Internal Error: DynamoRIO debug check failure: C:\tools\src\dynamorio\core\dispatch.c:793 dc == NULL || OWN_NO_LOCKS(dc)
(Error occurred @0 frags in tid 4972)
version 10.0.19818, custom build
-no_dynamic_options -code_api -probe_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct
C:\tools\src\dynamorio\build/lib64\debug\dynamorio.dll=0x0000000015000000>

Versions

• What version of DynamoRIO are you using?
  commit 525020b

• Does the latest build from https://github.com/DynamoRIO/dynamorio/releases solve the problem?
  No

• What operating system version are you running on? ("Windows 10" is not sufficient: give the release number.)
  Windows 10.0.19045 Build 19045

• Is your application 32-bit or 64-bit?
  64-bit

Additional context

The windows is actually running in a fully-accelerated VM. The host os is mac os sonoma 14.4.1 and the hypervisor is Qemu 8.2.1. Nevertheless, please do not let the fact that the environment is virtualized discourage you.

Now, I am aware this may be not easily reproducible, still I would love to get to the bottom of this. Therefore, I will you provide you with any more information you will need, we can even schedule an online debugging session.

[edeiana]

Hi!

This problem seems more related to your specific configuration and setup rather than DynamoRIO itself.
I'd suggest you post this issue on: https://groups.google.com/g/DynamoRIO-Users to reach a wider audience, so we can work it out, and if this is an actual bug in DynamoRIO we can post a more precise (and actionable) issue here on Github.
In the meantime, I'd suggest you add -loglevel 4 to drrun.exe and check the log (and add it to your "DynamoRIO-Users group" post) to see if there is any useful information there.

[derekbruening]

Looks like this is being discussed here: https://groups.google.com/g/dynamorio-users/c/W97-BSreDy8

[bugger15]

It seems like the issue is triggered by an OS without support of YMM. The problem went away when cpu supported the feature.

Culprit stacktrace:

 # Child-SP          RetAddr               Call Site
00 0000006a`57f0f718 00000000`153d2897     0x0
01 0000006a`57f0f720 00000000`15384b62     dynamorio!nt_get_context_size(unsigned long flags = 0x10000b)+0x17 [C:\tools\src\dynamorio\core\win32\ntdll.c @ 5405] 
02 0000006a`57f0f760 00000000`15375b8b     dynamorio!os_take_over_thread(struct _dcontext_t * dcontext = 0x0000022f`15b95200, void * hthread = 0x00000000`00000100, unsigned int64 tid = 0x1ab0, char suspended = 0n0 '')+0x72 [C:\tools\src\dynamorio\core\win32\os.c @ 2512] 
03 0000006a`57f0f7e0 00000000`15015980     dynamorio!os_take_over_all_unknown_threads(struct _dcontext_t * dcontext = 0x0000022f`15b95200)+0x26b [C:\tools\src\dynamorio\core\win32\os.c @ 2728] 
04 0000006a`57f0f880 00000000`1534e7a0     dynamorio!dynamorio_take_over_threads(struct _dcontext_t * dcontext = 0x0000022f`15b95200)+0x170 [C:\tools\src\dynamorio\core\dynamo.c @ 2925] 
05 0000006a`57f0f930 00000000`15026d10     dynamorio!dynamo_start(struct _priv_mcontext_t * mc = 0x0000006a`57f0faa0)+0xd0 [C:\tools\src\dynamorio\core\arch\x86_code.c @ 112] 
06 0000006a`57f0f9d0 00000000`15027115     dynamorio!dynamorio_app_take_over_helper(struct _priv_mcontext_t * mc = 0x0000006a`57f0faa0)+0x300 [C:\tools\src\dynamorio\core\dynamo.c @ 2999] 
07 0000006a`57f0fa30 00000000`15426e49     dynamorio!dynamorio_earliest_init_takeover_C(unsigned char * arg_ptr = 0x0000022f`15811000 "", struct _priv_mcontext_t * mc = 0x0000006a`57f0faa0)+0x135 [C:\tools\src\dynamorio\core\dynamo.c @ 3068] 
08 0000006a`57f0fa80 0000022f`15811000     dynamorio!dynamorio_earliest_init_takeover(void)+0x83 [C:\tools\src\dynamorio\build\core\x86.asm_core.s @ 4877] 
09 0000006a`57f0fa88 0000006a`57f0faa0     0x0000022f`15811000
0a 0000006a`57f0fa90 00000000`00000000     0x0000006a`57f0faa0

[derekbruening]

Pasting from https://groups.google.com/g/dynamorio-users/c/W97-BSreDy8/m/lmTDvp02AQAJ

ntdll_RtlGetExtendedContextLength does look like a problem, initialized under YMM_ENABLED but used outside. Probably your VM does not have it enabled. Looks like a real bug. Presumably those Rtl routines are still there and still work: is that YMM_ENABLED conditional needed?