The reason 0x42480000 looks suspicious is that it's the integer representation of 50.0f.

If you search the code you'll see that 50.0f is used initializing the Vertex_List array in the Create_Polygon() function.

A quick inspection of the array declaration says you're going off the end of the array:

CUSTOM_VERTEX Vertex_List[3];

void Create_Polygon()
{
Vertex_List[0] = Create_Custom_Vertex(-50.0f, 100.0f, 0.0f, D3DCOLOR_XRGB(255, 255, 255));
Vertex_List[1] = Create_Custom_Vertex(50.0f, 100.0f, 0.0f, D3DCOLOR_XRGB(255, 255, 255));
Vertex_List[2] = Create_Custom_Vertex(-50.0f, 0.0f, 0.0f, D3DCOLOR_XRGB(255, 255, 255));
Vertex_List[3] = Create_Custom_Vertex(50.0f, 0.0f, 0.0f, D3DCOLOR_XRGB(255, 255, 255));
}


Wow, that's magnificent debug-fu

Thanks

I did cheat a bit use a debugger for one thing there - typing [color=#0000ff]0x42480000,f into a Visual Studio watch window does the hex to float conversion and tells you that it's 50.0f. I didn't compile or run the code myself though.

The more usual way of debugging it would be to spot that the pointer had changed since you initialized it, and then rerun it and put a data breakpoint on it just after initialization.

However that's not always possible, especially if the memory that gets trashed isn't in a consistent location, so working backwards from the data that it's been trashed with can come in handy sometimes. For example when what you have is a one-off crash dump instead of a reproducible bug.