Unhandled Exception during Compile/Test under VS2019 / Win10

[sz10101]

I'm trying to generate/use the Subclassing thunk and although I have been able to compile each of them using VS2019 / x86 - I'm running into a problem during the Test step of main().

If I step through the code, everything appears to function correctly UP TO the CallWindowProc test which throws the following "Unhandled exception"

Exception thrown at 0x00CA0944 in thunks.exe: 0xC0000005: Access violation writing location 0x00000000.

The output window shows:

hWnd=00A256CC
hThunk=00CA0000
THUNK_SIZE=250

The only change I could find that seemed most appropriate was to include MEM_COMMIT on the VirtualAlloc function:

void *hThunk = VirtualAlloc(0, 0x10000, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);

I've stared at it for hours trying to follow the logic (including the assembly of SubclassingFunc). Since the faulting address appears to be inside of the SubclassingThunk Code which has been copied to the dynamically-allocated page, Moreover, the fault appears to be outside of the range of the THUNK_SIZE that's been copied into that allocated space. So that seems odd to me and having walked through the listing, nothing is jumping out at me. Because I'm unclear about the best means of debugging this any further, I thought I'd ask here. Any guidance would be welcome.

Attached is the compiler listing for the file including assembler output. If I can provide or try anything else, I'll be happy to provide.

thunks.zip

Thanks!

[wqweto]

When the hThunk address is dumped you can open Assembly window, navigate to this hex address and put a breakpoint with F9 so that you can trace the later DWORD dwSize = CallWindowProc((WNDPROC)hThunk, hWnd, (UINT) 0, (WPARAM)&p, (LPARAM)&pUnk) call for problems inside the thunk initialization.

You'll need a separate breakpoint at the __SubclassProc label inside the thunk to trace the SendMessage(hWnd, WM_USER, 0, 0) call for problems.

[sz10101]

Got it - thanks - Here's what I've found (so far):

Following your recommendation (thanks for the hint - I should have taken a break to get a fresh perspective).
stepping this code - something appears to be incorrect in the memcpy:

    printf("hWnd=%p\n", hWnd);
    void *hThunk = VirtualAlloc(0, 0x10000, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
    printf("hThunk=%p\nTHUNK_SIZE=%d\n", hThunk, THUNK_SIZE);
    memcpy(hThunk, SubclassingThunk, THUNK_SIZE);

Console displays:

hWnd=002A24F4
hThunk=014B0000
THUNK_SIZE=250

When I disassemble the allocated page at hThunk - I get the following:

.
.
.014AFFFD ??                   ?? ?????? 
014AFFFE ??                   ?? ?????? 
014AFFFF ??                   ?? ?????? 
014B0000 E9 3F 09 00 00       jmp         014B0944  
014B0005 E9 75 49 00 00       jmp         014B497F  
014B000A E9 35 4B 00 00       jmp         014B4B44  
014B000F E9 30 30 00 00       jmp         014B3044  
.
.
.
014B0942 00 00                add         byte ptr [eax],al  
014B0944 00 00                add         byte ptr [eax],al  
014B0946 00 00                add         byte ptr [eax],al  

Which explains the faulting address location in the above (Access Violation).
When I look at the assembly listing for the memcpy code -

00B12110 B8 16 13 B1 00       mov         eax,offset _main (0B11316h)  
00B12115 2D 1C 12 B1 00       sub         eax,offset SubclassingThunk (0B1121Ch)  
00B1211A 50                   push        eax  
00B1211B 68 1C 12 B1 00       push        offset SubclassingThunk (0B1121Ch)  
00B12120 8B 8D 78 FF FF FF    mov         ecx,dword ptr [hThunk]  
00B12126 51                   push        ecx  
00B12127 E8 03 F2 FF FF       call        _memcpy (0B1132Fh)  
00B1212C 83 C4 0C             add         esp,0Ch 

I see something odd - The source address of SubclassingThunk is wrong. It points into the debug jump tables (thus explaining the wrong copy), NOT at the address of SubclassingThunk.

I noticed that I have the build mode in "Debug" - and changed it to "Release".
After rebuilding - (as if by magic) ... It now works properly.

Resolution: Build/run in x86/RELEASE mode only.

Thanks for the hints!