Hmm... unfortunately, it seems your libc was compiled without debug information in it. Which means a good bit of that backtrace (both the current function name and the first function name in the call stack) are nonsense.
=>0 0x402e0421 (NTDLL.DLL.memcpy+0x2cec1 in libc.so.6) (ebp=4d762f04)
1 0x4070bf6c (TIME_MMSysTimeThread+0x6c(arg=0x40395054) [time.c:159] in libwinmm.so) (ebp=4d762f20)
2 0x400f199d (THREAD_Start+0x5d [thread.c:257] in libntdll.so) (ebp=4d762f38)
3 0x400f0c88 (SYSDEPS_StartThread+0x38(teb=0x4d773000) [sysdeps.c:168] in libntdll.so) (ebp=4d762ff4)
4 0x4030fbaa (NTDLL.DLL.memcpy+0x5c64a in libc.so.6) (ebp=00000000)
how the offsets (the ones in bold) from the start of NTDLL.DLL.memcpy are so huge compared to the others? That's a good indication that the affected address isn't actually in that function (memcpy, in this case). The filename (libc.so.6) is right., though.
Have you ever compiled glibc before? Reconfiguring it with --enable-debug would probably give better information, but the process is a little complicated.
I must admit, I haven't seen anything like this in wine or winex before, but hopefully it won't be too hard to track down. Hopefully...
Does SuSE 7.3 use gcc 3.2? If so, I can compile glibc and post the libc.so.6 file for you, with --enable-debug, but if not, I'm fairly sure that won't work.