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