Need help in debugging a stack corruption

Stefan Dösinger stefandoesinger at
Tue Jan 3 14:17:14 CST 2006

I am working on a DDraw rewrite with WineD3D, and I've hit a problem with 
Half-Life, which looks like a stack corruption. HL makes a ret from a 
function which leads into sensless code, and I wasn't able to debug it.

That's what happens: From 0x00428a35 there's a call to a function at 
0x00408b70. This function calls a lot of DDraw calls, which seem to work 
fine, but on return, it doesn't return to 0x00428a3a, as it should, but to 
0x7fbcd888, which is valid, but contains only garbage code.

I assumed that some call runs amok on the stack, and I've set tried setting 
breakpoints at 0x00428a35, 0x00408b70 and some other addresses. Oddly, this 
doesn't work(winedbg disables them when continuing), although I can access 
the code right after start. I can set a DebugBreak() in the last called 
function(IDirectDraw::FlipToGDISurface), but there it is too late.

Are there any other ways to debug this? Does anyone know why setting the 
breakpoints fails?

Well, that's my suspicion for the problem: (an any COM expert comment on 
To create interfaces for IDirectDraw1 to 7, I created 4 lpVtbl structures for 
each version, and I cast most DD7 funtions info the older versions. Only 
where the type or the number of parameters is different, I use a wrapper 
function. At DD creation, I use whatever version was requested by the app for 
the new object. The old dd version used a number of macros to cast the 
various interfaces(defined in ddcomimpl.h). I don't use them. Might this 
cause the problem?

Thanks for your help,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the wine-devel mailing list