Help with 6120d7cc145, causing bugs

[Henri Verbeet]

On 27 August 2010 14:04,  <wylda at volny.cz> wrote:
>
> Also from log previously attached, following string is written to
> address out of this word, isn't? Look like some return address than
> HEAP, right?
>
> 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,0021cac8
> "HDA NVidia",ffffffff,7dfc9ee4,00000020) ret=7dfb2ae4
> 0009:Ret  KERNEL32.MultiByteToWideChar() retval=0000000b
> ret=7dfb2ae4
>

Well, it would be this one:
> 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,7d6d8b18 "Digital",ffffffff,004e3044,00000020) ret=7dfb268b
> 0009:Ret  KERNEL32.MultiByteToWideChar() retval=00000008 ret=7dfb268b

> 0009:Call ntdll.RtlAllocateHeap(00110000,00000008,000004ec) ret=7dfb31c2
> 0009:Ret  ntdll.RtlAllocateHeap() retval=004e2b58 ret=7dfb31c2
This allocates 0x4ec bytes at 0x4e2b58, so that's 0x4e2b58 ->
0x4e3044. MultiByteToWideChar() writing 0x20 wide chars at 0x4e3044 is
clearly outside that range. At first sight I'd say there's an error in
the calculation for "mixdev[mixnum].chans" somewhere, that's what
ultimately determines the size of the block that's allocated above,
and should correspond to the number of lines filled in filllines(), 16
in the log you attached.