DirectX 9 Debug Mode Crash with ColorFill / UpdateSurface

[Jamie Gotch]

When attempting to write to a surface using the DirectX 9
ColorFill routine as follows:

m_pd3dDevice->ColorFill( pSurface, NULL, D3DCOLOR_XRGB
( 0, 255, 0 ) );

the application generates the following
message: "Unhandled exception at 0x00334c80 in App.exe:
0xC0000005: Access violation reading location
0xe8dc4d99." This ONLY occurs after compiling in DEBUG
MODE (i.e., D3DSpy is executing and the debug library,
d3dx9dt.lib, has been linked).

This method executes properly and returns S_OK. However,
when the application is compiled using RELEASE MODE, it
executes just fine without crashing (and everything
expected does occur as planned). Additionally, the same
situation reoccurs when attempting to use the DirectX 9
UpdateSurface routine for copying a portion of a surface
to a texture (and likewise, it executed just fine in
RELEASE MODE). I have followed and met all restrictions
proposed by the DirectX 9 online documentation, and yet
have not found a solution. Debugging an application
which attempts to write to a surface in some way (whether
via UpdateSurface, ColorFill, etc.) causes the
application to crash after compiling in DEBUG mode.
However, the original application had been written in
DirectX SDK 8.0, and it had executed as expected with the
CopyRect routine.

The debug runtime outputs very little before the crash
occurs, and it is nothing even closely related to the
problem at hand. In the debug output window, I receive a
first-chance exception which is immediately followed by
an unhandled exception, but this information has already
been notified by the error dialog box that appears when
the application terminates. The variable at the memory
address just contains garbage information, so it appears
as though the problem is due to an invalid pointer.
However, as I had said before, this is very confusing, as
the application executes flawlessly in release mode.
When looking at the disassembly, the application crashes
AFTER all variables are placed onto the stack, failing at
the call to the UpdateSurface routine. However, when
either the pSurface or the pTextureSurface parameter are
not mentioned in the method call, the program executes
smoothly; it just does not perform as expected. My guess
is that the program is attempting to access memory that
has been marked as invalid to the debugger when the data
copy is being performed, but this is only an assumption
and nor does it aid me in finding a solution.

My goal is to retrieve data from a D3DPOOL_SYSTEMMEM
surface and to write it to a texture using the
GetSurfaceLevel routine and UpdateSurface. If anyone can
help solve my problem, explain the reason as to why this
access violation is occurring, or has experienced a
similar situation, your advice would be greatly
appreciated.

[Phil Taylor [ATI]]

I suspect that, despite your feelings, this app does not "execute
flawlessly" in release mode. This sounds like there is a bug in your code,
some null pointer is overwriting garbage in your app where pSurface or the
pTextureSurface parameter are.

What if you set a breakpoint on those variables changing?.

Perhaps trying something like BoundsChecker would be a way to resolve this.

"Jamie Gotch" <jmg...@psu.edu> wrote in message
news:4dc401c334a7$116f3770$3101...@phx.gbl...