Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.
Sign upBuilds from past few days won't run. #14018
Comments
This comment has been minimized.
This comment has been minimized.
|
The downloads do the same thing for me. It appears to have started at 0.C-3872 (3871 is commit 492db8e). I don't know what came in the commit after 3871, but I guess it would be compiler related. The game runs when I build it with MinGW. |
This comment has been minimized.
This comment has been minimized.
|
I'm running the official 3889 right now on Windows 7 64bit without any problem for my main game. I've just tested 3882 and it works without any main issue. I was able to create a new world, a new character and loading the game with that character. |
This comment has been minimized.
This comment has been minimized.
|
Were you able to then reopen the game with that character? Like I said, 3882 worked once for me- it was the second time where the problems started. Also, is it possible this could be related to #13932 and/or #11627? Update: Official 3889 build is still doing it for me. |
This comment has been minimized.
This comment has been minimized.
|
@scorpion451 I tried 3882 again and I was again to reopen the game with my character. I doubt this is related to #13932 or #11627. Those are just build issues not problems running the game. |
This comment has been minimized.
This comment has been minimized.
|
That's the thing though, something changed around 0.C 3872, and suddenly DEP is flagging the exe as a potentially dangerous file as soon as it tries to initiate from memory. Maybe that something is how its compiling now, or is related to what was causing the compliling issue? Edit just to clarify what I mean by the DEP thing, on the ones where the flag is a weak one and it lets me temporarily disable it in Process Hacker, I can get a grand total of two CPU cycles before DEP is slammed back into place and initiates a program termination attempt. |
This comment has been minimized.
This comment has been minimized.
|
Are you all on Win 7 x64? Tried running the game as admin account? Are you using software or hardware acceleration setting? |
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
Compiling has not changed recently from my understanding. The various PR for build changes have not been merged yet.
I am on Win 7 64bit running the game with an admin account without elevated privileges. I'm using hardware acceleration. |
This comment has been minimized.
This comment has been minimized.
|
I tried running a version as admin, it opened for me, and every other version that failed is opening normally now. I was debugging for a different Cataclysm issue earlier, I don't know if that is related. |
This comment has been minimized.
This comment has been minimized.
|
It's possible that we're randomly matching the signature of something in
Microsoft's database, that happens on occasion when you have a long enough
series of versions.
|
This comment has been minimized.
This comment has been minimized.
|
Speaking of databases, I found out toggling Avast's DeepScreen option will allow me to open the game now. It's only ever been running when it looks at each new cataclysm-tiles.exe, and I realized it hasn't been popping up to tell me that it is scanning like it usually would. It spams 3 copies of the same .exe and just sits there. Apparently Avast had an update available, it appears to have fixed my specific issue. |
This comment has been minimized.
This comment has been minimized.
|
If avast decided it doesn't like the exe, there's not much we can do about
it :/
|
This comment has been minimized.
This comment has been minimized.
|
It's more like they broke their sandboxing program on older Avast versions with their new update. |
drbig
added
<Bug>
(S1 - Need confirmation)
OS: Windows
labels
Nov 15, 2015
This comment has been minimized.
This comment has been minimized.
|
Could be the issue for me as well, updating Avast. Yep- that did it. |
This comment has been minimized.
This comment has been minimized.
|
I think I've just had a friend I've been pestering to play this hit the same problem. I always have to deal with Avast derpscreening a new version on mine, and causing issues if I get impatient and attempt opening multiple times, but just sitting back and letting it do that initial screen causes no further trouble for THAT build. My friend however has it apparently going FUBAR anyway even if given enough time that Avast SHOULD be able to screen unhindered, on 64-bit Windows 7. |
This comment has been minimized.
This comment has been minimized.
|
Some instructions from an Avast user on reddit for a workaround:
|
This comment has been minimized.
This comment has been minimized.
|
Hmm. Since my last grabbed version has been Deepscreen'd already, I might update and see how well it works for MY issue, but no idea if it'll fix the issue he's having. EDIT: Yeah, that resolves Derpscreen, but still doesn't start for the other person. |
This comment has been minimized.
This comment has been minimized.
|
Has been tagged confirmation needed for nearing 6 months. @scorpion451 please re-open if you are still having the reported difficulties with a recent nightly. |
scorpion451 commentedNov 13, 2015
Windows 7 64bit, saw another person in the forums who might be having the same problem also with windows 7.
I haven't tested all of them, but the builds from the past few days (starting somewhere between 0.C 3864 and 3882) don't seem to run more than once, if that.
As in, some of them boot once after being freshly unpacked, and thereafter any attempt to run them results in them appearing in my task manager, opening a single thread, and ceasing to do anything further. No cpu usage, no i/o readings, and cannot be terminated aside from a reboot.
Takes the cake as the weirdest error I've ever seen. =/
Update: Okay, figured out what's going on, if not why: they seem to be triggering Data Execution Prevention, and getting put on lockdown. Poking with sticks to ensue.
update 2: sound of stick breaking 8[
Okay, um, so there's something pretty wrong happening here...
Using das Uber task-manager "Process Hacker" tried to kill one of those with kernel level thread halting and memory overwrites. Still there, doing nothing. Aside from crashing Process Hacker when I tried to view the adamanitum thread's properties.