Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[NCommander]

The crash plot thickens. Using g_src as a reference, I caused DF to call exit() well before it fires up the mainloop.

To Reproduce:
 * Turns GRAPHICS on
 * Point DF at a non-existing file

This causes us to die very early in textures.cpp before the main loop fires. I'm 98% sure at this point the crash on exit is caused by one of DF's dependencies and not DF itself. My gut wants me to suspect fmodex.dll, but it could be any of them due to the mscvrt mismatchs. I may try recompiling the ones I can tomorrow or later tonight depending on how I'm feeling. Fortunately, all of these are either recompilable, or have replacements in one of the ports.

[StrikaAmaru]

[...] now after closing the program it pops up a "df_xp_test.exe has encountered a problem and needs to close." generic windows error message. Very similar to Random_Dragon's problem.[...]

... Now that you mention it, I remember getting that error on XP when closing DF too, when I was playing on XP about 2 years ago. I've gotten used to ignoring it.

I just got the same behaviour myself, on a Win Server 2012 (work environment, obviously, so this is the most testing I'm doing atm). Used the 'Windows (no sound)' zip. Will see how it behaves on playthrough in about 9 hours.

[Toady One]

I haven't experienced the exit crash myself (or at least any visible sign of it), so I can't jump in on the test/fix train with this one, unless I somehow can with the magic information you all possess.

I have the 64 bit DF running!  Without SDL so far, but I was able to share saves back and forth between 32 and 64 without immediate issues.  There are a few error logs, but if the SDL version also runs, maybe this won't take forever.  Then we can play with linux...  where I might need a new GCC?  I don't even remember how that worked, but I have a giant PM to read about that.

[Random_Dragon]

I have the 64 bit DF running!  Without SDL so far, but I was able to share saves back and forth between 32 and 64 without immediate issues.

Oooh, nice. o.o

And now that both my desktop and laptop have stopped doing the exit thing, I'm even more stumped than you are.

[lethosor]

This causes us to die very early in textures.cpp before the main loop fires. I'm 98% sure at this point the crash on exit is caused by one of DF's dependencies and not DF itself. My gut wants me to suspect fmodex.dll, but it could be any of them due to the mscvrt mismatchs. I may try recompiling the ones I can tomorrow or later tonight depending on how I'm feeling. Fortunately, all of these are either recompilable, or have replacements in one of the ports.

I was away for a few days, so I missed some of this, but just to clarify, is the issue that some libraries were compiled against MSVC 2010's runtime library? In that case, mifki, wouldn't it still be necessary to distribute the old one (or would they "fall back" to the newer msvcrt runtime library somehow)?

[Chase]

I haven't experienced the exit crash myself (or at least any visible sign of it), so I can't jump in on the test/fix train with this one, unless I somehow can with the magic information you all possess.

I have the 64 bit DF running!  Without SDL so far, but I was able to share saves back and forth between 32 and 64 without immediate issues.  There are a few error logs, but if the SDL version also runs, maybe this won't take forever.  Then we can play with linux...  where I might need a new GCC?  I don't even remember how that worked, but I have a giant PM to read about that.

Can we expect a halt on 32 bit DF once 64 bit is standard?

[Random_Dragon]

Can we expect a halt on 32 bit DF once 64 bit is standard?

Heresy. D:

[LordBaal]

I would rather that, but given there's still plenty of people with 32 OS I think Toady will opt to support 32 bits longer.

[Random_Dragon]

I would rather that, but given there's still plenty of people with 32 OS I think Toady will opt to support 32 bits longer.

I for one fully intend to run my 32-bit Windows 7 into the ground. >.o

[NCommander]

I haven't experienced the exit crash myself (or at least any visible sign of it), so I can't jump in on the test/fix train with this one, unless I somehow can with the magic information you all possess.

I have the 64 bit DF running!  Without SDL so far, but I was able to share saves back and forth between 32 and 64 without immediate issues.  There are a few error logs, but if the SDL version also runs, maybe this won't take forever.  Then we can play with linux...  where I might need a new GCC?  I don't even remember how that worked, but I have a giant PM to read about that.

Yay on 64-bit Windows. With luck everything goes smoothly . On Linux, it shouldn't be too hard to get a 64-bit build though to be fair, I have no idea how you currently compile DF on Linux or Mac OS X.

At this point, given my debugging, I'm fairly sure the crash is being caused by the fact DF uses FMOD EX on Windows. C++ ABIs are incompatible across visual studio releases. Legacy dodged this bullet since the old fmod.dll only has a C API. Is it possible we can get a test binary that has FMOD EX disabled/removed to rule it out one way or another? Looking in g_src, there's a preprocessor flag (NO_FMOD) that should disable it.

I'll send you a PM if that's alright on AppVerifier which can flush out the crash; I couldn't reproduce it at first either. It should have been installed along with Visual Studio 2015.

[Max™]

The poll on bitness suggests that 3% (at most) run on a 32 bit OS, which goes along with my hunch that literally nobody is using a 32 bit CPU, just a few weirdoes like our chaotic firelizard are sticking with a 32 bit version of an OS for some reason.

Spoiler alert: 32 bit W7 is already ran into the ground. :p

[Random_Dragon]

The poll on bitness suggests that 3% (at most) run on a 32 bit OS, which goes along with my hunch that literally nobody is using a 32 bit CPU, just a few weirdoes like our chaotic firelizard are sticking with a 32 bit version of an OS for some reason.

Spoiler alert: 32 bit W7 is already ran into the ground. :p

Mostly because some of us derps happen to have got a computer that came with Windows 7 64-bit, but not enough RAM for it. :V

[Toady One]

I might have to ditch FMOD EX anyway since I don't have a 64-bit version of FMOD EX (the link dies since fmod.h uses a hack to ensure 32 bits which doesn't work on 64 bits, possibly among other things -- trying to patch it up on a lark, but will probably have to fall back to old fmod).  I haven't looked at linux yet so I don't even remember why we were using it to begin with (I have some linux stuff in the fmod folder on the windows computer, but I don't remember if we ended up using OpenAL instead or whatever).

edit: or maybe it's worse than that.  I'm getting a new group of linker errors for SDL...  yeah, zlib and SDL aren't working either.  It looks like the legacy version of fmod and zlib are fine, but the new ones are 32 only.  I assume my SDL is 32-bit specific as well.

[polartechie]

FIXED

Hello, I'm also getting the Error "VCRUNTIME140.dll is missing"

I reinstalled C++ Redist but no change. I verified that that dll is in my system32, and I even tried renaming that dll to all uppercase like the error refers to with no change in that error.

I downloaded the two test .exe's found here, but then those produce the error "fmodex.dll is missing"

After installing fmodex.dll from one of those dll sites, it gets the same error.

Also tried running all versions as administrator with no changes?

Edit: Forgot to mention I'm running Windows 7 Pro 64-bit

Solution was replacing the executable at the top of the game folders with:
http://bay12games.com/dwarves/redist/Dwarf%20Fortress.exe

[NCommander]

I might have to ditch FMOD EX anyway since I don't have a 64-bit version of FMOD EX (the link dies since fmod.h uses a hack to ensure 32 bits which doesn't work on 64 bits, possibly among other things -- trying to patch it up on a lark, but will probably have to fall back to old fmod).  I haven't looked at linux yet so I don't even remember why we were using it to begin with (I have some linux stuff in the fmod folder on the windows computer, but I don't remember if we ended up using OpenAL instead or whatever).

Linux uses OpenAL which is also available for Windows; if it can't find OpenAL, it gracefully disable sounds and keeps chugging. That being said, the OpenAL code in g_src does dymsym; that will have to be rewritten for Windows to use LoadLibrary()/GetProcAddress() ... or just linked in.

For your sanity, it may be worth standardizing to one sound library.

Also, on the topic of the runtime, here's what will probably fix it permamently: Go to "C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86", copy and paste everything, and throw it into the DF folder. I can't test it easily, but that's all the files for the VC15 runtime. I'll post a zip in a moment.

EDIT: For anyone who wants to test or has runtime errors, grab http://dffd.bay12games.com/file.php?id=12184, and extract that zip into the same folder that you have DF 0.43.04 in.

EDIT 2: Here's the license from Microsoft on redistributing the DLLs in the runtime: http://go.microsoft.com/fwlink/?LinkId=524842