wqweto / modernsubclassingthunk Goto Github PK

Hey there, you pointed me to this from StackOverflow.

I managed to get this kind of working, but the VB6 IDE randomly crashes for me. Often on the third run, but not always. It often follows this pattern, but it also depends on whether there are debug statements and if I initiate vb6 from Visual Studio or not. But in all cases, it eventually crashes.

1. I run my program, close it (properly).
2. I run my program, close it (properly).
3. I run my program and get a crash while loading

I don't quite understand the underlying thing that makes this work so it's tough for me to debug. I'm only using the Subclassing thunk in my main form. It seems more stable if I put a debug statement on the Set SubClass = nothing that I have on program close, but it still crashes eventually.

How might I diagnose this?

I know this is for VB6 not VBA. I'm just wondering if it's likely to be at all possible to get this working for 64 bit VBA. At the assembly level I think there start to be some key differences so I think the thunk code might have to change.

I'm not actually trying to subclass but I am trying to get some code working that uses WinAPI timers to call VBA methods and this approach you outline I'm pretty sure could allow the debugger to work cleanly in those (right now if I have an End statement in the callback method then that crashes the VBA host)

Shot in the dark asking! But I'm sure you know enough of the internals to figure it out ;)

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!