Critical Error during game start.

Voltoth

7 anos atrás
Views 12.785
atualizado 7 anos atrás
Completed - Resolved

When attempting to load the game, I'm met with the following error:

Critical error during game start

"Sharing violation on path C:\Program Files (x86)\Steam\steamapps\common\War For The Overworld\WFTOGame_Data\GameData\Options.txt"

The game cannot start.

I have checked the file and cannot find any issues with the contents. In case I'm missing something though, it reads as follows;

FirstLaunchLanguageDetection=
Lang=0
HoGLaunched=True
DLC=HeartOfGold
Screen Width=1920
Screen Height=1080
Screen Refresh Rate=60
FullScreenMode=True
Gamma=20
V-Sync=True
Camera Zoom Max=30
Editor Camera Zoom Max=50
Needs Pixel Light Upgrade=False
Pixel Light Count=10

This is the same computer that I have used to play the game for many hours before with no issues. I'm at a loss of what could be the cause of this issue.

Game Version:

Steam Public

Platform:

Windows

Como você classifica o suporte recebido?

Satisfaction mark by Voltoth 7 anos atrás

Add a comment about quality of support you received (optional):

Comentários 25

Antigos primeiro
Mais recentes primeiro Antigos primeiro

7 anos atrás

Hi Stefan, it's quite alright, I know that life happens and of course, that must always come first.

I'm glad the issue has been identified however, I have tried with my local security programs turned off and disabled and I did not have the Options.txt open in any editor at the the time of launching the game. I have tried closing down everything but steam and the game but still encounter the same issue. I even went as far as to disable windows defender (Despite being nagged several times by the OS)

Nothing I have tried so far, has produced any different results.

Incase this helps, I have included my dxdiag log file for additional troubleshooting. Hopefully that would shed some light on the situation.

DxDiag.txt

Resposta Link

Stefan Furcht

We are really puzzled what could be causing this problem.
Fact is the Options.txt file is locked by someone when the game writes to it and more interesting it succeeds multiple times before the issue occurs.
Could you upload us another output_log, just to see if it always fails at the same write or if it varies?

Is there any possibility that two instances of the game would start simulataneously?

Since it works for other users, we highly suspect a local issue with your system, but it is hard to guess why this file could be locked by the OS when the game tries to write to it.

If you have any idea, try to find anything which could cause this and disable it.

I am sorry, that we do not have any better idea what the cause could be.
As said it is the first report of this kind of issue we ever encountered.

Options.txt

I'm really confused too. I have no idea at all what it could be. Even more confusing is that this problem is new. As I mentioned in my original post, the game ran fine for me before and I've only really updated my computer. No other services or programs have been added. I'm completely stumped but the Options.txt seems to be the same all the time. I just tried again to get a clean version while deleting the previous version as recommended before but still encounter the same issue. However, interestingly enough, the game did give me an achievement this time around. "New Year Goodness"

I have checked my task manager when launching and as the error occurred and noticed a spike in disk activity but only one instance of the game was running.

> Could you upload us another output_log, just to see if it always fails at the same write or if it varies?

Your system specs seem fine to run the game, so nothing that immediately points to any issue in your DxDiag.

As requested.output_log.txt

Looks identical to the previous one to me but maybe there are some subtle differences.

Yes it is exactly the same issue at the exact same place.

And the most mysterious thing is, that this is write access number 4 after 3 previously successful write accesses to the same file.

Like if something would only allow us to write the same file thrice in a sequence and then lock it away.
(This is why we suspected AV software but you already removed this potential cause)

When did the problem start to occur?
Did anything special happen in between it working and when it broke?
Did you change anything on your system in this time, or installed any new software?

Did it happen after a Patch of the game?

In case you didn't do it yet, can you verify your steam files, to make sure it is not Steam which is actually stuck updating the file during game start.
Here is how to do this: https://support.steampowered.com/kb_article.php?ref=2037-QEUH-3335

I'm not sure exactly when the problem started as it has been quite some time since I actually played the game last, however, I noticed it when trying to start the game up last week. (The same date as this bug report)

Nothing special has happened to my system since the last time I played and now, aside from windows updates. The only software I have installed since is some other games already in my steam library. It was working fine with Heart of Gold, the last time I played it so I'm not sure what has changed since then and now.

I have attempted to verify all my files on steam and they all come back as fine. (According to that anyway)

Unfortunately we are running out of ideas what could potentially causing it.

A very technical note:

The only thing we found strange in code is that the writing stream was closed manually by code rather than wrapping it in a using-statement which calls Dispose, but both _should_ be sementically the same. (Only a programmer would understand this)
It might be that in Unitys Mono (C# runtime) version this is not the same, which would be against the C# standard but we are now fishing in the dark, this would be unlikely and why would it only impact just you?

However we changed it now to use the most standard way to make sure the file stream is correctly closed after each write and there is a tiny chance that this change has an impact on his problem.

We are releasing a new minor patch very soon (expect it some time next week).

I just hope this patch brings you back to play the game, but unfortunately it's not unlikely that nothing we changed has any impact on this particular issue.

However I would say give it a try and let us know if it works again, once this patch is out.

I am sorry that we are unable to help better in this case, but this seems to be a very rare system specific issue.

Thank you for trying so many things though.

I will give it a try and yeah, I didn't see any end of statement in the output_log either. While I'm not familiar with Unity coding, I do dabble with LUA and it seemed strange to me that the code was not purged before exiting.

As for why it flags as being closed manually, maybe because the error throws up a dialog box with only one option to exit the game? That would be my only guess as I haven't had to force close it at all.

Fingers crossed for the new patch being just the switch needed to turn the game back to a working state (for whatever reason). I will let you know either way though.

I'm sorry that we weren't able to figure it out but thanks for at least trying. Some things are just beyond our control with the interactions of various programs having unforeseen effects.

Just in case it was misleading, the game is closing correctly and the end of the log looks like a normal exit.

It is just the case that this exception occurs during loading which then causes the game to force quit with an error dialogue.

The problem I was mentioning is about closing file streams, because if I file stream to a file is not correctly closed before a new write attempt to the same file happens, then this error you encounter would occur.

But we double checked the the file streams are closed on our side correctly, but it might be an oddity of Unitys special custom version of the Mono runtime, which might break the standard here.

If this unlikely guess would be true, we could indeed have fixed it by using the standard way to close the file streams rather than calling "close()" manually even if both should do the exact same thing.

I not want to get even more technical but in with a small chance we did run into an odd Unity bug, which we might circumvent with the small change we did.

Fingers crossed, but the likelyhood for this is small and I just hope it helps to get you back to play.