Updates on the way.
Moderators: BAgate, drool66, Aswan jaguar, gmzombie, stassy, CCGHQ Admins
Re: Updates on the way.
by quatrocentos-e-vinte » 02 Jun 2015, 23:49
Just to try to shed some more light... I've checked my event log and the Shandalar.exe errors I was getting initially were access violation errors (0xc0000005), so whatever the problem is, it's different from the problem I had. Interestingly, my reports always point out the culprit module (either shandalar.dll or shandalar.exe), while Teraunce's don't.
TBH, I still believe the problem could be AV-related (since debuggers and sandboxing mechanisms can trigger an exception of the 0xC000041D type), so (assuming you trust Korath and the other Shandalar devs), I think you really should try turning off Comodo temporarily, to see if that's the problem.
Regarding ASLR... I doubt it is being applied to Shandalar.exe, but you can check using Process Explorer (link in Korath's comment): for each running process, you'll have a column named "ASLR" that tells you whether the OS applied it to the process or not.
TBH, I still believe the problem could be AV-related (since debuggers and sandboxing mechanisms can trigger an exception of the 0xC000041D type), so (assuming you trust Korath and the other Shandalar devs), I think you really should try turning off Comodo temporarily, to see if that's the problem.
Regarding ASLR... I doubt it is being applied to Shandalar.exe, but you can check using Process Explorer (link in Korath's comment): for each running process, you'll have a column named "ASLR" that tells you whether the OS applied it to the process or not.
- quatrocentos-e-vinte
- Programmer
- Posts: 65
- Joined: 08 May 2015, 21:04
- Has thanked: 36 times
- Been thanked: 42 times
Re: Updates on the way.
by Teraunce » 03 Jun 2015, 00:29
Yeah, about that. I generally have auto-sandbox off. And I'm not sure how I'd attach process explorer to Shandalar.quatrocentos-e-vinte wrote:Just to try to shed some more light... I've checked my event log and the Shandalar.exe errors I was getting initially were access violation errors (0xc0000005), so whatever the problem is, it's different from the problem I had. Interestingly, my reports always point out the culprit module (either shandalar.dll or shandalar.exe), while Teraunce's don't.
TBH, I still believe the problem could be AV-related (since debuggers and sandboxing mechanisms can trigger an exception of the 0xC000041D type), so (assuming you trust Korath and the other Shandalar devs), I think you really should try turning off Comodo temporarily, to see if that's the problem.
Regarding ASLR... I doubt it is being applied to Shandalar.exe, but you can check using Process Explorer (link in Korath's comment): for each running process, you'll have a column named "ASLR" that tells you whether the OS applied it to the process or not.
Edit: why do I keep reading Process Explorer as Princess Explorer?
Re: Updates on the way.
by Teraunce » 03 Jun 2015, 02:11
Here's the program Dump Korath. Process Explorer was useless and Cheat engine didn't work. The Dump was generated with Procdump using the -ma -64 -x switches.
Warning: The Dump is contained in an ultra-compressed 7-zip file. Be prepared to have 2 GB free of HDD space.
Warning: The Dump is contained in an ultra-compressed 7-zip file. Be prepared to have 2 GB free of HDD space.
- Attachments
-
Shandalar.exe_150602_212539.7z.zip- Shandalar Dump 7-zip inside is containing an almost compression-bomb
- (3.82 MiB) Downloaded 410 times
Re: Updates on the way.
by quatrocentos-e-vinte » 03 Jun 2015, 02:15
I hate to sound repetitive but it's not just the "sandboxing" feature that can be interfering... Comodo (among other protections) also has protection against shellcode injection/buffer overflows. What Korath describes (shandalar.dll rewriting shandalar.exe during runtime) is the exact type of thing that this type of protection is supposed to protect against (basically, it protects against "data execution", like DEP, though possibly through other means). You can try to whitelist Shandalar.exe from the "shellcode injection protection", since Comodo seems to allow that. It might help.Teraunce wrote:Yeah, about that. I generally have auto-sandbox off. And I'm not sure how I'd attach process explorer to Shandalar.quatrocentos-e-vinte wrote:Just to try to shed some more light... I've checked my event log and the Shandalar.exe errors I was getting initially were access violation errors (0xc0000005), so whatever the problem is, it's different from the problem I had. Interestingly, my reports always point out the culprit module (either shandalar.dll or shandalar.exe), while Teraunce's don't.
TBH, I still believe the problem could be AV-related (since debuggers and sandboxing mechanisms can trigger an exception of the 0xC000041D type), so (assuming you trust Korath and the other Shandalar devs), I think you really should try turning off Comodo temporarily, to see if that's the problem.
Regarding ASLR... I doubt it is being applied to Shandalar.exe, but you can check using Process Explorer (link in Korath's comment): for each running process, you'll have a column named "ASLR" that tells you whether the OS applied it to the process or not.
Edit: why do I keep reading Process Explorer as Princess Explorer?
Otherwise, another (more annoying) option would be to install VirtualBox, get Windows working in a virtual machine (without any AV), install Shandalar.exe there and see if it works then.
Regarding ASLR... I checked on my computer, and Windows doesn't seem to activate ASLR on Shandalar.exe (see https://i.imgur.com/vrSIF7x.png). Don't know if that helps or not...
Either way, good luck.
- quatrocentos-e-vinte
- Programmer
- Posts: 65
- Joined: 08 May 2015, 21:04
- Has thanked: 36 times
- Been thanked: 42 times
Re: Updates on the way.
by Teraunce » 03 Jun 2015, 02:31
Yeah I have the shellcode protection disabled as well. It's disabled by default.quatrocentos-e-vinte wrote:I hate to sound repetitive but it's not just the "sandboxing" feature that can be interfering... Comodo (among other protections) also has protection against shellcode injection/buffer overflows. What Korath describes (shandalar.dll rewriting shandalar.exe during runtime) is the exact type of thing that this type of protection is supposed to protect against (basically, it protects against "data execution", like DEP, though possibly through other means). You can try to whitelist Shandalar.exe from the "shellcode injection protection", since Comodo seems to allow that. It might help.Teraunce wrote:Yeah, about that. I generally have auto-sandbox off. And I'm not sure how I'd attach process explorer to Shandalar.
Edit: why do I keep reading Process Explorer as Princess Explorer?
Otherwise, another (more annoying) option would be to install VirtualBox, get Windows working in a virtual machine (without any AV), install Shandalar.exe there and see if it works then.
Regarding ASLR... I checked on my computer, and Windows doesn't seem to activate ASLR on Shandalar.exe (see https://i.imgur.com/vrSIF7x.png). Don't know if that helps or not...
Either way, good luck.
Re: Updates on the way.
by stassy » 03 Jun 2015, 03:22
Unfortunately those days a lot of AV and firewall are adding "features" that bug a lot of programs, I had to remove everything but windows 7 own firewall to use them properly.
- stassy
- Moderator
- Posts: 5274
- Joined: 25 Feb 2009, 07:06
- Has thanked: 471 times
- Been thanked: 337 times
Re: Updates on the way.
by Korath » 03 Jun 2015, 03:45
gdb can't deal with the dump file. windbg can, but it is far and away the horriblest debugger I've ever had the misfortune to deal with.
You're crashing during startup due to a missing or unopenable dll. I think it's comctl32.dll, but practically nothing else on Windows would work if that didn't.
You're crashing during startup due to a missing or unopenable dll. I think it's comctl32.dll, but practically nothing else on Windows would work if that didn't.
-
Korath - DEVELOPER
- Posts: 3707
- Joined: 02 Jun 2013, 05:57
- Has thanked: 496 times
- Been thanked: 1106 times
Re: Updates on the way.
by Teraunce » 05 Jun 2015, 04:19
That is strange korath. And if you know a better crash dumper please do tell me. It crashes too fast for process explorer and I was barely able to pause it with Cheat Engine.Korath wrote:gdb can't deal with the dump file. windbg can, but it is far and away the horriblest debugger I've ever had the misfortune to deal with.
You're crashing during startup due to a missing or unopenable dll. I think it's comctl32.dll, but practically nothing else on Windows would work if that didn't.
Re: Updates on the way.
by Teraunce » 05 Jun 2015, 04:22
When will you people read what I type!? Its not the AV and I know it isn't because I turned it off. So stop suggesting that's the problem. This post is 2 days late because you were making me mad.stassy wrote:Unfortunately those days a lot of AV and firewall are adding "features" that bug a lot of programs, I had to remove everything but windows 7 own firewall to use them properly.
Re: Updates on the way.
by Korath » 05 Jun 2015, 05:15
I don't know a better dumper, no, short of installing cygwin, which I don't recommend. But it wouldn't help anymore at this point anyway.
The way to definitively track this down is to install Microsoft's debugging tools (about two thirds of the way down this page), turn on library tracing with gflags as described here, and start the program under windbg or cdb (both included in the debugging tools package). It's a lot of hoops to jump through, though.
Dependency Walker may or may not isolate the problem, but it's a lot more user-friendly. I've had positive experiences with it in the not-so-recent past.
The way to definitively track this down is to install Microsoft's debugging tools (about two thirds of the way down this page), turn on library tracing with gflags as described here, and start the program under windbg or cdb (both included in the debugging tools package). It's a lot of hoops to jump through, though.
Dependency Walker may or may not isolate the problem, but it's a lot more user-friendly. I've had positive experiences with it in the not-so-recent past.
-
Korath - DEVELOPER
- Posts: 3707
- Joined: 02 Jun 2013, 05:57
- Has thanked: 496 times
- Been thanked: 1106 times
Re: Updates on the way.
by Korath » 08 Jun 2015, 00:22
I made an honest effort to find the select-multiple-target, or just select-multiple-anything, cards I mentioned here. It turns out, though, that constructing a regex to find them without it finding every instance of "draw two cards" and so on is suprisingly difficult, so I've gotten a bit distracted.
These cards are complicated by effects like Sorceress Queen's, which change their base power and toughness. Nightmare is very different from a card that reads "Creature - Nightmare Horse 0/0
. Flying. Nightmare gets +1/+1 for each Swamp you control." - Nightmare, as printed, turns into 0/2 when targeted by Sorceress Queen, while the hypothetical card would be (number of swamps)/(number of swamps + 2).
The way this implementation of Magic works is to compute power and toughness at the moment each is needed, not to go through each card, figure out what both its power and toughness should be, record that, and try to figure out when they'd be different. (In practice, they're recomputed very frequently, if for no other reason than for display to the screen; and there's an optimization that skips recomputation in favor of cached values most of the time. But never mind that.) This prevents the game from going through the all the layers and substeps to find power and toughness detailed in rule 613. The relevant ones are:
7c and 7d can be safely combined, since they only add to or subtract from the current power or toughness value, and together they account for well over 99% of effects.
If 7a or 7b or 7e were more common, it would make sense to dispatch separate events for them. That's still not such a bad idea; there's plenty of triggers that only get checked for if some card on the battlefield is flagged to indicate it might respond to them. (That's what the columns from "Flags: Special Code When Controlled" through "Flags: Martyr" in ct_all.csv do, for example). But MicroProse instead decided to compute them all in one pass with EVENT_TOUGHNESS and EVENT_POWER, and got it working correctly; but their implementation is horribly complex. It requires a separate effect card ("AsteriskFX") to set the power or toughness of the */* creature instead of letting the creature card do it itself, and each effect that changes base power or toughness ("PiggyFX" - you can't make this stuff up) has to search for both AsteriskFX and any other PiggyFX's attached to the creature and flag them all as inactive. This turned out to be very easy to get wrong when we started adding similar effects in Manalink; and I expect that */* creatures will still be broken there for either Sorceress Queen or for Mirrorweave, one or the other.
Turns out there's an easier solution - just before EVENT_TOUGHNESS is dispatched, set a global variable to hold the "current" base toughness. Now, when a creature like Nightmare or an effect like Sorceress Queen's wants something to have a different base, subtract the previous value of that global, change the global, and add it back in. (And do the same thing with EVENT_POWER.) This does the right thing even if there's an effect like Giant Growth being computed in the same pass. It'll need to be revisited once it becomes possible for a card or effect that wants to set base power or toughness to have an earlier timestamp than the creature being affected - say, a Humility that was already in play - probably by adding in a hack so that a creature card whose power or toughness is being computed always gets sent the event first, instead of in normal timestamp order. But for now, it's working correctly, doesn't need a bazillion invisible effect cards all over the place, and makes sense when you look at the cards' and effects' implementations.
Also, these characteristic-defining effects are supposed to work in all zones. Unlike Manalink, there's still only a few places in Shandalar that look at the power or toughness of a card that's not either in play, on the stack, or in a player's hand; so I can make the card functions of cards with a power or toughness of * safe to call even if there's no actual card_instance_t to work with, and then call it when when the value's needed. (Cards on the stack have power and toughness computed normally; cards in hand still have card_instance_t's, so just needed to not be skipped anymore.) So if you have a battlefield full of Mountain's, a library full of Keldon Warlord's, and a hand full of Imperial Recruiter's, you can now tutor up a Warlord for each of your first two Recruiters, but the third Recruiter onto your 'field won't be able to find anything.
I'm giving myself an arbitrary limit of 300 new cards between releases; by my count, I've got about 25 to go, so consider one imminent. I'll also be continuing to maintain a bugfix-only branch for Ruined Tower, so folks will have a stable release to play that Just Works. Still willing to take card requests from people who've been reporting bugs and posting AI decks.
- Cards recently added, largely as a result of such distraction | Open
These cards are complicated by effects like Sorceress Queen's, which change their base power and toughness. Nightmare is very different from a card that reads "Creature - Nightmare Horse 0/0
. Flying. Nightmare gets +1/+1 for each Swamp you control." - Nightmare, as printed, turns into 0/2 when targeted by Sorceress Queen, while the hypothetical card would be (number of swamps)/(number of swamps + 2).The way this implementation of Magic works is to compute power and toughness at the moment each is needed, not to go through each card, figure out what both its power and toughness should be, record that, and try to figure out when they'd be different. (In practice, they're recomputed very frequently, if for no other reason than for display to the screen; and there's an optimization that skips recomputation in favor of cached values most of the time. But never mind that.) This prevents the game from going through the all the layers and substeps to find power and toughness detailed in rule 613. The relevant ones are:
The workflow in the MicroProse game is to do layer 1 separately (mediated by EVENT_CHANGE_TYPE), do all of layer 7 in one step for toughness only (EVENT_TOUGHNESS), then do all of layer 7 in one step for power only (EVENT_POWER).MTG Comprehensive Rules, 2015-03-27 wrote:613.1a Layer 1: Copy effects are applied. See rule 706, "Copying Objects."
613.1g Layer 7: Power- and/or toughness-changing effects are applied.
613.3a Layer 7a: Effects from characteristic-defining abilities that define power and/or toughness are applied. See rule 604.3.
613.3b Layer 7b: Effects that set power and/or toughness to a specific number or value are applied. Effects that refer to the base power and/or toughness of a creature apply in this layer.
613.3c Layer 7c: Effects that modify power and/or toughness (but don't set power and/or toughness to a specific number or value) are applied.
613.3d Layer 7d: Power and/or toughness changes from counters are applied. See rule 121, "Counters."
613.3e Layer 7e: Effects that switch a creature's power and toughness are applied. Such effects take the value of power and apply it to the creature's toughness, and take the value of toughness and apply it to the creature's power.
7c and 7d can be safely combined, since they only add to or subtract from the current power or toughness value, and together they account for well over 99% of effects.
If 7a or 7b or 7e were more common, it would make sense to dispatch separate events for them. That's still not such a bad idea; there's plenty of triggers that only get checked for if some card on the battlefield is flagged to indicate it might respond to them. (That's what the columns from "Flags: Special Code When Controlled" through "Flags: Martyr" in ct_all.csv do, for example). But MicroProse instead decided to compute them all in one pass with EVENT_TOUGHNESS and EVENT_POWER, and got it working correctly; but their implementation is horribly complex. It requires a separate effect card ("AsteriskFX") to set the power or toughness of the */* creature instead of letting the creature card do it itself, and each effect that changes base power or toughness ("PiggyFX" - you can't make this stuff up) has to search for both AsteriskFX and any other PiggyFX's attached to the creature and flag them all as inactive. This turned out to be very easy to get wrong when we started adding similar effects in Manalink; and I expect that */* creatures will still be broken there for either Sorceress Queen or for Mirrorweave, one or the other.
Turns out there's an easier solution - just before EVENT_TOUGHNESS is dispatched, set a global variable to hold the "current" base toughness. Now, when a creature like Nightmare or an effect like Sorceress Queen's wants something to have a different base, subtract the previous value of that global, change the global, and add it back in. (And do the same thing with EVENT_POWER.) This does the right thing even if there's an effect like Giant Growth being computed in the same pass. It'll need to be revisited once it becomes possible for a card or effect that wants to set base power or toughness to have an earlier timestamp than the creature being affected - say, a Humility that was already in play - probably by adding in a hack so that a creature card whose power or toughness is being computed always gets sent the event first, instead of in normal timestamp order. But for now, it's working correctly, doesn't need a bazillion invisible effect cards all over the place, and makes sense when you look at the cards' and effects' implementations.
Also, these characteristic-defining effects are supposed to work in all zones. Unlike Manalink, there's still only a few places in Shandalar that look at the power or toughness of a card that's not either in play, on the stack, or in a player's hand; so I can make the card functions of cards with a power or toughness of * safe to call even if there's no actual card_instance_t to work with, and then call it when when the value's needed. (Cards on the stack have power and toughness computed normally; cards in hand still have card_instance_t's, so just needed to not be skipped anymore.) So if you have a battlefield full of Mountain's, a library full of Keldon Warlord's, and a hand full of Imperial Recruiter's, you can now tutor up a Warlord for each of your first two Recruiters, but the third Recruiter onto your 'field won't be able to find anything.
I'm giving myself an arbitrary limit of 300 new cards between releases; by my count, I've got about 25 to go, so consider one imminent. I'll also be continuing to maintain a bugfix-only branch for Ruined Tower, so folks will have a stable release to play that Just Works. Still willing to take card requests from people who've been reporting bugs and posting AI decks.
-
Korath - DEVELOPER
- Posts: 3707
- Joined: 02 Jun 2013, 05:57
- Has thanked: 496 times
- Been thanked: 1106 times
Re: Updates on the way.
by Teraunce » 09 Jun 2015, 03:13
well dependency walker told me that such fun stuff as dcomp.dll and ieshims.dll and most of the api-ms-win-*.dll files were missing and unregistered from my system. I have no idea how it's working either.Korath wrote:I don't know a better dumper, no, short of installing cygwin, which I don't recommend. But it wouldn't help anymore at this point anyway.
The way to definitively track this down is to install Microsoft's debugging tools (about two thirds of the way down this page), turn on library tracing with gflags as described here, and start the program under windbg or cdb (both included in the debugging tools package). It's a lot of hoops to jump through, though.
Dependency Walker may or may not isolate the problem, but it's a lot more user-friendly. I've had positive experiences with it in the not-so-recent past.
Re: Updates on the way.
by Korath » 09 Jun 2015, 03:59
I don't know what to tell you, Teraunce. I'm pretty sure I'm not doing anything unusual during linking that would make shandalar.dll trigger your problems, and you're not even getting to the point where it's loaded in the dump you posted (it's loaded via a LoadLibrary call in WinMain, rather than statically linked). A functioning Manalink rules out problems with cardartlib.dll or drawcardlib.dll, whose import libraries are statically linked from shandalar.exe.
The only thing I can think of that might account for this is some sort of trickery in the Shandalar installer that's now failing because the executable no longer exactly matches. But I don't even know if that's something that gets checked for - I'm out of my depth here; all of my professional experience is under Unix, not Windows.
The only thing I can think of that might account for this is some sort of trickery in the Shandalar installer that's now failing because the executable no longer exactly matches. But I don't even know if that's something that gets checked for - I'm out of my depth here; all of my professional experience is under Unix, not Windows.
-
Korath - DEVELOPER
- Posts: 3707
- Joined: 02 Jun 2013, 05:57
- Has thanked: 496 times
- Been thanked: 1106 times
Re: Updates on the way.
by Aswan jaguar » 09 Jun 2015, 13:45
@ Teraunce if you haven't tried another install a fresh one (and you don't say you tried that) then:
Installation directions: If this is your first installation
1- Install Shandalar from any of the recent versions posted in this forum.(I highly reccomend this) :
viewtopic.php?f=76&t=2349
2- Install Manalink into the same directory, overwriting everything.(Use one from these latest = 1 probably better):
viewtopic.php?f=55&t=6401#p82367
3- Update Manalink to the Fate Reforged patch (not any later ones, for now), including the art updates. (Just the Manalink art updates is fine; you don't need to install the CardArtShandalar package.) Install Manalink 3 latest patch into the same directory,again overwriting everything :
http://www.mediafire.com/download/6a86j ... 325-FR.rar
and read carefully the instructions for cardart from the last fate reforged patch that is:
viewtopic.php?f=85&t=16964#p176033
4- Unzip the attached package (Ruined Tower 2)into the same directory (again overwriting everything if needed):
download/file.php?id=22342
If this fresh install doesn't work,tell us if you have the same problem or different ones.
Installation directions: If this is your first installation
1- Install Shandalar from any of the recent versions posted in this forum.(I highly reccomend this) :
viewtopic.php?f=76&t=2349
2- Install Manalink into the same directory, overwriting everything.(Use one from these latest = 1 probably better):
viewtopic.php?f=55&t=6401#p82367
3- Update Manalink to the Fate Reforged patch (not any later ones, for now), including the art updates. (Just the Manalink art updates is fine; you don't need to install the CardArtShandalar package.) Install Manalink 3 latest patch into the same directory,again overwriting everything :
http://www.mediafire.com/download/6a86j ... 325-FR.rar
and read carefully the instructions for cardart from the last fate reforged patch that is:
viewtopic.php?f=85&t=16964#p176033
4- Unzip the attached package (Ruined Tower 2)into the same directory (again overwriting everything if needed):
download/file.php?id=22342
If this fresh install doesn't work,tell us if you have the same problem or different ones.
Last edited by Aswan jaguar on 10 Jun 2015, 13:33, edited 1 time in total.
---
Trying to squash some bugs and playtesting.
Trying to squash some bugs and playtesting.
-
Aswan jaguar - Super Tester Elite
- Posts: 8078
- Joined: 13 May 2010, 12:17
- Has thanked: 730 times
- Been thanked: 458 times
Who is online
Users browsing this forum: No registered users and 24 guests