LoadResource with module=0x00400000 followed by stack overflow

[Jan-Espen Pettersen]

I get this stack overflow exception while trying to run the Watchtower
Library Setup on FreeBSD 6.1. I have extracted some debug lines which I
think is relevant. Please ask if you need more information.

0009:Call ntdll.LdrFindResource_U(00400000,0034ecf0,00000003,0034ec8c)
ret=9c266b12
0009:trace:resource:LdrFindResource_U module 0x400000 type #0006 name
#0901 lang 0414 level 3
0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40b000 id 0006
ret 0x40b090
0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40b090 id 0901
ret 0x40bb98
0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40bb98 id 0414
ret 0x40d1c8
0009:Ret  ntdll.LdrFindResource_U() retval=00000000 ret=9c266b12
0009:Ret  kernel32.FindResourceExA() retval=0040d1c8 ret=00405ac0
0009:Call kernel32.LoadResource(00400000,0040d1c8) ret=00405ae4
0009:trace:resource:LoadResource 0x400000 0x40d1c8
0009:Call ntdll.LdrAccessResource(00400000,0040d1c8,0034ed48,00000000)
ret=9c26807b
0009:trace:resource:access_resource access resource
0009:trace:resource:access_resource *ptr=0x4219d0
0009:Ret  ntdll.LdrAccessResource() retval=00000000 ret=9c26807b
0009:Ret  kernel32.LoadResource() retval=004219d0 ret=00405ae4
0009:Call
ntdll.NtCreateEvent(0034e634,001f0003,0034e8dc,00000001,00000000)
ret=9c22d14a
0009:Ret  ntdll.NtCreateEvent() retval=00000000 ret=9c22d14a
wine: Unhandled stack overflow at address 0x405b1d (thread 0009),
starting debugger...

(There was thread two (to 000b and back to 0009) context switches in
between, which I filtered out)

I single stepped the last instructions before the crash and found that
it crashed while trying to write to the memory pointed to by the
returned pointer from LoadResource. It loaded the address with some
offset into register %esi and crashed at an andw instruction:

First chance exception: stack overflow in 32-bit code (0x00405b1d).
file_set_error: Bad address
file_set_error: Bad address
Register dump:
 CS:0033 SS:003b DS:003b ES:003b FS:1007 GS:001b
 EIP:00405b1d ESP:0035ee08 EBP:0035f224 EFLAGS:00010346(   - 00      RITZP1)
 EAX:0000006c EBX:00000000 ECX:00000003 EDX:00000000
 ESI:00421b5e EDI:00421a86
Stack dump:
0x0035ee08:  9c266cc0 0035f954 0035f230 00000000
0x0035ee18:  00401df3 00009003 0035f224 0035f958
0x0035ee28:  0035f954 00000000 9c086a19 9c0da2c0
0x0035ee38:  0035ee78 9c092b72 00120020 00000001
0x0035ee48:  9c086957 00000000 00000000 0035ee34
0x0035ee58:  005ca2c0 9c08b791 00167e10 00000000
0200: sel=1007 base=00110000 limit=00001fff 32-bit rw-
Backtrace:
=>1 0x00405b1d in setup (+0x5b1d) (0x00405b1d)
0x00405b1d: andw        $0,0x0(%esi)

Wine-dbg>info share
Module  Address                 Debug info      Name (3 modules)
PE      0x9c070000-9c0dd000     --none--        ntdll
PE      0x9c210000-9c2f1000     --none--        kernel32
PE      0x00400000-0042b000     Export          setup

Can a win32 program expect that it has write access to the memory
pointed to by the return value of LoadResource with module 0x00400000?
Should LoadResource in some cases copy the memory and return a writeable
copy of the resource?

Jan-Espen Pettersen

[Mike Hearn]

On Tue, 20 Jun 2006 12:49:25 +0200, Jan-Espen Pettersen wrote:
> Can a win32 program expect that it has write access to the memory
> pointed to by the return value of LoadResource with module 0x00400000?
> Should LoadResource in some cases copy the memory and return a writeable
> copy of the resource?

The SEH handling code should catch this case and un-protect the resource
section. At least it does for InstallShield ... I'm not sure why it's not
working here.

thanks -mike