The Dink Network

I found a crash to desktop bug in FreeDink V109.6 that manifests itself in "Friends Beyond II: Branches of Destiny ver 2.0"
I should note that the bug does not appear in FreeDink V108.4.

How the bug manifests:
- Running FreeDink V109.6 in Windows 10 (Version 2004)
- In FB2, on screen 509 there are some stairs, (south west of the save machine closest to the eastern cave)
- If you go down these stairs in FD V109.6, the game fades to black as you begin warping, but then crashes to desktop
- The error code is -1073741819 or 0xC0000005

To go in more detail, the Windows Event Viewer is telling me the following:

Faulting application name: freedink.exe, version: 1.0.8.0, time stamp: 0x00000000
Faulting module name: msvcrt.dll, version: 7.0.19041.546, time stamp: 0x7f567a50
Exception code: 0xc0000005
Fault offset: 0x00088d4a
Faulting process ID: 0x3438
Faulting application start time: 0x01d7118a50a21032
Faulting application path: C:\Games\Dink Smallwood\gnu_freedink-109_6\freedink.exe
Faulting module path: C:\WINDOWS\System32\msvcrt.dll
Report ID: 56beba58-fb63-4fe8-8c15-36fd798c3ed8
Faulting package full name: 
Faulting package-relative application ID: 

I checked the FB2 game data, and there doesn't seem to be anything out of the ordinary in the warping destination. No scripts getting executed as far as I can tell, just a regular warp.

Also as I noted at the beginning, this doesn't manifest in the original Dink V108 or FreeDink V108.4

I also messed around with a Virtual Machine running Ubuntu 20.04 and FreeDink V109.6 crashed there too! I should have a big fat 15MB crash log there that I could email to someone if they think there's something useful to be learned from it.

Another interesting and possibly related piece of information, is that someone over on discord said they were trying to run Free Dink V109.6 on Windows XP and it would crash at launch, but the error code in his event viewer was the same as mine, 0xC0000005

I think that's all I got for now. I tried building Free Dink V109.6 myself for Windows from Ubuntu, but I haven't managed to get the build process to work correctly yet.

Since currently FreeDink has no maintainer, it's unlikely this will get fixed in the near future. Kind of a shame.

How weird. It's like there's something FreeDink doesn't like about screen 116 itself in that dmod. It crashes on load, even after replacing it with another screen, and vice versa that screen works fine if you copy it elsewhere. Actually, the game still crashes there after deleting map.dat.

Maybe some kind of corruption in dink.dat? Sadly, I don't know how to make those .dat files readable, although there should be a few people around who know more about that.

I'd say your best bet is to play the game in FreeDink V108.4.

Other than that, you can try your hand at removing things from screen #116 until it works. :-} If you can tell us what can be removed that will allow it to work, maybe someone here could "fix" the problem for the version of the Dink engine you prefer to use.

Hmm, perhaps, but at the same time, the fact that it doesn't crash in V108.4 or the OG game makes me think it's probably not the DMOD's fault.

Looking at the Free Dink changelog, it seems a lot has been rewritten...

The main things that stick out to me are:
- Move from C to C++ : this could have accidentally introduced some obscure bug somewhere I suppose?
- Rewrite graphics/sounds/inputs against SDL2 : this seems like another possible major change that can have some obscure unforeseen consequences related to loading/unloading screens

I kind of want to dig into it myself, but I'm but a poor .NET programmer and I am unfamiliar with compiling big projects with complicated dependencies... And building for Windows seems especially tricky with it. I messed with it for a few hours and didn't even manage to resolve the SDL dependencies.

Although, a thought just occurred to me right now. I had the same issue manifest under Ubuntu, so I should just try building it for Ubuntu in the first place, since I might have less issues with that. Then I can start poking around the code and see what happens... There's a 99.9% chance it will take me forever to understand how the engine works and I'll just give up, but hey, at the very least it could be an interesting learning experience.

One hint: the exception 0xc0000005 is an access violation, which is roughly equivalent to a NullReferenceException in .NET.

Of course, those are much harder to debug in C/C++ because they can happen for many tricky reasons (like buffer overflows, corrupt pointers, bad pointers, etc.)

The fix is simple.

Open the dmod in WINDINKEDIT, and save the dmod (file >> save) without changing anything.

You will warp in fine without a crash.

(I just confirmed it myself, crashed before I did it, saving fixed the crash)

The fix is simple.

Open the dmod in WINDINKEDIT, and save the dmod (file >> save) without changing anything.

Great workaround Robj!

I found that in my 109.0 exe it worked as intended. What exactly is WinDinkEdit changing when it re-saves MAP.DAT that makes 109.6 able to process the warp as expected? I'll get out the hex editor later and have a look, but it seems awfully strange that this somehow changes something. In my experience, WinDinkEdit seems to terminate bytes differently to regular (Free)DinkEdit but that's all I can think of at this stage.

Odd, the WINDINKEDIT save trick didn't work for me.

Tried WinDinkedit V1.4 Beta 2 and WinDinkedit Plus V2.3.2 and neither did anything for me.

I used the latest version windinkedit plus 2. Then I ran the dmod and warped to the screen and it didn't crash. Weird.

Windows 10. FreeDink 109.6.

Strange that it worked for me but not you. That has me baffled.

I can try sending you my fixed map.dat after the save trick, if that doesn't work then there is some weird reason why you're freedink is reading it differently to mine and crashing?

If it does work, your windinkedit plus2 is saving in a different way.

Either scenario makes no sense.

Good idea, so can you private message me the link to your map.dat or something?

Done. Pm'ed you.

I included both the map.dat and dink.dat after I re-saved the dmod in windinkedit.

You need both, I tested on a fresh install of FB2 - if you only include the resaved map.dat, the game starting screen glitches the duck out.
They must work in conjunction or something. I dunno.

As a matter of fact, for anyone else wanting to fix it, here's the two files that indeed work (tested under fresh install). If they work for me but don't work for someone else, that would just be illogical and would be baffling.
Maybe I'll just upload them as a patch if they are comfirmed working, for future downloaders.

Remember, copy both .dat files.

FB2 fixed map.dat:
map.dat

FB2 fixed dink.dat:
dink.dat

Maybe I'll just upload them as a patch if they are comfirmed working, for future downloaders.

Excellent idea!

Thanks for you are uploads Rob. I went in with a hex editor and compared the Dink dats. In the original, the screen index starts counting from 164 whereas yours starts counting from screen number 1. I'm guessing that WinDinkEdit reads every map screen upon loading and sorts Dink.dat and Map.dat into sequential order. I have no idea what's going on in the engine though that's causing it to freeze. It seems somewhat strange as well considering that this would be commonplace with D-mods made with DinkEdit which would be just about all of them prior to a certain date.

Interesting.. so that means there *might* be freeze errors in other dmods using 109.6 as well?

Well.. patching them all this way would be quite tedius, especially since all I did was open and save in windinkedit, almost doesn't seem worth it to go searching for any faulty dmods and try to patch them all this way.

Whatever bug has been introduced between 109.0 and 109.6 is bound to affect just about every other D-mod that is doing whatever FB2 is doing when it warps. At this point, I don't know what the actual problem is, but considering that this is a 109.6-specific issue, I would advise people to attempt to use a slightly older Freedink version to get around it.

Yeh, with all the different Dink Smallwood engines/version that have there own little quirks and stuff, I tend to just keep multiple executables in my Dink Smallwood folder and switch between them in DFarc. It's the best way to go. Experience a freeze, switch freedink versions.

Too bad Beuc isn't around anymore to whip up a quick fix for stuff like this but oh well, it's manageable.

Besides, if people want to fix it, it's as simple as opening windinkeditplus 2 and resaving the dmod, then it works in all versions. Although I'm not sure why that didn't work for OP.

EDIT:
Weird thing is, it only happens in particular situations, when there are a certian amount of used screen or something.. I dunno...

I tested by editing another Dmod(which was only ever made in Dinkedit) and copied those two screens 509, 116 and they warped fine. Same scenario, different dmod, only difference is, the dmod has less used screens. So it might be a bug that won't affect many dmods anyway.

Ok, so I tried your files, they worked as expected.

I also found out why mine didn't work. Apparently both my WinkDinkEdits are broken in some way and I can't actually save the dmod data...

I tried adding a screen to one of the unused slots and saved. Then I closed the dmod in the editor and opened again. The change I had made had not been saved. Checked the file modify date, that also was unchanged. Weird... Suppose it's some weird windows 10 issue.

Ok well that makes things easy then. No need to play in different versions, just re-save in windinkedit for the fix.

Since this is the only dmod it's been found to effect so far, and casual players may not ever download windinkedit due to not being interested in dmod creating, I'll just upload these dat files as a patch later today.

Yeah, most likely, it's a combination of some very specific circumstances that cause this to happen, since I haven't experienced it anywhere else so far, not even within the same dmod. So it's unlikely for it to be an issue for other dmods.

Ok, courtesy of our king, he has updated the dmod to a new version, which includes the fixed .dat files I sent to him, so anyone else in future won't have this issue.

I just updated since i was playing ffb2 and could NOT enter the stairs in the west, now i know that there is a fountain!!
meanwhile i have BOTH the flame and the sword and BOTH cavvictims are saved and thanked me. they stayed in the cave while they thanked me aswell in their home. after rewaching 'more level' did finaly changed. there are no longer in the caves.
maybe now it has use to slay those monsters that keep come back so the fairy can stop telling me about them ....
but i did have a zip off water now !!

There's also a similar error in FB3.

I've sent the fixed package to redink1 for update, but it isn't up yet.

For now, here's a zip file with the map.dat and dink.dat.

As you know FB3 has multiple maps, these are for the FIRST map, so just extract them directly into the FB3 directory and overwrite.

FB3 Dat files

Hi,
do i see it correct that the 'bug' is infact compatibility between old and new versions?
i once tried to look at FB2 source but it seems to need its own font in the .d or some alike.
I am pretty new to c anyway. If i comment to storyline that still does not work properly for me, then i should jump to FB2 i supose.

>do i see it correct that the 'bug' is infact compatibility between old and new versions?
Something like that. The new version (FreeDink 109.6) reads something incorrectly from files saved with old dinkedit.

>i once tried to look at FB2 source but it seems to need its own font in the .d or some alike.
You need to decompile .d files into .c files. Get something like WinDinkEditPlus from here, https://www.dinknetwork.com/file/windinkedit_plus_2/
After you open the dmod in it, go to Tools -> Decompress Scripts (.d -> .c)