We found the root cause.
It was your prisoners which all together tried to find lair in a loop but failing obviously.
(You can test this by getting a rid of your prisoners and the lag will go instantly away)
They simply should not do this as it can never succeed and we prevented them to do so in the past.
However this check was overrun by a recent change, so it is indeed a regression.

We will get this lag issue fixed for next patch.

In my test the lag is instantly gone if prisoners only try to find rats when they are hungry and do query for nothing else.

Thanks a lot for providing a save game allowing us to quickly find the cause of these lags.

Cheers

Seems your save game does indeed show lag.

This might be some regression, with the empire patrols failing to find a sleeping place in a loop after the entire map is revealed.

But we will have to investigate a bit deeper where this comes from exactly.

Thanks for providing this save game which shows an issue we can profile to find the cause.

We are getting back to you once we know more.

Hello again,
so the output_log was uploaded directly after having the lag without restarting the game?

If yes, then I can at least say that no error was occuring frequently which would explain the lag.
I am gonna take a look at your save file.

What Biervampir is trying to say:
We have an hard time to reproduce this problem. 
Do you have any pointers how to trigger it @XtraPEG?

Did you do anything different than the steps Biervampir tried?

Hello Mateusz Saczka,

in such cases it is always useful to upload an output_log (to see if any errors did occur frequently) and a save game when the game did lag (to reproduce the issue).
Can you upload these two to make it easier to investigate?
Here is how to do that:
http://brightrockgames.userecho.com/forums/2-war-for-the-overworld-knowledge-base/topics/118-how-to-submit-a-bug-ticket/

Cheers

Thanks for keeping us updated.

I am very happy to see you back in the game!

This Windows update is for the Flash Player and the game does not use any Flash, so this _should_ be unrelated.

The issue you did run into seems to be very system sepcific and I doubt there are other users which run into this.

At least we got no related reports.

Even if you are programmer, you keep dealing with black boxes which allow no insight and only limitted control.

The Windows operating system is such a black box and we can not really know which screw got turned fixing this strange file stream sharing violation, but seems what ever locked Options.txt did finally stop doing so.
I highly supsect an internal Wwindows issue causing this problem.

I am just happy it stopped and I hope it will never come back so you can keep playing.

However let us know if you encounter any issues with the game in future.

I wish you fun playing!
Cheers

Thanks you for the kind words, we worked hard to make this game a reality.
But it's a shame to see someone who has all the required specs unable to play the game.

I hope we'll get this sorted soon but this issue looks extremely strange.

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.

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.