• Advertisement

Archived

This topic is now archived and is closed to further replies.

Access Violation Problem

This topic is 6518 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am currently getting as Access Violation from KERNEL32.DLL whenever I exit my game. It says: First-chance exception in Invasion2.exe (KERNEL32.DLL): 0xC0000005: Access Violation. This is happening AFTER WinMain returns, which is the weird part... People said before that it could be an error in one of my constructors, but right now I don't have any class objects being instantiated. Well, I do have a struct object (a Bitmap type). Actually, I do have one class being instantiated, for my level, but it doesn't define a constructor or destructor. I have Create and Destroy methods in it, and I don't think there's a problem with my destroy causing this, because then the AV would occur when I called Destroy... Does anyone have any suggestions? (sorry if this is not well written, it's very late.. ) ------------------------------ Jonathan Little invader@hushmail.com http://www.crosswinds.net/~uselessknowledge Edited by - Qoy on 4/18/00 3:40:22 AM Edited by - Qoy on 4/19/00 1:18:33 AM

Share this post


Link to post
Share on other sites
Advertisement
My only thought, is your program multi-threaded? You might have orphaned a thread and it decided to run amok.

Share this post


Link to post
Share on other sites
In most cases this happens because you reserve memory and forget to free it.

Visit our homepage: www.rarebyte.de.st

GA

Share this post


Link to post
Share on other sites
I''ve had 0xc0000005: Access Violation a couple of time before when I have run a program that tries to access the contence of an object pointer.

I''m sorry if this is no help.

Share this post


Link to post
Share on other sites
0xC0000005 Access violation is usually when the program is trying to access the contents of a NULL pointer.
>>>
and I don't think there's a problem with my destroy causing this, because then the AV would occur when I called Destroy...
>>>
Not necessarily. Objects are automatically deleted when they go out of scope.


ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, Tile editor, diary, 3D Art resources at Check out my web-site


Edited by - ZoomBoy on 4/18/00 6:35:19 AM

Share this post


Link to post
Share on other sites
The debugger tells me that I get about 3 First Chance exceptions before my program even runs! I have no idea how to find out more about this, but since it doesn''t seem to affect my program''s execution, I''m doing nothing for now.

Share this post


Link to post
Share on other sites
Qoy: Your access violation is probably the result of an invalid pointer being accessed in a class destructor. I''ve also encountered this problem when I forgot to release a DirectDraw surface. Without being able to view your code, all we can do here is speculate.

Kylotan: If they occur before WinMain (or main) is called, then they are probably occuring in the constructor of a global variable. You might want to look into that. To prevent things like this, I always use pointers when I need globals and then I dynamically allocate them when the program starts.


Josh
http://www.jh-software.com

Share this post


Link to post
Share on other sites
OK, I seem to have found the origin of the problem.. First of all, as it turns out, the AV wasn''t being thrown after WinMain returned, it was just displaying it on the debug window after.. It turns out it''s being thrown when I release the DirectDraw object (very weird).

Here''s the code:


void ShutdownDirectDraw()
{
if(backBuffer)
backBuffer->Release();
if(primaryBuffer)
primaryBuffer->Release();
if(dDraw)
dDraw->Release();
} // end ShutdownDirectDraw


The AV is being shown on the line dDraw->Release();

dDraw is an LPDIRECTDRAW, and primaryBuffer and backBuffer are LPDIRECTDRAWSURFACEs.

Is there any other code I need to show for this? I can''t think of what could be the problem...

Share this post


Link to post
Share on other sites
OK, some more information..

I turned DDraw debugging up to the HIGHEST debug level I could, and this is what came out around the Access Violation:

DDraw:INFO:Resetting primary surface
DDraw:DeleteOneAttachment: 840ca664,840cb71c
DDraw:Leaving AddRef early to prevent recursion
DDraw:DeleteOneLink: 840cb71c,840ca664
DDraw:DeleteOneLink: 840ca664,840cb71c
DDraw:Leaving Release early to prevent recursion
DDraw:Unsubclassing window 000000c0
DDraw: ProcessSurfaceCleanup
DDraw:Leaving ProcessSurfaceCleanup
DDraw: ProcessPaletteCleanup, ppal=00000000
DDraw: ProcessClipperCleanup
DDraw:Not cleaning up clippers not owned by a driver object
DDraw: ProcessVideoPortCleanup
DDraw:Leaving ProcessVideoPortCleanup
DDraw: ProcessMotionCompCleanup
DDraw:Leaving ProcessMotionCompCleanup
DDraw:In RestoreDisplayMode
DDraw:Redrawing all windows
DDraw:DoneExclusiveMode
DDraw:Enabling error mode, hotkeys
DDraw:FREEING DRIVER OBJECT
DDraw:Calling HEL DestroyDriver
DDraw:0 surfaces allocated - 0 bytes total
DDraw:*********** DDHEL TIMING INFO ************
DDraw:******************************************
DDraw:Calling DestroyDriver
DDraw:Heap aliases reference count is zero: discarding aliases
DDraw:Driver is now FREE
First-chance exception in Invasion2.exe (KERNEL32.DLL): 0xC0000005: Access Violation.
-WinMain: Returning...
DDraw:====> ENTER: DLLMAIN(bab004c7): Process Detach fffa8269, tid=fffa52b5
DDraw:====> EXIT: DLLMAIN(bab004c7): Process Detach fffa8269


I hope that wasn't too much Anyway, just thought that might be of some help..

Thanks!

Edited by - Qoy on 4/18/00 3:54:44 PM

Share this post


Link to post
Share on other sites
Hmmm, this is a longshot, but it''s possible that if you didn''t initialize your buffers to NULL when you started they might not be NULL when you check them if you never did anything with them and it would try to release something that isn''t there.
Also I''ve gotten into trouble doing if (backbuffer) rather than if (backbuffer != NULL) type things though not with DDraw, you might want to do the second type just in case.

-fel

Share this post


Link to post
Share on other sites
If the primary is a complex chain, then you shouldn''t be releasing the backbuffer unless you added it to the flipping chain yourself. Otherwise you just want to release the primary, which will take care of all the attached surfaces for you (although I''ve never seen this actually crash a system).

And you don''t have any palettes or anything else that your not releasing? If not, I''d say you need to invoke the classic method of commenting stuff out until the ddraw object closes with no problems, and then add stuff back in to see what causes the problem.

Rock

Share this post


Link to post
Share on other sites
Well, I got the backbuffer with primaryBuffer->GetAttachedSurface...

Anyway, I tried if (backBuffer != NULL) and I also tried not releasing the backbuffer explicitely, but the AV is still coming up. I'm starting to think I should just ignore it...

I guess I could try just commenting out stuff, but everything's so dependant on everything else with DDraw, that I wouldn't know where to start.

I'm running in a 16 bit mode, so I don't have any pallettes, and I don't have any clippers or anything, the only other DirectDraw object I have at all is a DDSURFACEDESC I think, and I used a DDPIXELFORMAT and DDSCAPS structs when I was initializing, but I don't think those should do anything...

Edited by - Qoy on 4/18/00 10:18:04 PM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
What compiler are you using? If you''re using the free Borland command line tools, that could definetly be your problem. I checked it out a little while back, and for no reason, every once and a while a build would end up with an executable that caused 3 exceptions on exit. It seemed to pop up randomly.. And it wasn''t programmer error on my part because even a damned hello world would cause this problem, and it also happened to code that compiled and ran fine with my MSVC++. I also saw in their support news group that other people were having this problem, so I gave up on that pretty fast. Anyone else here go through that? I wonder if they ever fixed that...

Share this post


Link to post
Share on other sites
Nope, it''s not that easy I guess I''m using VC++ 6.

Share this post


Link to post
Share on other sites
How would I go about getting that massive amount of debug information? As far as I know, I have the debug sliders set to full in the DirectX control panel, but I still don''t get much more than the 3 first-chance exceptions info.

And as for errors in constructors of globals... I never have more than 3 or 4 globals, and they don''t have anything in them which could really go wrong... just stuff like someMember = someValue... not even memory allocation. I''m hoping that being able to see more debug info may shed some light on the situation.

Share this post


Link to post
Share on other sites
I''ve had the same problem countless times. I have NO idea how to fix it! If anybody posts it up or knows what ''kind'' of error it is, PLEASE, for the love of god, mail me!

"Remember, I'm the monkey, and you're the cheese grater. So no messing around."
-Grand Theft Auto, London

"It's not whether I win or lose, as long as I piss you off"
-Morrigan, Super Puzzle Fighter II Turbo

Share this post


Link to post
Share on other sites
The only thing that I can think of is this: did you declare dDraw as LPDIRECTDRAW dDraw or LPDIRECTDRAW *dDraw? if it''s the first case, change it to LPDIRECTDRAW *dDraw( don''t ask me why though, when I had the same problem, that''s what I did and it worked... )



Cyberdrek
Headhunter Soft
DLC Multimedia
Two Guys Soft

Share this post


Link to post
Share on other sites

I don''t have much more to offer ...

Its definitely a problem, I know that sometimes in the release build the access violation won''t show up, but its still a symptom of a problem somewhere...it can just be a real pain to track down.

Follow fels advice and check all of your pointers:

if ( 0L != backbuffer ) ...


Once you have released your interfaces, set their pointers to 0L (NULL). Be sure that ShutdownDirectDraw() isn''t being called more than once..

Good luck!

Share this post


Link to post
Share on other sites
I''m getting the same Access Violation too, only in GDI32.DLL. Sometimes it appears, and sometimes it doesn''t. If DirectDraw was in the middle of a Blt or Flip or something when the program shuts down, could that cause an Access Violation like this? If so, how do you wait for DirectDraw to finish its current operation before shutting it down?

*Sparkle*

Share this post


Link to post
Share on other sites
I''ve never got KERNEL32.DLL AV. I used to get GDI32.DLL AV quite often last time. It just happen... and I don''t know where it came from.

Try commenting out your code.... comment out all DirectX code, leaving only Windows code, then slowly add them back.

Share this post


Link to post
Share on other sites
You said that the pointer is LPDIRECTDRAW. Are you sure that''s the one you''re using? That is DDraw3, or some old version. Make sure your pointers match whatever interfaces you''re really using. If you get a IDirectDraw4 interface, you have to save it off into a LPDIRECTDRAW4 pointer.

Rock

Share this post


Link to post
Share on other sites
Lets see...

Kylotan: The debug info appears when the slider is all the way up, and you run the program in the debugger I guess.. I'm using MM debugging. (not monochrome, two SVGA cards)

Cyberdrek: if I change it to LPDIRECTDRAW* dDraw I get a compiler error:

error C2040: 'dDraw' : 'struct IDirectDraw ** ' differs in levels of indirection from 'struct IDirectDraw *'

And I'm not sure if the LPDIRECTDRAW vs LPDIRECTDRAW4 could be a problem. Even if LPDIRECTDRAW isn't the most current, it still calls its own functions right? I'm pretty sure COM is organized so old versions of interfaces will still work...

Oh, and I tried to set them to NULL after releasing them. Still happening.

I mean, what's the real problem with just leaving it there?

Edited by - Qoy on 4/19/00 1:25:41 PM

Share this post


Link to post
Share on other sites
BREAKTHROUGH!

OK, I now know that the Access Violation ONLY occurs when I run the game on my second monitor... And it''s only gonna be run that way on my computer, so it doesn''t really matter all that much. I still wanna fix it if I can though.

All I have to do to set up the second monitor is enumerate devices, and in a callback function I test and return the GUID of the first device which has a monitor handle of NULL (because that''s the first display device attached to the main display, but not the main display). Then I use that GUID to set up DirectDraw.

Do I need to do something to return the GUID or something?

Thanks!

Share this post


Link to post
Share on other sites
Ok, I turned the debug info back up (I think installing DX7 turned the slider back to ''less'') and, what do you know, I don''t get First-Chance exceptions anymore... making me think it wasn''t my code in the first place. Hmm...

Share this post


Link to post
Share on other sites
There is a big difference between LPDIRECTDRAW and LPDIRECTDRAW4. Old versions of the interface are guarenteed to work IF you use the old interfaces from start to finish. So if your program creates a IDirectDraw interface, and saves it in a LPDIRECTDRAW variable, it will continue to work even on DX7. The interface will always be there. That''s why DX3 games run fine under DX5,6,7,.....

But you can''t (possbly read shouldn''t) create a IDirectDraw4 interface and treat it as a IDirectDraw interface. It isn''t one. Some functions may line up correctly, but under no circumstance should you rely on that.

I''m not a COM wheenie (nor do I want to be), so maybe someone can elaborate, but you have to keep your pointers correctly typed. It''s pretty easy; just make sure if you''re creating a IDirectDraw4 interface, to change your pointer type to LPDIRECTDRAW4. Same goes for the surface interfaces, and any others.

Rock

Share this post


Link to post
Share on other sites

  • Advertisement