LukeV1

Ok, created a diff: https://code.wildfiregames.com/D1274

I've got a working patch now. Just replaced WARN_IF_FALSE(SetEndOfFile(hFile)); by RETURN_STATUS_IF_ERR(SetEndOfFile(hFile)); in wfilesystem.cpp and all of a sudden everything works. Not sure if it breaks/ slows down something, but I don't think so. Don't ask me why that works, but it does work (at least for me). Didn't create a diff in Phabricator since I never used it and don't want to destroy something...

After some testing I found out that saving a file isn't the problem - the last file processed before crashing gets written and closed correctly (all of this happens in io.h). The issue is the afterwards called "wtruncate"-function (an API-call) whichs crashes without producing an error message or return value. Try and catch that line doesn't work. Unfortunately I don't know how I can prevent/print errors from an API-call... BTW: Is there any function like ENSURE(pathname.has_write_permission) ?

SVN wasn't working cause I had a local compiler issue I tackled down the problematic code even further, it has to do with the function "wtruncate" in "wfilesystem.cpp". Will take a look at that soon - at the moment it seems as if this returns a Null pointer or crashes internally, when the antivirus software is getting angry...

Im still around Actually I didn't wrote any code around the core issue. As written here, I had two problems. The first one (HWDetect) is easily solvable but that's not what you meant (it already displays an (ignorable) error message). The other one - the bad one - wasn't solved through coding, but by adding an exception path to the antivirus scanner. I might ask the G DATA Software AG for investigation, if you would like that?

Important Update: I figured out the problem: the installed antivirus scanner (G DATA Internet security) seems to block all file accesses made by pyrogenesis after a few dozen file changes in appdata subdirectories. So elexis is right - it actually is a directory permission issue - but not caused by windows When I deactivate all virus scanner services the SVN version works. Though, I'm not sure why this happens since I use exactly the same antivirus software on a few other PCs (win7 / win8.1) where the SVN version works... Seems to be a windows 10 specific "feature". Since I'm the only one affected by this I will close the ticket on track and handle the problem as solved. Thanks to everybody who helped me on this!

I think so. I'm running 0 A.D. on a single-account windows with standard admin privileges - starting pyrogenesis by choosing "running as Admin" explicitely doesn't change anything. No special rights set for any appdata folder. As mentoned somwhere above, 0 A. D. is able to save a few files to this directory before crashing - so I guess it hasn't to do anything with directory permissions (otherwise it shouldn't be able to write a file at all, right?).

opened a ticket on trac: https://trac.wildfiregames.com/ticket/4802

I'm finally coming back to the subject after having a few days off Now I've checked that size got a valid size (>> 0), pathname got a (seemingly) valid name and that the fileContents Pointer actually points to something. At the crash all values seemed normal (comparing to all other converted files before)... What can I do next - or where should I probably take a look at?

Already did that. But since it crashes always on a different file it's hard to tell how big size should be.. I'll append a Screenshot from a random debug run.

I've found debug_printf, which works pretty decent, so no need of cout anymore.. Now I got the line inside CreateFile (part of vfs.cpp) where it crashes: RETURN_STATUS_IF_ERR(realDirectory->Store(name, fileContents, size)); I've already checked that size is > 0 and name isn't empty. Both got believable values at the error. Have no clue how to check fileContents, though. Could the crash output (wsysdep.cpp(358): Assertion failed: "charsWritten < max_chars") mean that size was too big for some reason?

@stanislas69 where can I watch the output of std::cout ? I wanted to insert a few debug texts in the ("lowlevel") file vfs.cpp where I can't use LOGMESSAGE but I don't find the messages printed by cout...

Now I've got the extact line where the program crashes: it is vfs->CreateFile(xmbPath, writeBuffer.Data(), writeBuffer.Size()); in the function CXeromyces::ConvertFile of CXeromyces.cpp Is there any realistic chance that these parameters are faulty (e. g. overflow?) or the function is doing something wrong in a special case?

Disk Space: around 300 GB free, running as Admin didn't change everything, chkdsk found nothing to complain about on any drive. This problem is getting worse with every step we make to find it

Writing the cache files is the problem. When I'm deleting the cache the game crashes right on startup (while loading the menu) a couple of times - but then it got everything cached and at least the menu works. What I figured out so far that the crash isn't caused by any specific file. It seems as if it crashes after a certain numer of written bytes... I've checked the cache folder, no special permissions set (0 a. D. is capable of writing a few files there but then suddenly crashes..)