search

leecher1337 / ntvdmx64

Run Microsoft Windows NTVDM (DOS) on 64bit Editions
793 stars 81 forks source link

WOW32: Windows 10 Scrollbar bug #93

Open leecher1337 opened 4 years ago

leecher1337 commented 4 years ago

There also is an annoying bug in more recent Windows 10 versions which surfaces with subclassed Scrollbar-class, i.e. Visual Basic 3 ThunderHScrollBar class: Upon creation, in WM_NCCREATE, an address is set at the end of the Window's extra bytes. Currently the Thunder* classes of VB allocate the number of bytes from the control they are subclassing and add an additional 6 bytes at the end. So for instance,in my tests, the "Scrollbar" Window clas has 0x50 bytes, so 0x56 bytes get allocated. In WM_NCCREATE, an address is set at the first place of these additional bytes allocated, so at 0x56 - 6 = 0x50:

171F 16370935 14A7 User:CreateWindow(14a7,8d22,14a7,06c8,4401,0000,0000,0000,0000,0000,04b6,0001,14a6,0000,0000)
        String @14a78d22: "ThunderHScrollBar"
        String @14a706c8: ""
    Thunking window f047a message WM_NCCREATE
171F (WM_NCCREATE)
16-bit Window Proc = 161F0000
171F          Calling WIN16 WNDPROC(161f0000:047a,0081,0000,14a7,8ca4)
171F 161F0041 14A7 User:GETCLASSWORD(047a,ffee)
171F 161F0041 14A7 User:GETCLASSWORD: 56
171F 161F004A 14A7 User:GETWINDOWLONG(047a,0050)
171F 161F004A 14A7 User:GETWINDOWLONG: 0
171F 161F006F 14A7 User:GETCLASSWORD(047a,ffee)
171F 161F006F 14A7 User:GETCLASSWORD: 56
171F 161F007D 14A7 User:SETWINDOWLONG(047a,0050,10c7,00f2)
171F 161F007D 14A7 User:SETWINDOWLONG: 0

This Long gets set at the correct place (@0x50) However, in newer Windows verisons, there is some strange value at tagWND + 0xFC that gets subtracted from the GetWindowLong Index upon retrieval. As mentioned, in WM_NCCREATE the value gets set et the correct place, so this tagWND + 0xFC value is 0. However, in WM_CREATE, the value suddenly gets set to 0x50 (The code that does this hasn't been found yet, as it thunks out to 64bit world in user32.dll: _ScrollBarWndProcWorker --> NtUserMessageCall), so when the value gets retrieved later, it is read from 0x00, instead of 0x05, so it returns 0 and VB.EXE crashes in turn:

171F 15CF1A3A 14A7 User:IsWindow(047a)
171F 15CF1A3A 14A7 User:IsWindow: 1
171F 161F41C9 14A7 User:GETWINDOWTASK(047a)
171F 161F41C9 14A7 User:GETWINDOWTASK: 39f
171F 161F41DE 14A7 User:GETWINDOWLONG(047a,fffc)
171F 161F41DE 14A7 User:GETWINDOWLONG: 161f0000
171F 15CF1A51 14A7 User:GETCLASSWORD(047a,ffee)
171F 15CF1A51 14A7 User:GETCLASSWORD: 56
171F 15CF1A5A 14A7 User:GETWINDOWLONG(047a,0050)
171F 15CF1A5A 14A7 User:GETWINDOWLONG: 0

As MS was stupid enough to pull the tagWND definition from their symbols, it still remains unclear what this value is good for and where it gets used, thus, the bug cannot be fixed. Therefore it is recommended to use earlier Windows versions which don't suffer from this bug.

hdfsyu commented 3 years ago

its probably because of memory or maybe the mouse or drivers or something like that cuz the errors look like memory addresses