This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

If this is not the problem, I recommend comparing the address given to you in the access violation or segfault with any and all of the pointers involved in the line of code that's crashing, including the implicit "this" pointer used to access member variables. While it likely won't match exactly due to member variable offsets and the like, this will likely point you to the exact pointer that's causing the crash when dereferenced.

Very specifically, Tile::ERROR_TILE is being initialized by storing a copy of Tile::ERROR's value, but this is total garbage (because Tile::ERROR hasn't yet been initialized). Namely:

// this object is constructed before main() is invoked
// and TileType::ERROR is just an uninitialized pointer
// which you're copying into Tile::ERROR_TYPE.type
const Tile Tile::ERROR_TYLE(TileType::ERROR);

As some unsolicited advice, the entire structure of the code is just... awkward. If you find yourself wanting to use the "mutable" keyword, you should pretty much rethink everything you're doing. In almost 20 years of programming C++, I've never once had a legitimate use for that keyword; anything it can solve you can solve by a better abstraction (which may well mean less abstraction).

In your case, I'd keep a TileDatabase that just mapped simple integer IDs to TileType values. It can even just be a simple std::vector wrapper that returns a reference to the error tile for out-of-bound indices (e.g. invalid tile IDs).

You've got a ton of different objects/types defined, which is a usual sign of newer coders who've just learned about object-oriented programming but haven't learned the do's and dont's yet.

Remember: just because you have some conceptual "object" doesn't mean that it deserves its own C++ class. C++ classes and interfaces should focus on how things work in the algorithm and do not focus on how a human would categorize conceptual entities. In other words, don't make overly "concrete" classes, but rather focus on algorithmic abstractions. It takes a lot of practice and experience to really start understanding what that really means. A classical treatise of the subject is the Coffee Maker example, with a good explanation available at http://web.archive.org/web/20081227131937/http://www.objectmentor.com/resources/articles/CoffeeMaker.pdf