On 27 August 2010 14:04, wylda@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.