Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
If you aren't experiencing this issue when running other software, I would first examine the mods you've got. I don't use any mods myself, and Civ VI is one of the most bulletproof, bug-free games in my library; it just never crashes.
"'Unhandled Exception' errors are very generic and can have many root causes, so they are not easy to diagnose. It's impossible to say the exact cause with the limited information you've provided. Generally, however, it is likely a mod that is causing your error. The best thing I can recommend is try to start a game with no mods active, then gradually add them back one by one checking to see if they updated recently and/or are compatible with the current game version. You could also check your Database & Modding Logs for errors."
I strongly disagree with this opinion. It's very common on this forum, but it's not based on a deep understanding of programming, the structure of the game, and the nature of bugs, and access violations in particular.
While it is true that there is no proof that a mod is the cause here, I'm not sure what your argument is against that supposition.
We have a few facts at hand: One, there has been a recent rash of complaints about the "access violation" exception being associated with Civ VI. Two, so far as I know, there have been no recent updates to the base game. (And personally, I know that I've not experienced any instability in the game myself.)
As such, it seems logical to investigate those aspects of the game that do get updated frequently, but are not part of the base game. In particular, mods.
Do you disagree with this?
If the game , with all mods unsubscribed and cleaned out by deleting the file mods.sqlite in (default path) documents/my games/sid meier's civilization vi , does not give the constant "Unhandled Exception (code: EXCEPTION_ACCESS_VIOLATION) Error reading address 0x330", then it probably was a mod.
If it's still doing it, I would be looking at repairing or reinstalling Microsoft Visual C++ redistributables or increasing virtual memory.
But I bet it's a leader mod.
And I bet it's something silly like forgetting to add spy names.
Very well. I presume you are arguing that, because Lua, XML, and SQL are such high-level languages, access violations are far more rare than in a low-level language such as C++, where the programmer has far more flexibility to directly control memory management. This is true.
However, the problem here is that we are using Lua, XML, and SQL to directly manipulate a very large program that is (probably) implemented in a low-level language such as C++. We are allowed to create new (or modify existing) civilizations, leaders, units, and the like; we can manipulate fundamental concepts within the game such as production, gold, or faith costs of buildings or units, unit features such as sight range or zone of control, civilization features, leader features, heck even UI features. We can warp this game in ways that the authors never even dreamed of, let alone prepared for.
In short, the variable typing features and error checking inherent in high-level scripting languages is of no protection, if you are using that code to manipulate a program written in C++ to do something the original authors never intended.
If this error is associated with a mod, the best we can do at this moment is to isolate the mod causing the issue and remove it from the game. (Games without mods do not appear to be crashing.) Hopefully, the mod's creator can eventually fix the bug.
But again, this particular exception is extremely generic, so yours might be from a different issue.
No. I am arguing that you don't really know what you're talking about, and I can tell that you are not a programmer and have no experience debugging program crashes.
XML is not a programming language. It is data. Data description. All the xml in the world does absolutely nothing by itself. It doesn't run. It doesn't execute. It cannot create an AV. Period.
You need code to load the XML and then do something based on it. The code that loads XML is designed to deal with invalid specifications and not crash. It's not code that is part of the game source, that's licensed software from somebody else. The game code that interprets the loaded XML, that is part of the game source, and it can have a bug, and can crash, but XML is inert. A mod consisting solely of XML is inert. If the game loads that XML and crashes, it is because the game has a bug, not the XML.
LUA is an interpreted language. It runs in a virtual machine. LUA errors, such as referencing an undefined variable, are caught and handled, they do not result in an AV. If the LUA virtual machine itself has a bug, that is not a bug in a mod, it is a bug in LUA, and is not the modders fault or the game's fault, that bug will belong to VMS software or whoever has implemented the lua VM in use. (And I'm skipping over the question of whether the AV is even occuring at the time the game is running LUA)
SQL is a database query language, not a programming language. If a SQL query causes a crash, you call up microsoft and tell them they have a bug in their SQL implementation.
You aren't paying attention to the fact that the crash is occurring early to mid game. *Not* during game loading when the XML from mods is loaded, the SQL is processed, and the LUA run.
Here's a challenge for you, since you are pretending you know something: Create for me a mod that crashes the game. LUA, SQL or XML or all of them. Create the mod and provide the exact steps that cause it to crash the game reliably and consistently. I don't think you can, because I think you're a poser with no real experience.
Very well. I'd never created a mod for Civ VI before, so I went ahead and looked at how you set one up. I've put together a minimal mod on my home system now. Probably the easiest way to confuse the game is to just mess up the parameters for an existing unit. I've chosen the "siege" class of units, as you don't get the chance to construct one until you've done a bit of research (and therefore, it probably doesn't crash the game right away).
So, for my first attempt, let's make siege units have a really, really long range. Such as 1000 tiles. Not too hard, this just requires a modification of existing data in the sqlite databases of Civ VI. The following statement performs this task:
(I should note that I cribbed this off of Marco's "More Realistic Artillery" mod, it would have taken me much longer to find the appropriate items in the database otherwise.)
Place this into a .sql file in your mods directory, create an appropriate .modinfo file, and we're off to the races. (Well, sort of. I had some trouble finding the correct local mods directory, so I went ahead and used the workshop directory instead. I'm still figuring this stuff out.)
Amazingly, this works! The game accepts the new range without complaining:
https://steamcommunity.com/sharedfiles/filedetails/?id=3004197673
It's kind of amazing watching a catapult launch a sub-orbital kinetic strike anywhere on the globe. :)
Anyway, let's try a little harder. This time, I loaded up the siege units with lots of just random values; a bombard strength of 1234, a combat strength of 4321, a base movement range of 12786, a base sight range of 44682, and a firing range of 12878:
The game accepts these values:
https://steamcommunity.com/sharedfiles/filedetails/?id=3004197710
However, things go bad as soon as you construct one of these guys and click on him. Possibly because the sight range reveals the entire map (other than what is obstructed by terrain), or because it is trying to calculate the paths available to the catapult with ridiculous movement range, this caused my machine to hit 100% CPU and never returned. I ended up having to kill the app.
So no, I don't know exactly how to create the specific "access violation" error (at least, not yet), but it is quite easy to use a mod to crash this game.
EDIT: Simplified unnecessarily complex SQL update statement.
EDIT2: I didn't really need to mess up an entire class of units. It's probably simpler to just focus on a single unit type, like the catapult:
As I keep saying, an AV is a specific kind of problem, and mods are only feeding data to the program, not directly providing code - and it is code that can AV.
I think your obsession with blaming mods for everything is more superstition than knowledge based and I think you're doing a disservice to the community by pretending to know more than you do and jumping into every thread with the advice to take off all the mods.
It's especially bad advice to take off the mods one by one as you did in that other thread. The guy has 120 mods on, and you want him to take them off one by one? You obviously have never worked as a programmer. Divide and conquer? Binary search? Hello??
The mostly likely reason for an AV is a bad update to the DX library, which microsoft does *a lot*, or a bug in the graphics driver. When I was working at AMD there were people underneath my second-line manager whose job it was to debug reported driver crashes, and they told me that more often than not it was not the driver, but DX that had the bug. And those were all AV's.
No, I haven't created an AV, but I've found a few clues as to how I might. I've been googling a bit, and one of the (many, many, many) different ways to generate the Civ VI AV appears to be overloading the game with excess graphical structures. (Apparently the "Warfare Expanded" mod can sometimes trip over this.)
No, this isn't a bug in the XML schema, as this has nothing to do with XML. This particular issue appears to be related to the mechanism used to calculate available paths to a unit when moving it. And, given that I didn't use values anywhere near the limits of even a signed integer, I suspect that I'd be able to choose a value greater that the abilities of any machine currently in existence (although I haven't tested this yet). The game just doesn't seem to be placing limits on these numbers (although it shouldn't have to, given how stupid those numbers are).
I would argue that this isn't even a bug; you shouldn't have to load your executable down with run-time checking for every single value in use. There are thousands of values stored in that database, it would take noticeable real-world time to consider all the possible overflow, underflow, and otherwise inappropriate values for each one. (And some of those would indeed be judgement calls based on the abilities of the target hardware.) They could perhaps place some additional constraints on modders, but it's probably more appropriate to let modders act freely and fix their own code themselves.
And as I keep saying, if the mod is triggering a bug in the program that would otherwise never be hit, that's the mod's problem, not the program's problem.
Ah, so it's okay for you to assume I'm not a programmer, but it isn't okay for me to assume that someone else isn't a programmer. Very well, guilty as charged. I apologize.
I've been going through an older, very comprehensive thread on Civ VI AVs. In that one, if I'm reading it right, about a third of the people who reported fixing their bug stated that it was a problem with a graphics driver. (A lot of folks guessed that it was an issue with DX, but weren't able to show that.) Roughly another third were able to manipulate their mods in such a way as to remove the issue; many of them stated that it was associated either with a very very large mod (e.g., "Warfare Expanded"), or with a significant quantity of mods that simply overwhelmed the game in some manner. And the rest pointed to any number of other fixes, such as sound drivers, wireless mouse drivers, badly behaving applications, and other odds and ends.
But it appears that the majority of participants in the thread never did find the cause of the AV (even after testing all these possibilities), and simply gave up.
Here's the thread:
https://steamcommunity.com/app/289070/discussions/0/2243301553217932538/
In any case, I apologize if I'm jumping the gun to blame mods for this issue. I do still think that switching off mods is the easiest thing to test for first, and has the highest chance of fixing the problem, given the evidence of how people previously fixed their AV issues.
Now this is interesting! The Steam Deck isn't running Windows, and it has a single well-understood and well-supported GPU, so much less scope for driver bugs. And I do know that Civ VI has been running perfectly on the Deck.
So, let me ask: are you using mods? Can you try running the game without the mods? Could you sort through your mods to try and find one (or a group) that might be associated with the error? (As @eastwind points out above, a binary search sort of process could make this less painful, if you're managing lots of mods.)