• Advertisement
Sign in to follow this  

Visual Studio Bug?

Recommended Posts

Hi,

I am using Visual Studio 2013 Express on Windows 10 to develop my game. Recently, I've ran into a problem concerning Direct3D: When I start my game, it crashes as soon as it starts rendering the first frame with different error messages stating that there was an access violation reading/writing/executing at different locations. However, when I compile the game on Windows 7, it runs on both Windows 7 and 10 without this error. When I try to run the game compiled on Windows 10 on Windows 7, it crashes, too. It does not crash in Debug build, only in Release build. I once "fixed" the problem by outputting the device context using OutputDebugString(). Some changes to the code in unrelated locations seem to "cause" this error.

I already tried re-installing Visual Studio and updating my graphics driver, but that didn't help.

Can I re-install the Direct3D SDK somehow? Or is there maybe another solution?

 

Edit: SOLVED (see post #15)

Edited by Magogan

Share this post


Link to post
Share on other sites
Advertisement

It does not crash in Debug build, only in Release build.

Without further information, this sounds like a memory-access related error, likely due to an uninitialized variable which doesn't show up in debug because memory is preinitialized there. Try a tool for detecting such errors like Microsofts application verifier (https://www.microsoft.com/en-us/download/details.aspx?id=20028), while creating debug symbols for your release build (https://msdn.microsoft.com/en-us/library/fsk896zz.aspx). This should optimally lead you to the exact point of failure.

Additional things to do: Turn on the directx debug layer + break on error/corruption, see if this leads you to the source of the crash. Static code analysis tools can also help (http://cppcheck.sourceforge.net/).

If this doesn't help, it might be something else, it just sounds like something along those lines.

Share this post


Link to post
Share on other sites

It is almost never a Visual Studio bug. Even if it only crashes with one version of the compiler, the issue is usually that you are relying on undefined behaviour which can differ from one compiler to the next.

Suggestions:

  • Check that all your variables are being initialised properly, and never assume they start at some correct value if you didn't do it explicitly
  • Test your debug build with all the runtime diagnostics you can; often the problem exists in debug mode too, but it just doesn't present itself unless you look for it
  • Try creating an 'optimised debug' build; you may be able to find out more about the crash this way, although the call stack may not be 100% accurate.
  • Try using #pragma optimize("", off) around various functions - if the crash goes away, it's likely that the error lies in that part of the code

Share this post


Link to post
Share on other sites

In this case, all variables were initialized. It crashes when I clear a depth buffer. When I debug the graphics, I get the warning that the depth buffer is read-only, which does not make sense because it was created to be read- and writable. I initialize the graphics in the main thread. After initialization, I create a render thread that then uses those variables. This should not be undefined behavior, though.

Additionally, I don't see how this could possibly lead to an access violation by execution, meaning the PC register is somehow invalid. The device and device context cannot be corrupted at this point since the device is thread-safe and I protect the device context by a mutex each time I use it.

I turned off optimization to test it and sometimes the error did occur without optimization, sometimes not.

This problem first occurred when I changed some unrelated code.

Edited by Magogan

Share this post


Link to post
Share on other sites
But why does it work on Windows 7 with the same compiler (Visual Studio 2013 Express)? It is exactly the same project (I just load it from the same location on the hard drive).

I am certain that the 3 variables involved here are actually initialized. If there was an error in the creation of the device, device context, or depth buffer, the game would have shown an error message and exited.

The code I changed last time was not even executed before the error occured... It was code for some NPC rendering, but there are no NPCs in the game menu displayed at the beginning.

The depth buffer clearing is the second instruction in the rendering and before it there is only initialization since it crashes on the first frame. I don't know what I could have missed.

It works now, though, but I don't know for how long. It worked for years (literally) without any error. I've developed this game since about 2 or 3 years and this part of the code has not changed in all this time, but it just crashed in the last two days. How could this be possible?

Share this post


Link to post
Share on other sites
Could be a (graphics) driver update.

Enable DirectX debug mode (e.g. set the flags on creation). Any warnings/errors showing up there, when you run your game?

Share this post


Link to post
Share on other sites

Could be a (graphics) driver update.

Enable DirectX debug mode (e.g. set the flags on creation). Any warnings/errors showing up there, when you run your game?

As I already said, I already updated the graphics driver and the debug mode only shows a weird error message stating that the depth buffer is read-only, but nothing helpful. :(

Share this post


Link to post
Share on other sites
I cannot post the exact error message for this error does not occur at the moment, but it said something like that the depth/stencil view was created with the "depth read-only" flag and therefore ClearDepthStencilView does not clear the depth/stencil buffer. This is just not the case (I set the flags to 0), so the error message is not very helpful.

Share this post


Link to post
Share on other sites
I'd still not disregard this message, I've never seen that output being wrong.

Try to really track down if the variable at the moment of the call is actually set to zero. It could be that you do init it to zero, but something else trashes it.

Are you passing a variable in that argument? Could that variable not be initialised?

Share this post


Link to post
Share on other sites
I set the whole struct to 0 using memset and then set the member variables accordingly. So Flags is definitely 0. Even if the depth/stencil view was created with the read-only flag, the game should not crash, it should only look wrong.

The depth buffer texture is also initialized correctly. And I check whether the initialization of the DSV was successful.

There is definitely no variable that is not initialized...

Share this post


Link to post
Share on other sites

There is definitely no variable that is not initialized...

 

Is there a local variable anywhere else in your code that is not initialized?  Even in a completely unrelated part of code?  Because unitialized local variables are the cause of 99.99999% of "works in debug/crashes in release" problems and in the absence of compelling evidence otherwise that is what we must assume that your problem is too.

Share this post


Link to post
Share on other sites

Array overrun, perhaps? Or writing through a bad pointer? Have you tried an optimised build with debug symbols yet?

The other thing is that you're doing things in different threads with shared variables. You say it "shouldn't" be undefined but it's not clear how the 2 threads interact. I'd be tempted to look closely at that and make sure nothing is getting written by one thread while it's being read by another.

Share this post


Link to post
Share on other sites

Array overrun, perhaps?

...

I use an array for the blend states and an enum to enumerate them. I added a blend state a few days ago without changing the size of the array... That's what happens when you change code you wrote years ago when you were not as experienced as today...

I will now use something like the following instead of defining NUM_BLEND_STATES as a macro:

enum EBlendState{
	BS_Disabled,
	BS_Enabled,
	BS_Light,
	(...)

	NUM_BLEND_STATES
};
Edited by Magogan

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement