Menu
▾
▴
#149 1.12.0 The editor crashes when trying to save a level
The level I was working on did contain custom textures. I made no changes to the amount of the custom textures, only tried to swap out one texture for another. The editor crashes when pressing the Save button, and does so repeatedly. Upon reloading the level, the POG is absent from the HOG archive and appears to be lost permanently.
Is the crash on clicking "Done" in the POG editor or the Save button (for the whole level) after that? It sounds like it occurs when writing the POG, otherwise there would still be something there afterwards.
You say it's repeatable? I can't get it to crash there, so my guess is it's specific to the level or your environment... hopefully the level. There are a couple options to go further with this:
1) I would need a copy of the level and exact steps to make it crash (including whether you have Expert Mode on or off and what buttons you clicked at each prompt).
2) Alternatively, if you could send the crash dump I might be able to figure something out from that. This will require a registry tweak and possibly a custom binary (but hopefully not). The registry tweak can be applied by running the file here: https://sourceforge.net/projects/d2x-xl/files/Debug/dle-crashdump-full.reg/download
The crash dump will then be saved to: %localappdata%\CrashDumps (It will probably look like dle.exe.####.dmp; you would want the most recent one if there are several)
Regarding custom binary: it's possible that I may not be able to open the crash dump due to how the debugger works. I am hoping that I can force it because I should be able to build an identical .exe. If I'm wrong, I would have to send you a new .exe (although it'll have a couple extra bug fixes :)) and you would need to use that instead.
Let me know what option you'd prefer. Thanks!
Ok, I'll just post a link to the level here. Also, I may have worded what I did in a slightly imprecise way - I meant I did absolutely nothing in regards to the POG - I just wanted to change a texture on one wall to a different one, already among the used ones of the level. Then I tried to save the level and the editor crashed for the whole level, removing the POG entirely.
Here's the level:
https://www.dropbox.com/sh/753uilbymwhyouj/AABtKJ85uq_afJXcz-xNLX0ya?dl=0
Steps to make it crash:
1. Open the level
2. Zoom in to the small hostage cell entered directly from the main hub area
3. Change the jail texture on some of the walls for the other one
4. Attempt to save. Voila.
Actually you can simply open the level - do nothing and attempt to save it, the editor will crash anyway. This didn't happen for example when I opened The Enemy Within level 23, with its many custom textures - it saved just fine.
However, I'd like to point out that the original palette still doesn't get saved along with the level - the problem I reported a while ago. The first time I opened the discussed level with the new version of the editor, the palette in the Settings tab was set to Alien1, while the level itself was made using Fire. I remember that in earlier versions of the editor the palette would change along with every level you opened to reflect the palette the level was originally saved on. Right now, Fire (the last set palette) seems to load when opening any level, until changed manually. This way you can't really know what palette the level is supposed to be using in the first place - the level just opens on the palette you last selected manually and its custom textures get somewhat distorted due to that, lossy conversion adn all. This is a really serious issue. I tried to open one of the Water levels of the original Descent 2 mission and I got an immediate crash. The same happened after I manually switched the palette to Water. Strangely enough, when trying a GROUPA level, it loaded fine, but the palette was Water anyway.
I figured it would be best to get those crashdumps, ran the registry entry and all, but the crashdumps won't appear anyway.
Last edit: Xfing 2015-01-29
Last edit: Xfing 2015-01-29
I know about the settings issue - I haven't resolved it yet, which is why bug 147 is still open. It is on my queue for next patch.
And now the bad news: I still don't get a crash saving your level. So I think the crash dump might be the most effective course of action now (either that or a game of 20 questions where I don't even know what the questions will be :)). Some things on that:
Does the crash dump folder exist on your machine? Is it just empty? Or are there other files in there but nothing from DLE?
Are you running Vista SP1 or newer (below that and it won't collect crash dumps, which would be... a problem, I'd just have to resort to trying to guess the problem)?
I've got Vista SP2, at least that's what Speccy says. Also, it seems to be the latest service pack for the system, so I'm pretty much up to date.
As for the crashdumps: there was no folder for them, I had to create it manually in the path you suggested. Even then, DLE won't generate a crashdump when closing due to a crash. Of course the registry info had been added before I tried it, so guess something's wrong with either the registry entry or my system :(
Last edit: Xfing 2015-01-30
It could be. If you know your way around regedit - check the key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps"
Is there a "DumpFolder" value there, and if so, where does it point to? That's where Windows will (try to) save crash dumps to, or at least it's the one that applies to programs like DLE.
There is more info on how this process works here, if you are interested in tinkering with registry settings: https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181.aspx
Currently my only guess on what may be causing DLE to crash is that it has something to do with the file location - but it's a long shot, because clearly it's able to open the file if it can remove the POG.
RegSZ had its value unspecified, and REG_DWORD was set to 2. I assumed that RegSZ referred to the path where the crashdumps would be saved, so I put in %localappdata%/Crashdumps (full path). Still, no crashdumps appear after crashes :(
After reversing that change, adding a DumpFolder key and typing in the path didn't help either.
Last edit: Xfing 2015-01-31
While trying to figure out what was going wrong I noticed the line "This feature is not enabled by default." and realized it might require configuring everything. Plus, I have a suspicion that the value might have been added to the wrong key.
So, I've updated the .reg file on SourceForge (http://sourceforge.net/projects/d2x-xl/files/Debug/dle-crashdump-full.reg/download) - try it again and see what happens? I'm hoping I don't have to set the default \LocalDumps values since the other application I have that configures crash reporting doesn't...
Ok, the dump worked with that new registry entry. However, the dump file is 450 MB in size. I assume it's not an appropriate size for such a file :O
obviously, there are going to be difficulties in uploading it for you to see.
Actually, that isn't out of line with what I expected. If it's too large to upload anywhere (even compressed), another option is changing "DumpType" to 1 - should make it smaller but there's less guarantee I can figure out the problem from it.
https://www.dropbox.com/s/f1oervorjz4m81d/DLE.exe.4316.dmp?dl=0
Here's the dump. It occurred when trying to save the Eris map after switching the PIG from Water to Fire. Interestingly enough, when the level opened with the PIG being Water, the level saved just fine, only after changing did the error occur. I'm beginning to think my PIG files are corrupted, might as well refresh them.
Oh, and lemme know when it's ok to delete the file, my Dropbox space is wearing thin :P
You can take it down now. It looks like most of the DLE part of the stack is very difficult to analyze thanks to, I suspect, the linker settings it was built with - but the PIG-switch crash on that level was reproducible on my end anyway, so I might have it cleaned up.
See if there are still any crashes with this binary: https://dl.dropboxusercontent.com/u/40598935/DLE.exe
(I'm still working on fixing bugs which is why it's not released yet :))
If the size of crash dumps is a problem in future, you could try either
1) Compress the crash dump with something like 7zip - the one you sent compressed to 27.3 MB which is much easier to find space for; or
2) Edit DumpType under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\DLE.exe. If you set it to 1, it will produce a "minidump" which will probably not have much level data in it, but can still be enough to diagnose many crashes and is much smaller - only around 10 MB
However, the binary is going to have to be built with symbols for the crash dump to be very useful. 1.12.0 was not, but the one I sent you a link to was. Hopefully next published version will too, we'll see :)
Checked out the new binary, and it's fantastic. Not only is the error completely gone, but the previous palette changing bug is done away with also. It finally picks up the intrinsic palette of the level every time you open one. Now with this we can work! Thanks and brilliant job :D
Thanks for helping get the information needed to fix this. As I just uploaded version 1.12.1 to SourceForge, which contains the fix, and there are no (known) remaining crash-on-save bugs with the level, I'm closing the bug.