My program starts up and then 3 seconds later a windows error says "this program has to close." I've narrowed the problem to this code: m_pPlanetVB->Lock(0,0,(void**)&pVertexPlanet,D3DLOCK_READONLY); float bx5 = pVertexPlanet[parent].fX - orginx; float by5 = pVertexPlanet[parent].fY - orginy; float bz5 = pVertexPlanet[parent].fZ - orginz; m_pPlanetVB->Unlock(); There is nothing wrong with it, I think. I just want to read from the buffer but it doesent work, and the strange thing is I had it working for like an hour while I was still making changes to the program. Another part of the code also changes the buffer, so Im thinking somehow the way they interact may be causing problem. The logic of vertex buffer confuses me, because in the main function that fills the VB, even after it is unlocked I can write the above code with no problem, but in another function it crashes the program! Also, if I remove the lock it still crashes. The only other thing I can think to do is use stride and read from where the memory is stored, &m_pPlanetVB, when I created the buffer.

A few things:
1. Your debugger will tell you exactly what the problem is. Is there a reason you're not running it through the debugger? Your debugger will tell you the exact line the crash occurs on, and the reason for the crash (Probably a null pointer or something).
2. You cannot write to a pointer returned from Lock() after you Unlock() it (I'm not sure if that's what you're doing). Doing that is completely undefined behaviour.
3. What do the Debug Runtimes say?

Unhandled exception at 0x0040ee29 in terrain01.exe: 0xC0000005: Access violation writing location 0x00d47008.

In MVS 2008, i run it under debug and my whole computer freezes, I push sleep button just to get access to task manager to kill the program, but the log still had this in it.
I looked at your blog about debug sdk, and all it did was remove the pop up box when my program crashes outside MVS.

Also, the program has this library included
#pragma comment (lib, "dxguid.lib")

should I remove it and put something like this?
# pragma comment(lib, "d3dx9d.lib")



But the exception makes no sense anyways, because the code that is bugged does not write, its supposed to read by setting an outside variable.

Sounds like you have flakey drivers if the computer is freezing up. You really need to debug this sort of thing from within the IDE, it's a lot more difficult to do it from just an instruction address.

You could try running your app in debug mode with a breakpoint at the first line of WinMain(), and then go to dissasembly and see what source code line 0x0040ee29 refers to, but it'd be far easier to get the app running as it's supposed to in the debugger.
If you really can't use the debugger for some reason (Although there isn't a single reason I can think of), you could use something like DebugView to capture the output of the debug runtimes and see if there's something relevant there.

The access violation says it's writing, so the problem is definitely that you're writing to a bit of memory you don't have permission to write to. It's possible that the vertex buffer has already been Release()d, or any number of things that you really can't track down easily without a debugger.

As for the libraries, those are two totally unrelated ones. dxguid.lib contains the GUIDs for various DirectX interfaces (And you don't need it if you're just using D3D as far as I know), d3dx9d.lib is the debug version of the D3DX library.

Wow, I figured out what the problem was. Very sneaky in-fact. I dismissed it initially because I thought that writing some code would inhibit a function from running more than once.

cacheindex++;

Basically since the function keeps running over and over the index exceeds the limits of the array with only holds 100 elements. Although in reality the function isnt going to be ran every frame I was just testing it. I wrote the code like this to make it run only once, which didnt work, darn it.


if (*i = 0){
planet1->AddChecks(4);
*i = 1;
}

Apparently the above code doesn't work, even if I use a global pointer.


Also, @ Evil_Steve
My computer doesn't freeze, but the debugger will run the program, and when the exception happens there is a huge hangup in the program, and the debugger apparently.

And, what exactly does the debug sdk do? Does it work from within the compilers debugger?


EDIT:

I see some information in the debugger, but as soon as I click continue or break it dissapears

[Edited by - VprMatrix89 on May 6, 2008 2:02:00 PM]

Quote:Original post by VprMatrix89
And, what exactly does the debug sdk do? Does it work from within the compilers debugger?

It's a debug version of D3D - the release runtimes will just pass a lot of calls straight through to the driver, and do the absolute minimum of parameter checking. The debug runtimes will check every parameter passed to every function, and when an error occurs, they spit out helpful error messages in the debug output window (See the screenshot in my linked journal entry in my first post).
They work slightly slower than the release runtimes, but not by a huge amount (Your game definitely still be playable using the debug runtimes, unless you're constantly generating errors, which would be A Bad Thing anyway).

The debug runtimes work outside the IDE, you can run normal games with the debug runtimes installed, and use something like DebugView to capture the D3D debug output for them if you're interested.

Hi. Is this what you wanted
if (*i = 0){
planet1->AddChecks(4);
*i = 1;
}


or this
if (*i == 0){
planet1->AddChecks(4);
*i = 1;
}