If no high entropy ASLR applied at execution, as the current officially used linker mandates, then the virtual address space allocated for the binary remains under 4GiB hence the pointer truncation has no effect and no crashes happen. But with various linking configurations, operating systems, memory size, etc... this can change at anytime.
The crash happens with x64 builds only and it needs the executable linked with high entropy ASLR <https:/ /learn. microsoft. com/en- us/cpp/ build/reference /highentropyva- support- 64-bit- aslr?view= msvc-170> enabled. Also it currently crashes only under an operating system that supports this feature such as Win8+.
The cause is that 8 byte-long x64 TabInfo pointers sent through using a <https:/ /learn. microsoft. com/en- us/windows/ win32/api/ commctrl/ ns-commctrl- tcitema> strucure as an item data parameter are getting truncated to 4 bytes when they come out as <https:/ /learn. microsoft. com/en- us/windows/ win32/api/ winuser/ ns-winuser- drawitemstruct>.itemData or when accessed by TabCtrl_GetItem.
Both TCITEM's and the tab controls's documentation <https:/ /learn. microsoft. com/en- us/windows/ win32/controls/ tab-controls? redirectedfrom= MSDN#owner- drawn-tabs> mention this. You cannot pass through data with size other than 4 using this method, even though the size of the containter for this data (TCITEM.lParam) is 8 bytes long in x64.
If no high entropy ASLR applied at execution, as the current officially used linker mandates, then the virtual address space allocated for the binary remains under 4GiB hence the pointer truncation has no effect and no crashes happen. But with various linking configurations, operating systems, memory size, etc... this can change at anytime.
A <https:/ /learn. microsoft. com/en- us/windows/ win32/api/ commctrl/ ns-commctrl- tcitemheadera> must be used instead with quirks to work around some undocumented behavior.
A fix, that is under testing right now, will be committed soon.