Hey, I have now sussed out how to load a bitmap to the screen using the TOTWGPG module libs, only prob is when I exit out of the loaded bitmap program, I get the following error message(s) Unhandled Exeption in filename.exe 0xC0000005: Access Violation This is in a windows box, then when I click okay I get this from the compiler debug prog: - Please enter path for MEMCPY.ASM Anyone shed any light on it, I have closed everything down correctly or I think so, I have checked everything it all appears fine apart from this. Help appreciated. Pk.

Hey,

Thanks, any ideas on how I can sort it out, the code looks fine as far as I can see?

Pk

This error means that you deleted a surface that was not there.

Make sure you delete your surfaces textures etc in the REVERSE ORDER you created them.

for dx 7. if you created ddraw, d3d, primary, back, bmp, texture,

THen you delete Texture then bmp, then back, then primary, then d3d, then ddraw.

If you are using dx8, make sure you unitialize after you delete everything else, and in order.

If you overwrote an array bound, the array would delete upon exiting, no error would occur.

If you underwrote an array bound, the program would not start with an exeption error.

Good Luck!!

-Matt

PS

If you are using the Borland compiler, this error often happens if you try to delete the back buffer after deleting the primary.

See, Borland automatically assumed that the backbuffer is attached, so deleting the primary is enough.

Also make sure (if using Borland Builder) that you rewrite the Windows Handler!

I HATE when I accidentally reply to the wrong post.

This is still not an over written array, this is a msvc++ being stupid.

Make sure you have all the header files needed, and also make sure you are building a simple windows app, using stdafx.h.

Also make sure you #define INITGUID in one of your files, and use ZeroMemory instead of memset.

this may not be msvc++ being stupid. its more likly an error on the part of the programmer. you say the code looks fine and all, but where does the actually crash happen? ignore the request for the source to memcpy, just dismiss the dialog. then at the assmebly view (this does happen in the debug build as well, correct?) goto the function call stack box and see which function it occers in to see which call to memcpy is the culprit. you could instead use debug messages written to a log file (make sure you flush after each write) where you log each time you call memcpy in your program. see which one the app crashes on and make sure for 100% that you are not using a bad index.

memset is not the problem, since it crashes on a call to memcpy which is a different function. any library that you use will have quirks, it is possible that the module libs you are using are buggy. you could be trying to access some meory AFTER you freed it. or the library is trying to copy some memery after you released since you did things wrong.

i truly believe its the coder at fault and not the compiler. you should really attempt to actually debug your code, you will be surprised what you thought was good code.

King1297, you dont ever need to use stdafx.h in ANY program written using the vc++ compiler. if that is the problem, then he configured things wrong, which puts the error on the part of the coder NOT the compiler. King1297, you cant even be sure what the problem is unless you see some code where the crash occers. the standard cause for when this happens is a out of bound array. in fact he could have written to an area of memory he owned which would not flag a gpf, but the array he wrote to belonged to the library which corrupted some memory which later affects something else. you would be surpirsed how many ways you can screw things up and not realize it using arrays improperly. then again he coudl have just clobbered part of the stack which in turn screwed up other vraibles he was using to access the array ising memcpy which in turn causes the gpf. of course those are simple scenarios that can occer. more complex things like overwriting into a directx vertexbuffer which merley makes the drawing of the buffer messed up are more difficult to spot and fix (mainly because you think its your loading code for the messed up model which in fact its code for a model that was allocated before, but modified after you fiddled with the corrupt looking model.

Sir_Spritly, give more info to the problem if you want help. no one will be able to solve it unless they see code where the problem is. espeically if you think that all the code is correct (the bane of all who try to debug their own code).

Hey,

It was my mistake, thanks for the tips though!

Pk