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..)

Unfortunately template_unit_hero.xml is a false positive. I've inserted a LOGMESSAGE output and pyrogenesis.exe crashes at a different xml file each time. (BTW: the absolute path to template_unit_hero.xml is 107 chars long, there are no spaces oder special characters). So I guess it isn't related to any special file but to some problem with memory management I have no clue what to do next...

I've got it - at least I think so. This was the last time the breakpoint was hit before the buffer overflow exeption popped up. The file is "template_unit_hero.xml" (see screenshot). I figured that out manually by making a screenshot and clicking countinue each time CXeromyces::Load was called which seemed to happen a million times. So I was wondering if I could insert a simple std::cout << *filename in CXeromyces::Load to print all called files to the console? This would be a lot faster since I would know the last file printed was the broken one. Is that possible? As I said I'm new to such large scale projects but I've attended a C/C++ course at university, so I know at least a few basics..

Here you go: call stack of release version r20160 stack_r20160.txt

Ok, did so. Updated to r20159 and used the debug version inside VS13 stack.txt

Finally got permission to install VS2013 and WinDbg I've updated my svn version to r20157 and followed the instructions on https://trac.wildfiregames.com/wiki/DebuggingOnWindows I've appended the file since the service mentioned on the wiki site is down. As I am absolutely new in debugging i have no clue what to do next - so if I should test/upload/change anything let me know. And: thanks to everybody who helped me so far! I know at least something about debugging - it's quite time consuming. So thanks for support! WinDBG.txt

@stanislas69 I could generate a dump file of the crash manually with procdump. Would this help?

After several tests I would split the initial problem in two parts: HWDetect error, which is somehow caused by "numa.h". This error can be ignored and the game works then. Workaround to avoid the error handler window: comment out line 313-315 of HWDetect.cpp. Game crash when loading a map / starting a game. This error is more severe because it just breaks everything. No crashlog.txt or crashlog.dmp gets created So I will irgnore the HWDetect problem for now since its basically ignorable Regarding the starting game crash I found out another strange thing. As written in an above post the Alpha 22 Release works (besides of the HWDetect thing). But EXACTLY the same svn version (r19921) doesn't work. I've appended a screenshot. But this versions should be completely identical or I am wrong?

wrote some wrong information in the last post, edited that. Sorry. Official Alpha 22: one message in interestinglog (after closing the game): game exited succesfully with 0 errors (while still creating a crashlog.txt!) svn/custom: the interestinglog is completely empty (0 kb size) - it even don't show the caption.

Crashing the came is absolutely no problem I've retested the svn (head version, as of now) and my custom build, both crashing each time and not producing any *.dmp file. I've attached a screenshot of "%localappdata%\0ad\" as proof. BUT: I found out something different. If I start the official Alpha 22 release version, I get the error as written in the first post with the crashlog uploaded in the 5th post. But if I hit continue then, the crash handler window disappears and then reappears showing exactly the same error. If I press continue again the game starts and works flawlessly (loading and simulating maps, just everthing)! Sorry that I wasn''t coming up with the idea of ignoring errors earlier EDIT: Anyway, if I try this procedure with r19876, r19921 the current version (r20096) or my build (custom r20096), the program crashes if I try to start a game (showing the windows message "this program has stopped working"). Now I really wonder what is going on...

Where should this file be located? Checked "%localappdata%\0ad\", but there is no *.dmp file. Just crashlog.txt, interestinglog.html, mainlog.html and (since I've commented out the _numa lines) system_info.txt.