I, too, assumed that the RefCon value was intended for passing back context variables such as this pointers. It works fine for that on the Mac. The Mac implementation relies entirely on the callback and does not need an event pump.
The 2.0 DSM is broken. When I discovered the RefCon passback was not implemented, I decided just to ignore the callback feature on Windows. That worked fine for the Epson scanner I was using for tests. However, when I tested with the TWAIN dummy software source, it blocked on the GetMessage call, even though I had not defined a callback. Reverting back to twain_32.dll (and supplying a window handle to DSM_Entry on startup) worked fine with the software source. So, that made me worry that future drivers for real devices might rely on the callback being there for the 2.0 DSM, causing apps that don’t implement it to hang.
The docs also do not make it clear that, on Windows, you need to implement both the callback and the event pump. I assumed it would work like the Mac — no more message pump. But when I tried that with the Epson, it showed empty UI windows, making it obvious the event pump was still needed.
I looked at the TWAIN sample application. It implements the callback, but uses a global variable to track it. That’s poor coding practice: globals are not thread-safe.
One possibility would be to store your this pointer in thread local storage (google TlsAlloc and friends). Another might be to cram it past the end of your manufacturer or product name in the appId and make sure your name string is 29 characters or less (better make that 25 to allow for 64-bit).