(moved to tracker) Crash in 3.3.0

[Radiant]

Some players report the following crash for 3.3.0, but only when running in windowed mode:


An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x00469B98 ; program pointer is -1893, ACI version 3.3.0.1156, gtags (8485,21)
AGS cannot continue, this exception was fatal. Please note down the numbers above, remember what you were doing at the time and post the details on the AGS Technical Forum.
Most versions of Windows allow you to press Ctrl+C now to copy this entire message to the clipboard for easy reporting.
An error file CrashInfo.dmp has been created. You may be asked to upload this file when reporting this problem on the AGS Forums. (code 0)

I have the .dmp file too, if that helps. The screen is 320x200 using max NN scaling, perhaps something is going on with detecting the proper multiplier?

[Radiant]

A different one that has been reported is this, which occurs when restoring a game:

An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x004CFA76 ; program pointer is +2051, ACI version 3.3.0.1156, gtags (48,2)

[Crimson Wizard]

Please, send me crash dumps. Also, is it Heroine Quest? I will probably need a matching game executable.

[Radiant]

Yes, it is HQ. It would be easiest if you could download the executable from http://store.steampowered.com/app/283880 - if that doesn't work for you let me know and we'll figure something out.

First crash dump: http://forum.caravelgames.com/getattachment.php?id=35692
Second crash dump: https://www.dropbox.com/s/bacwiz86puq6w7b/CrashInfo.3.3.0.1156.dmp

[Crimson Wizard]

I can't download from the first link.

[Radiant]

Hm, I guess it doesn't allow cross-site linking. Very well, it's attached (shown left of) the first post here: http://forum.caravelgames.com/viewtopic.php?TopicID=36960   

[Crimson Wizard]

Was the game built with exactly AGS 3.3.01146, or with any of the intermediate fix releases?
In the latter case I won't be able to do anything, because I didn't kept any PDB files for them.

EDIT: Ok, I found those PDBs in my backups, these are from versions built 6th, 7th and 10th November (between Beta 9 and Beta 10). But still none of them match.

[Radiant]

It's 1156, not 1146. That should be the final build minus the last hotfix.

[Crimson Wizard]

Ooops. I must be seeing things. Sorry.

Ok, this works, I can see where it happened. Will investigate.

E: the first crash occurs on taking a screenshot for savegame.
Strange, I remember seeing something like this from very early 3.3.0 development, or even 3.2.1.

[Radiant]

Yes. As I recall, the game makes a saved game when starting up (this is the .999 save used for restarting the game) and perhaps the screen isn't initialized yet or something. Easy workaround: never take screenshots for the .999 save.

[Crimson Wizard]

Easy workaround: never take screenshots for the .999 save.

And if that slot is saved in the midst the game and not in the start?

[Radiant]

Then it still doesn't need a screenshot, because the 999 doesn't show up in restore game GUIs, nor does it show up on the user's desktop (since it gets deleted when you quit the game).

[Crimson Wizard]

No. having screenshot for slot is completely unrelated issue. There should not be workarounds like that. The crash should be fixed instead.

[Alan v.Drake]

Are we talking about D3D mode ? If so we might try my patch against getFrontBufferData.

- Alan

[Crimson Wizard]

Are we talking about D3D mode ? If so we might try my patch against getFrontBufferData.

- Alan

Please commit, or make pull request.

[Radiant]

No. having screenshot for slot is completely unrelated issue. There should not be workarounds like that. The crash should be fixed instead.

Fair enough. Nevertheless, if the game is saved during the startup process, it would be reasonable to store a blank bitmap (after all, the screen isn't initialized yet so there's no screenshot to show).

And Alan - yes, this is D3D.

[Radiant]

A different one that has been reported is this, which occurs when restoring a game:

An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x004CFA76 ; program pointer is +2051, ACI version 3.3.0.1156, gtags (48,2)

Do you have an idea what may be causing this? It's apparently a different issue.

[Crimson Wizard]

Didn't have time to examine precisely, but IIRC that crashes during restoring a room state.

Does it occur every time with a particular saved game? If yes, do you have it?

[Radiant]

Here you go:

https://www.dropbox.com/s/fv2g4yb0ulqa7yt/Heroine's%20Quest%201.2.rar

It reproduces for me if you open the second saved game ("Autosave Jarnvidr"). Given that the rooms of Jarnvidr use Rawdraws, it may have something to do with restoring the screen's background?

[Crimson Wizard]

For now I can tell this: the dynamic room state is broken and some data is loaded incorrectly. This does not cause immediate crash for me though, but it crashes when I exit the game, simply put because it tries to delete excess objects that never existed.

This is not a precise information yet, but after adding few extra checks the incorrect data was detected on reading:
- Room 81 dynamic state
- Room object #13 data (but this may mean nothing, because in current save format rooms write all supported amount of objects, even if they are not really used in the room).

E: Other saves from this pack are similarily corrupted.

[Radiant]

Ok. Assuming these counts are base-zero, that corresponds to the object that shows the location name ("Jarnvidr" in fancy lettering) in the forest. When the player enters a new area, this location text is shown (then slowly removed via object transparency) and a string is set for the auto-save. This is all done in the following function, which is called from the room's on_call function, which itself is called from the global script's on_event for Enter Room. Then the next time repeatedly_execute() triggers, it detects that the string is set, and does an automatic save (I'm doing it this way because saving games from the enter room event doesn't always work).

Code: ags

function SetCaption (int o) {
  String msg = "Unknown";
  SetObjectBaseline (o, 250);
  if (caption_loc == GetObjectGraphic (o)) {
    ObjectOff (o);
  } else {
    caption_loc = GetObjectGraphic (o);
    SetObjectTransparency (o, 100);
    ObjectOn              (o);
    caption_obj  = o;
    caption_time = 0;
    o            = GetObjectGraphic (o);
    if (o == 2377) msg = "Fornsigtuna";
    if (o == 2373) msg = "Munarvagir";
    if (o == 2379) msg = "Jarnvidr";
    if (o == 2378) msg = "Svartalfheim";
    if (o == 2381) msg = "Gandvik";
    if (o == 1262) msg = "Nidavellir";
    if (o == 2380) msg = "Gastropnir";
    SetGlobalString (9, String.Format ("Autosave - %s", msg));
  }
}

[Crimson Wizard]

Hmm, is not the room 81 a room with avalanche you first see in the intro? This is 0-based (room #0 is obsoleted "intro.crm"). I hacked the engine to enable room travel and found it.
I tried visiting several rooms in forest and made saves, but they all work well.

[Moved from "edit" in the previous post]
To elaborate: the crash dump you linked previously shows an error when room dynamic data is being reset right before loading a saved game. This probably happened when user tried to load save while being in game already.
I am not sure room #81 is necessarily a culprit, but I can't tell much because I don't see the insides of your game. I think it may be possible to find out what is causing this by walking through a game and testing saves often: save on new slot then reload two times in a row, walkthough bit more, repeat. Of course one needs to at least have a guess where to start looking, because it may take too long.

E: what I'd like to know, does this happen with any save in this version of the game? Has only one user reported this?

[Radiant]

Hmm, is not the room 81 a room with avalanche you first see in the intro?

Yes, it is.

This probably happened when user tried to load save while being in game already.

That matches the error report, yes. The user states that he can still play by quitting the game and loading from the start screen. He also reports that the game likewise crashes when he quits, which matches your earlier statement.

I am not sure room #81 is necessarily a culprit,

Unlikely; it's one of the least complicated rooms in the game, with only two objects and 20 lines of room script.

but I can't tell much because I don't see the insides of your game.

I'd be happy to help, but I was hoping it would be possible to avoid this by adding a few nullpointer checks to the AGS code.

E: what I'd like to know, does this happen with any save in this version of the game? Has only one user reported this?

Only one user has reported this.

[Crimson Wizard]

but I can't tell much because I don't see the insides of your game.

I'd be happy to help, but I was hoping it would be possible to avoid this by adding a few nullpointer checks to the AGS code.

Well, I am not asking to give me a game project that was just a statement of facts.
Regarding null pointer check, this is kind of complicated. The problem is that the corrupted data modifies the variable that serves as a size of array, making engine think that array is much much larger than it actually is. This leads to accessing wrong memory addresses.
I made a fix to our master branch that detects when loaded room tries to set that variable beyond restricted bounds (for some reason such test was missing at one point), but this will just make the corrupted savegame not load at all.

[Radiant]

Ok, so the question is when the data became corrupted. That's a tough call considering how rarely it happens. Does this array size have a getter/setter function that can be traced?

Alternatively, would it be possible to recover from this error? For example, by loading the entire game but treating this particular room as "never visited" because its local data cannot be loaded? That and a warning or log message would be a graceful solution.

[Crimson Wizard]

Ok, so the question is when the data became corrupted. That's a tough call considering how rarely it happens. Does this array size have a getter/setter function that can be traced?

No, and it is some legacy data meant only for compatibility with pre-2.72 games. It stays zeroed in modern games.

Alternatively, would it be possible to recover from this error? For example, by loading the entire game but treating this particular room as "never visited" because its local data cannot be loaded? That and a warning or log message would be a graceful solution.

The corruption is specific, I examined this further and it does not break all the save file, just some partition in the middle of one room data (it fills it with random garbage). May be some process accessed incorrect memory and wrote something there...

I have a thought it is possible to clean the savegame in the hex editor, knowing where to start and where to end (it is pretty clear when you see data contents under debugger).

Alternatively, would it be possible to recover from this error? For example, by loading the entire game but treating this particular room as "never visited" because its local data cannot be loaded? That and a warning or log message would be a graceful solution.

This is a too optimistic view on problem. We can't add fixes that help to recover from one particular problem in one game. And I don't see an easy way to check if it is only one room that was corrupted. Such features as recovering from errors need a systematic approach. A lot of things to consider, and much code to change in the engine too.

[Radiant]

This is a too optimistic view on problem. We can't add fixes that help to recover from one particular problem in one game. And I don't see an easy way to check if it is only one room that was corrupted. Such features as recovering from errors needs a systematic approach.

I agree. I can see two ways of being systematic about this. First, assumedly a saved game contains an array of room structs (among other things); if one element of this array is corrupt, the rest can still be loaded, which would be preferable to aborting the game. And second, you can apparently tell when a room struct is invalid by noticing that this value for the size of an array is out of bounds.

Alternatively, if this data is only for 2.71 games, can it just be ignored when running in 3.3?

[Crimson Wizard]

Very well.
How should a user be notified of this error?
Should there be a setting that defines whether to quit or notify user and continue?

Should I make this as a hotifx to 3.3.0 or add to 3.3.1?

No, I just can't do that. This is way too stupid.
This variable is the ONLY one that is being checked for wrong value in whole room. It is simply a misfortune that data corruption occured at that point. Next time it occurs in another - what then?
There's no way to know if any of the rest of the room is bad, not without inventing a test that would suffice. Testing if room objects refer to sprites and loops that exist. Testing that some other values are not crazy.
Then, there should probably be a system that gathers all found problems, because the room state is initialized as data loads, and initialization failure should not stop reading data. Or, the loading procedure should be altered to let it calculate the rest of data and skip it.

Then, what if the corrupted data is non-essential (like here)? In this case we will reset whole room state simply because some byte is wrong in the midst of the file. So, do we need another check for that too?


Then, how "graceful" will it be to reset a whole room without knowing how important it is for the game? What if resetting that room will lead to broken scripting logic? In such case this solution is not graceful at all, in fact it will only worsen the case: the player will keep playing without knowing that he plays a "dead-end" game.


You see, there are so many issues interwined here; this quick solution is way too optimistic.

[Radiant]

That's a good point. Thinking about this, I suppose that many AGS functions, including restoring the game, assume that variables and structs have a valid value. That's fair, and it would be a ridiculous amount of work to add assert()s everywhere. So doing that is not the productive approach here. Rather, I believe there are three options worth considering.

First, is it possible to give the user a more friendly response than a crash message (to invalid saved games in general, not just this one). Rather than throwing an exception, it would be preferable if the engine showed a message "Sorry, this saved game is corrupt" and then abort. It would be even better if instead of aborting, the game would either continue or restart, although it depends on the internals of RestoreGame() whether that can be made to work.

Second, can we keep the situation from spreading? Currently restoring this saved game crashes, but restoring it from the title works, allowing the user to play on and make a second saved game, which will again crash when loaded; so now the user has two bad saves. Ideally, if a saved game doesn't load from within the game, then it shouldn't load from the title screen either. It is better to have a user lose one save, than to give that user a series of invalid saved games.

And finally, is it possible to find out what caused this? I'm inclined to say "no" at this point; as you told me, all five saves in that zipfile are corrupt, so it's not possible to compare the first corrupt with the last good saved game. All we know that this issue is rare, and that the player did something between starting the game and that save, and it might also have been caused by the Steam software, by some overly intrusive security package, or by a memory editor that some players use (to max out their stats or to claim Steam achievements). Unless we have a reliable way of reproducing it, the search space is simply enormous and finding this is not at all practical.

Your thoughts on this would be appreciated.

[Crimson Wizard]

First, is it possible to give the user a more friendly response than a crash message (to invalid saved games in general, not just this one). Rather than throwing an exception, it would be preferable if the engine showed a message "Sorry, this saved game is corrupt" and then abort. It would be even better if instead of aborting, the game would either continue or restart, although it depends on the internals of RestoreGame() whether that can be made to work.

IIRC the earlier versions of AGS would display a "can't load save" message in a standard text box (maybe in certain cases only) and let user continue playing. The weakness of this approach in the context of how AGS currently works is that game is put into undefined (and probably unstable) state; meaning user have some chances to load different game, but at the same time anything may stop working correctly.
I see three paths here:
1. Load data into temporary object(s), then replace the current game state with the contents of that object if it was loaded correctly. The disadvantage of this is that memory requirement increases (not doubles, because dynamic state does not hold everything, ideally only data that may change at runtime (although in AGS it's messed up a bit too)).
2. Prior to restoring the game save current game, and if the loading fails, reload backup. This may lead to quirky results if the "on restore game" event is being handled in script. Also this may look not good if the game was in special state (like a death screen, or something).
3. If load fails restart the game. Truth be said, AGS cannot restart normally at this point, it's "restarting" is based on restoring special 999th slot. But if we speak hypothetically, a new "real restart" feature could be added.
Alternatively, there may be a special built-in restore/restart/quit menu. The problem here is, though, that AGS has no "wrapping" framework around the game (like in ScummVM, for example), so if a part of the program's state gets corrupted there not often can be a guarantee that the rest will continue to work flawlessly.
Perhaps it is a way to go: strictly separate "static" part of the engine which always remains the same and "dynamic" one that may change, save and load. If this is accomplished, then the game designer could even provide a custom "service menu" for the case of game errors. But I am speaking hypothetically now.

Second, can we keep the situation from spreading? Currently restoring this saved game crashes, but restoring it from the title works, allowing the user to play on and make a second saved game, which will again crash when loaded; so now the user has two bad saves. Ideally, if a saved game doesn't load from within the game, then it shouldn't load from the title screen either. It is better to have a user lose one save, than to give that user a series of invalid saved games.

Yes, and in most cases it works that way. The reason this corruption got unnoticed was that there was a check missing on a single case (this is why I made a fix recently).

And finally, is it possible to find out what caused this? I'm inclined to say "no" at this point; as you told me, all five saves in that zipfile are corrupt, so it's not possible to compare the first corrupt with the last good saved game. All we know that this issue is rare, and that the player did something between starting the game and that save, and it might also have been caused by the Steam software, by some overly intrusive security package, or by a memory editor that some players use (to max out their stats or to claim Steam achievements). Unless we have a reliable way of reproducing it, the search space is simply enormous and finding this is not at all practical.

Well, my answer is "I don't know" at the moment.

What is possible to do: there's a way to tell the memory offsets which limit the corrupted region in file, then fill it with zeroes (e.g. in binary hex editor). This may at least fix the savegames. I may try that out.

[Radiant]

3. If load fails restart the game.

I would suggest this approach. If the user tries to restore a game, it is already a given that he's throwing away his current game state, because that's what restoring a game means (and it's likely that he is restoring from a death screen). Therefore it shouldn't be necessary to create a complicated system to let the user continue his (unwanted) current game in the case that restoring fails. Restarting is simply a nicer approach than terminating to desktop. It should be easy to force a hard restart by invoking a ShellExecute on the game's executable file to get a new process, then silently terminating the current process.

Alternatively, there may be a special built-in restore/restart/quit menu.

This would be an interesting feature to consider for AGS 3.4.

Yes, and in most cases it works that way. The reason this corruption got unnoticed was that there was a check missing on a single case (this is why I made a fix recently).

Then I think that most of the problem is solved now.

What is possible to do: there's a way to tell the memory offsets which limit the corrupted region in file, then fill it with zeroes (e.g. in binary hex editor). This may at least fix the savegames. I may try that out.

If you can fix the most recent saved game (by timestamp) without too much trouble, that would be nice. If not, I'd ask him to restart; considering how far he is in the game it shouldn't take him that long to get back to his current position.

Thank you for your help!

[Crimson Wizard]

Here:
http://www.mediafire.com/download/ftz3seg9p68lwra/agssave.000.hqthor

[Radiant]

Thank you very much.

(I've added the restart option to the tracker, for easy reference)

(edit:) the player in question confirms that it works now.

[Radiant]

I'm afraid we've got another one that may be related. One player points out that when playing in windowed mode, if he moves the window around, this may cause his game to crash and/or corrupt saved games. It only does this when he moves the window down while the game

The exception is as follows, "An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x00469B98 ; program pointer is -1893, ACI version 3.3.0.1156, gtags (0,7)" and the crash dump looks like this (does that work for you? Apparently the user opened the .dmp file in visual studio),

Spoiler

Dump Summary
------------
Dump File:   CrashInfo.3.3.0.1156.dmp : C:\Program Files (x86)\Steam\SteamApps\common\Heroine's Quest\CrashInfo.3.3.0.1156.dmp
Last Write Time:   3/30/2014 7:53:14 PM
Process Name:   Heroine's Quest.exe : C:\Program Files (x86)\Steam\steamapps\common\Heroine's Quest\Heroine's Quest.exe
Process Architecture:   x86
Exception Code:   0xC0000005
Exception Information:   The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
Heap Information:   Not Present

System Information
------------------
OS Version:   6.2.9200
CLR Version(s):   

Modules
-------
Module Name   Module Path   Module Version
-----------   -----------   --------------
Heroine's Quest.exe   C:\Program Files (x86)\Steam\steamapps\common\Heroine's Quest\Heroine's Quest.exe   3.3.0.1156
ntdll.dll   C:\Windows\System32\ntdll.dll   6.2.9200.16420
kernel32.dll   C:\Windows\System32\kernel32.dll   6.2.9200.16384
KERNELBASE.dll   C:\Windows\System32\KERNELBASE.dll   6.2.9200.16451
quartz.dll   C:\Windows\System32\quartz.dll   6.6.9200.16384
winmm.dll   C:\Windows\System32\winmm.dll   6.2.9200.16642
shlwapi.dll   C:\Windows\System32\shlwapi.dll   6.2.9200.16384
opengl32.dll   C:\Windows\System32\opengl32.dll   6.2.9200.16384
user32.dll   C:\Windows\System32\user32.dll   6.2.9200.16420
gdi32.dll   C:\Windows\System32\gdi32.dll   6.2.9200.16654
advapi32.dll   C:\Windows\System32\advapi32.dll   6.2.9200.16384
shell32.dll   C:\Windows\System32\shell32.dll   6.2.9200.16550
ole32.dll   C:\Windows\System32\ole32.dll   6.2.9200.16451
oleaut32.dll   C:\Windows\System32\oleaut32.dll   6.2.9200.16657
ddraw.dll   C:\Windows\System32\ddraw.dll   6.2.9200.16384
dinput.dll   C:\Windows\System32\dinput.dll   6.2.9200.16384
dsound.dll   C:\Windows\System32\dsound.dll   6.2.9200.16384
msvcrt.dll   C:\Windows\System32\msvcrt.dll   7.0.9200.16384
WINMMBASE.dll   C:\Windows\System32\WINMMBASE.dll   6.2.9200.16645
glu32.dll   C:\Windows\System32\glu32.dll   6.2.9200.16384
sechost.dll   C:\Windows\System32\sechost.dll   6.2.9200.16384
rpcrt4.dll   C:\Windows\System32\rpcrt4.dll   6.2.9200.16622
combase.dll   C:\Windows\System32\combase.dll   6.2.9200.16420
dciman32.dll   C:\Windows\System32\dciman32.dll   6.2.9200.16453
powrprof.dll   C:\Windows\System32\powrprof.dll   6.2.9200.16384
cfgmgr32.dll   C:\Windows\System32\cfgmgr32.dll   6.2.9200.16384
devobj.dll   C:\Windows\System32\devobj.dll   6.2.9200.16384
sspicli.dll   C:\Windows\System32\sspicli.dll   6.2.9200.16420
CRYPTBASE.dll   C:\Windows\System32\CRYPTBASE.dll   6.2.9200.16384
bcryptPrimitives.dll   C:\Windows\System32\bcryptPrimitives.dll   6.2.9200.16384
imm32.dll   C:\Windows\System32\imm32.dll   6.2.9200.16384
msctf.dll   C:\Windows\System32\msctf.dll   6.2.9200.16496
gameoverlayrenderer.dll   C:\Program Files (x86)\Steam\gameoverlayrenderer.dll   2.13.4.49
psapi.dll   C:\Windows\System32\psapi.dll   6.2.9200.16384
SHCore.dll   C:\Windows\System32\SHCore.dll   6.2.9200.16433
uxtheme.dll   C:\Windows\System32\uxtheme.dll   6.2.9200.16537
atiu9pag.dll   C:\Windows\System32\atiu9pag.dll   8.14.1.6268
version.dll   C:\Windows\System32\version.dll   6.2.9200.16384
FileBXH32.dll   C:\Users\Alex\Desktop\League of Legends\Deskpin\FileBX\FileBXH32.dll   2.1.0.0
dwmapi.dll   C:\Windows\System32\dwmapi.dll   6.2.9200.16384
hid.dll   C:\Windows\System32\hid.dll   6.2.9200.16384
setupapi.dll   C:\Windows\System32\setupapi.dll   6.2.9200.16496
wintrust.dll   C:\Windows\System32\wintrust.dll   6.2.9200.16666
crypt32.dll   C:\Windows\System32\crypt32.dll   6.2.9200.16666
msasn1.dll   C:\Windows\System32\msasn1.dll   6.2.9200.16384
clbcatq.dll   C:\Windows\System32\clbcatq.dll   2001.12.10130.16384
MMDevAPI.dll   C:\Windows\System32\MMDevAPI.dll   6.2.9200.16420
AudioSes.dll   C:\Windows\System32\AudioSes.dll   6.2.9200.16451
wdmaud.drv   C:\Windows\System32\wdmaud.drv   6.2.9200.16384
ksuser.dll   C:\Windows\System32\ksuser.dll   6.2.9200.16384
avrt.dll   C:\Windows\System32\avrt.dll   6.2.9200.16420
msacm32.drv   C:\Windows\System32\msacm32.drv   6.2.9200.16384
msacm32.dll   C:\Windows\System32\msacm32.dll   6.2.9200.16384
midimap.dll   C:\Windows\System32\midimap.dll   6.2.9200.16384
AGSteam.dll   C:\Program Files (x86)\Steam\steamapps\common\Heroine's Quest\AGSteam.dll   0.0.0.0
steam_api.dll   C:\Program Files (x86)\Steam\steamapps\common\Heroine's Quest\steam_api.dll   1.98.31.73
msvcr90.dll   C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6871_none_50944e7cbcb706e5\msvcr90.dll   9.0.30729.6871
profapi.dll   C:\Windows\System32\profapi.dll   6.2.9200.16384
d3d9.dll   C:\Windows\System32\d3d9.dll   6.2.9200.16384
aticfx32.dll   C:\Windows\System32\aticfx32.dll   8.17.10.1140
atiumdag.dll   C:\Windows\System32\atiumdag.dll   9.14.10.924
atiumdva.dll   C:\Windows\System32\atiumdva.dll   8.14.10.363
steamclient.dll   C:\Program Files (x86)\Steam\steamclient.dll   2.13.4.49
ws2_32.dll   C:\Windows\System32\ws2_32.dll   6.2.9200.16384
IPHLPAPI.DLL   C:\Windows\System32\IPHLPAPI.DLL   6.2.9200.16420
imagehlp.dll   C:\Windows\System32\imagehlp.dll   6.2.9200.16384
tier0_s.dll   C:\Program Files (x86)\Steam\tier0_s.dll   2.13.4.49
vstdlib_s.dll   C:\Program Files (x86)\Steam\vstdlib_s.dll   2.13.4.49
secur32.dll   C:\Windows\System32\secur32.dll   6.2.9200.16384
nsi.dll   C:\Windows\System32\nsi.dll   6.2.9200.16384
winnsi.dll   C:\Windows\System32\winnsi.dll   6.2.9200.16384
cryptsp.dll   C:\Windows\System32\cryptsp.dll   6.2.9200.16384
rsaenh.dll   C:\Windows\System32\rsaenh.dll   6.2.9200.16384
Steam.dll   C:\Program Files (x86)\Steam\Steam.dll   0.0.0.0
Steam2.dll   C:\Program Files (x86)\Steam\Steam2.dll   2.0.2117.156
dbghelp.dll   C:\Program Files (x86)\Steam\dbghelp.dll   6.7.5.0
CSERHelper.dll   C:\Program Files (x86)\Steam\CSERHelper.dll   4.50.0.0

[close]

[Crimson Wizard]

It only does this when he moves the window down while the game

You mean, minimize?

[Radiant]

The user says "move around", so I take that as meaning dragging the window to another location on-screen, not minimizing it.

[Crimson Wizard]

Regarding the dump, it's just dump info, but not actual dump. The real dump is a binary file.

"program pointer is -1893" is at the very beginning of saving game.

[Radiant]

Here you go: http://www.datafilehost.com/d/09c2383f

[Radiant]

Now in the tracker:

http://www.adventuregamestudio.co.uk/forums/index.php?issue=549.0
http://www.adventuregamestudio.co.uk/forums/index.php?issue=550.0

[Radiant]

Some players report the following crash for 3.3.0, but only when running in windowed mode:

An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x00469B98 ; program pointer is -1893, ACI version 3.3.0.1156, gtags (8485,21)

Can I assume that it is the same issue if another user gets a different EIP but the same program pointer and gtags?

[Crimson Wizard]

Some players report the following crash for 3.3.0, but only when running in windowed mode:

An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x00469B98 ; program pointer is -1893, ACI version 3.3.0.1156, gtags (8485,21)

Can I assume that it is the same issue if another user gets a different EIP but the same program pointer and gtags?

You can, but that's not necessarily true...