# C++ Game crashes only on Windows 7

## Recommended Posts

Posted (edited)

Hi,

I'm trying to find a bug in my game that causes it to crash on Windows 7. It crashes (almost) reliably when I do a specific thing in the game, but only on Windows 7 and only in the release build (without debug heap). It's some access violation reading from address 0000 0xxxx xxxx xxxx (it's always those 5 0's and a "random" number, weird). I'm testing my game on Windows 10 and this never happened in months (or years). On Windows 7, it crashed randomly and when I looked at it I actually found 2 problems and fixed them and now it crashes more often.

The problem with the error is: The game crashes at some point in time when I allocate or free memory in a different thread. I even tried to write code that causes such an error (to help me locate it) but everything I try makes it crash immediately.

How do I find the source of such an error? I would use the debug build but it just doesn't crash in the debug build. And I can't go through 50K lines of code.

I'm using several libraries but I doubt it's one of those. Their behavior shouldn't change on a different version of Windows.

Edited by Magogan

##### Share on other sites
Posted (edited)

Sounds like an irritated heap. If it was Linux and debug info was available i'd suggest to valgrind it ... ?

Edit: that may find such a corruption even on a different platform. A stray pointer is a stray pointer, in Windows 7 and 10 ... but i am just guessing ... maybe the offending code is only executed on Win 7 ...

Edited by Green_Baron

##### Share on other sites
Posted (edited)
20 minutes ago, Green_Baron said:

Sounds﻿ like an irritated heap. If it was Linux and debug info was available i'd suggest to ﻿valgrind it ... ?

I do have debug symbols but no debug heap and the code is optimized. I don't know, I have never done this before because I didn't need it. I guess now I need it.

Edit: I think I nailed it down to the GUI. It doesn't crash when I disable everything but the menu. Now I just need to find out which part causes the crash, good thing there are only about 20K lines of code for the GUI...

Edited by Magogan

##### Share on other sites
Posted (edited)

I found the problem, it was a small error on line 4078... I actually read from something that was deleted. That was pretty old code, it's weird that I never had a problem before.

I don't even know why I'm doing it that way, it makes no sense. I changed it so it can't happen anymore.

Edited by Magogan

##### Share on other sites
20 hours ago, Magogan said:

On Windows 7, it crashed randomly and when I looked at it I actually found 2 problems and fixed them and now it crashes more often.

99 little bugs in the code, 99 little bugs,
Take one down, patch it around,
117 bugs in the code!

In all seriousness, when fixing one bug causes two more to raise their heads, that suggests to me that the act of fixing the logic or design failure which induced the one bug, you also produced the side-effect of scraping away the crud which was hiding the other bugs...

12 hours ago, Magogan said:

I don't even know why I'm doing it that way, it makes no sense. I changed it so it can't happen anymore.

... and that would corroborate it. You might feel like the code is "fixed", but you should reconsider from a design perspective how you even reached that point. In particular, if you're using C++11 or C++17, and your application code includes any uses of the new/delete operators... you probably have a bug you haven't spotted yet.

##### Share on other sites
Posted (edited)
23 minutes ago, Wyrframe said:

...﻿﻿ ﻿and﻿﻿﻿ that would corroborate it. You might feel like the code is "fixed", but you﻿ should reconsider from a design perspective how you ﻿even reached﻿ that ﻿point.﻿

By being inexperienced when I wrote that code 3 to 4 years ago. It is actually fixed and I made sure this won't happen again.

23 minutes ago, Wyrframe said:

In﻿﻿ particular, if you're using C++11 or C++17, and your application﻿ code includes any uses of the new/delete operato﻿rs... you probably have a bug you haven't spotted yet

I'm actually using new to initialize smart pointers because Visual Studio doesn't show the constructor arguments when I use std::make_unique etc. I don't see that as a problem though. I'm open for suggestions as I have the same problem when I use emplace() or emplace_back() on their respective containers, I would really like VS to show what constructor options I have.

23 minutes ago, Wyrframe said:

In﻿ ﻿all seriousness, when fixing one bug causes two more to raise their heads, that suggests to me that the act of fixing the logic or design ﻿failure which ﻿induced the one bug, you also produced the side-effect of scraping﻿ away the crud which was hiding the other bugs...

It actually just made the same bug cause a crash more often because something changed. Any change could have caused that, it just happened to be another bug fix. It's weird that it didn't crash on Windows 10 on 3 different computers though, it really should have crashed at least sometimes.

Edited by Magogan

##### Share on other sites
Posted (edited)
42 minutes ago, Magogan said:

By being inexperienced when I wrote that code 3 to 4 years ago. It is actually fixed and I made sure this won't happen again.

👍

42 minutes ago, Magogan said:

I'm actually using﻿ new to initialize smart pointers because Visual Studio doesn't show the constructor arguments when I use std::make_unique﻿﻿﻿ etc﻿﻿﻿.﻿﻿

I guess I understand the autocomplete fail, but that doesn't mean you have to keep the "new T(" prefix after you've gotten the help. Unless VS doesn't detect it properly as a reference to the constructor when you're refactoring/searching for references, either?

Does VS understand move constructors well enough to suggest the insertion without the new? e.g. .emplace_back(T(...))? Although I guess that requires you haven't deleted or disqualified your move-construction operator (that is, T(T&&) noexcept).

Edited by Wyrframe
typo

##### Share on other sites
Posted (edited)
23 minutes ago, Wyrframe said:

but﻿ that doesn't mean you have to keep the "new T(" prefix

Yes, but there is no point in changing it, doing that just wastes time.

23 minutes ago, Wyrframe said:

.emplace_back﻿﻿(T(.﻿..))

Oh, yeah, I could write the type and then remove it afterwards but I'm rarely using any complex types in containers anyway, most of the time I use basic types like int or string or pointers as data types. Maybe it's because of the missing autocomplete. I could really need some features to speed things up in general, e.g. I often use tuple because it's faster than writing a struct/class with 3 data members, including a constructor if I want VS to show the constructor arguments, it doesn't do that if I use "{}" for initialization.

Edited by Magogan

##### Share on other sites

I'd suggest enabling page heap mode, which tends to make heap corruption bugs crash quicker, and therefore makes them easier to debug.

You can enable it with the gflags tool, which is part of Debugging Tools for Windows: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/

## Create an account

Register a new account

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 10
• 18
• 25
• 20