Host Visual C++ Runtime Error in 2.6.0

[Zeus]

Hi not sure whats going on but we have just abandoned our usual Friday night game this evening due to FGII server host stability issues.

Basically my usual 4e campaign is starting up OK and in good time, all players are connecting in under 1 minute each. Maps are being shared with no issues and tokens/portraits are loading and displaying well too. I have even got the usual Skype conference going in parallel (on a seperate Mac system) with my four other players with no problems.

All appears to be fine with FGII until I the host will suddenly get the following error message:


Microsoft Visual C++ Runtime Library

Runtime Error!
C:\Program Files\Fantasy Grounds II\FantasyGrounds.exe

This application has requested the runtime to terminate it in an unusual way. Please contact the application support team for more information.


Clicking the OK button, closes the application and all players disconnect (a couple of my players FGII clients hang for a good few minutes before finally closing after being forced to).

After the first occurence of the error, I just restarted the server normally, everyone reconnected and we resumed play for about 10 minutes when again the same message appeared. Whats strange was no one was doing anything, I mean we were all chatting and I wasn't interacting with FGII at all.

Restarted again only for the same thing to happen less than 2 minutes in, restarted again but this time we played for 30 mins with no issues until finally it occured again. Given the late hour we decided to call it a day in the hope that I can get it resolved by next weeks game.

Has anyone else experienced any issues or can anyone suggest what maybe causing the problem?

Nothing has particualry changed my end with exception of the usual rulebook module updates and the latest 2.6.0 release.

I am suspicious that perhaps my modules may contain an error or two which maybe causing the crashes to occur however remain uncertain as at least one occurence of the host error occured when no interactivity with modules were taking place.

Any assistance would be greatly appreciated.

[EugeneZ]

I've had similar problems recently.

First off, I believe the MSVC++ error you are getting is because you have MSVC++ installed and a watcher it installs hijacks the software crash with the hope of possibly debugging it. In other words, if I'm not mistaken, the error message is specific to your system and would normally appear as a "Your program has stopped responding" message, like does on my system when the watcher is turned off. (I forgot how I managed to turn it off.)

As for the issue itself, I am still trying to nail it down to a specific issue but it seems to be related to a player joining a game after a map *with a mask* has been shared. It then immediately crashes. Afterwards, it crashes at seemingly random intervals when players reconnect.

This is pure guesswork but I am guessing that the mask somehow blows up and FG2 tries to send this blown up chunk, causing a crash. When players reconnect, it may send the blown up chunk again.

I fixed it by having one player connect at a time, wait for them to select a character, then the next person gets on. I got the crash once or twice this way too but after a few crashes FG2 appears to eat through whatever crap caused the problem and then proceeds nicely.

What's odd is that this problem seems to persist to other campaigns. The first time this happened, we stopped playing like you. A few days later I was running a different campaign and similar issues cropped up. But we just kept reconnecting and they went away when we took it slow. When it happened again in a different game, we tried the "slow" approach again and it worked with only a single crash or two. After that, it was fine.

Hope it helps.

[Zeus]

The MSVC style message is more than likely down to the fact I have Visual Studio 2008 installed on the same system. Not sure how to disable it catching app crashes though.

The prognosis of map masks being a possible cause is an interesting one although several of the crashes which occured last night happened at times when masks were not enabled. By that a map was shared but it had no mask enabled.

I double checked all my modules and all seem to contain valid XML so I beleieve I can eliminate them as a possible cause. I'm running the 4E_JPG ruleset v1.51 with some homebrew extensions but everything prior to 2.6 was working very well with no host crashing issues.

I don't play anything other than D&D 4e at the moment so can't confirm if the error occurs in other rulesets. I have a 2nd campaign game on Sunday so if the problem occurs in that session too, I can eliminate my campaign XML as a rogue suspect to.

[Zeus]

OK. I think I know whats causing the crashing.

Its the return of the problematic growing <shortcut> elements in the xml files created in modulesdb during session play. The problem was reported back between 2.3.6 and 2.4 (see this original thread: https://www.fantasygrounds.com/forums/showthread.php?t=10473&highlight=modulesdb) (https://www.fantasygrounds.com/forums/showthread.php?t=10473&highlight=modulesdb%29).

I thought it was fixed but it looks like 2.51/2.6 may have re-introduced it. The offending file was my KotS module (yep still playing it) which had thousands of shortcut elements for one map (all duplicates at the same coordinates). I can remove the duplicates to get the moduledb image consistent again but I suspect FGII will create furter duplicates during the next session.

In addition to the duplicate shortcut entries some contain repeats of the @ designator address again.

As in the previous reported instance of this error, once the XML file reaches a size of about 1.5MB FGII begins to get unstable and eventally crashes.

I believe another user may have experienced a similar issue recently, gmkieren, (see thread here: https://www.fantasygrounds.com/forums/showthread.php?t=10992&highlight=modulesdb.) so I don't believe this is an isolated issue to me alone.

Perhaps some of the other community members can check the size of the files in their modulesdb subfolder after there next session and report back on this thread for the devs.

[Tenian]

I am getting the duplicate shortcut nodes as well. I have backups of my campaign from 9/16 and 9/24. For a randomly selected shortcut it appeared 48 times on 9/16 and 74 times on 9/24

The previous bug caused the shortcut recordname field to grow (adding another @module each time it was opened) this quickly reached the node size limit and caused the campaign to be unusuable.

This bug repeats the same <shortcut> over and over. So it appears to be new.

[Zeus]

I am getting the duplicate shortcut nodes as well. I have backups of my campaign from 9/16 and 9/24. For a randomly selected shortcut it appeared 48 times on 9/16 and 74 times on 9/24

The previous bug caused the shortcut recordname field to grow (adding another @module each time it was opened) this quickly reached the node size limit and caused the campaign to be unusuable.

This bug repeats the same <shortcut> over and over. So it appears to be new.

As well as the duplicated <shortcut> elements, I also get recordname fields growing with repeats of @4e KotS again and again and again. Its only for some entries though? Weird.

[EugeneZ]

I gotta say that I don't ever use shortcut pins and nothing in my modulesdb is over 22 KB, so I don't think that's my problem. Hm... guess I have unrelated issues? Still, it seems so similar.

[Griogre]

It still might be the same problem but instead of it being a specific shortcut error it might be that after such and such the next line (or next something) keeps having parts of it added too. For those with short cuts it happens on their short cuts for those who don't use them it happens on whatever follows in the same place the shortcuts are for the others. Probably in the next link or something.

[Goblin-King]

The bug with duplicate shortcuts was found and a fix is in internal testing.

We could not replicate the multiple @ issue. My guess is that there is some complex linking between different modules going on. If you continue to have these problems after 2.6.1, or if you want us to have a look at the problem, please either attach module files (preferred, even better would be a simple module that illustrates the problem as concisely as possible) or instructions on how to reproduce, starting with how the module was exported.

[Zeus]

Goblin-King,

Thanks I have a game planned for this coming Friday so will update this thread on Saturday.

On the off chance the problem is not completely resolved I have forwarded the affected modules via private message to Dupre's request. Hopefully they can help shed some light.

I should state I am not convinced the repeating @ is caused by a current bug, the entries in my modulesdb files might have been left over from the previous 2.3-2.4 bug issue I guess. However having said that I produce my adventure modules using FGII's interface, pulling copies of existing material from other modules where needed, to create local copies of data e.g. NPCs from my MM modules. I do this by dragging an NPC from one of my modules into Personalities. The remaining story entries are either hand inputted or parsed using a variety of tools. Finally its all combined into a module using the /export command. I guess this may create complexity in the module's internal linking but I don't believe the modules or their data are crosslinked in any way, although your welcome to correct my understanding if you spot anything otherwise.

[Zeus]

OK. We just finished our first session using the latest 2.6.1 release of FGII.

Game started promptly at 8.30pm with all players connecting OK, we played for about 45mins when suddenly another Runtime error occured on the host killing the app and all player connections to me.

Before restarting FGII I checked my modulesdb folder and all seemed well.

Restarted FGII and all players attempt to connect, as they are connecting I begin preparing my desktop with the story notes I need, image windows (not shared yet), modifiers, effects and Comba ... Runtime Error again.

Remebering Eugene's earlier suggestion of limiting players to connecting to one at a time, I restarted FGII and asked each player to connect in turn.

Seemed to make things a little better as all players connected OK and we were able to resume playing for well over an 1hr 30mins before another occurence of a Runtime error halted play. Decided at this point to halt the evening's activity.

I have another game on Sunday, this one using a completley different campaign but still 4E_JPG. I am hoping that the game on Sunday game goes better with no occurences of Runtime Errors, this would point the suspicion at the specific campaign. Would it not?

Aside from Eugene, is anyone else experiencing said Runtime Errors?

[Zeus]

Forgot to attach the campaign db.xml file.

[dpeters911]

Hi, I was having the same problem.

A possibly fix is to:

close FGII
remove images from folder
reopen FGII
wait for it to save the campaign
close FGII
put images back into folder
start up FGIIThis will remove ALL masks, notes, references, etc. on an image. However, this also clears the issue.

[Zeus]

Thanks for the help.

Tenian also suggested a similar cleans of the campaign's modulesdb folder. My group just finished an adventure module so the campaign is at a point where losing masks and so on is no big deal.

I have my 2nd weekly game later this evening, its using a different campaign to the one thats been prone to the runtime errors. It will be interesting to see if the problem occurs in that one too.

[Zeus]

OK. My 2nd group played a game using a different campaign only to experience the same host crashing issue. So its not looking likley to be campaign related.

I have subsequently reinstalled FGII, created a new campaign (copying over only my characters from the previous campaign) and manually re-adding a couple of campaign images to the new campaign's image subfolder.

I start FGII, open my modules. All good so far.

Fire up another local instance of FGII and connect to localhost. 2nd session connects fine and I select my local DM test character under character selection. Again all good so far.

I then on the host session begin laying out my windows as I would like them positioned and open up the first map image I have to re-mask it. Select the mask tool and then unmask a region of a map that has been semi explored and ...

FGII Application has stopped responding!

Now because I have VS2008 also installed on the same machine the debug exception handler kicks in and offers to fire up VS2008 to run a debug session. As soon as I do I get the following detailed error message:

Unhandled exception at 0x004041ec in Fantasy Grounds.exe: 0xC0000005: Acces violation writing location 0x63b3e38b.

Now as I don't have a copy of the source files on my machine, V2008 is unable to load the symbolic link library to reference the line of code in the source files thats caused the exception to be raised. However it can reference the offending assembly code and does offer a dissambled dump of the exe which I have attached for the devs reference. I'm hoping one of the devs can take the dissassmebled view and cross compare the assembly reference to the disassembled view (with source code) that he/she will have access to.

Any help would be much appreciated as I am truly at a loss as to what could be causing the problem other than FGII v2.6.1 itself now.

[EugeneZ]

Yes, same exact bug I was experiencing. And I bet when you came back in, any mask drawing you had done on that mask was blown away. It was this type of behavior that led me to believe that it had something to do with masks. But I could be wrong, of course, just a guess... it would be nice to have a solution. Whenever I have the issue, I ask my players to reconnect slowly and I try to stay away from masks. One of those two pieces of advice is helping, as we have been able to play, but I'm still nervous about the whole thing...

[Zeus]

The mask wasn't in place when I restarted but that could be because the crash could have occured before the campaign automatically saved.

I agree about images and masks possibly being the cause as its happened twice with masked images now. Is it coincidence that Smiteworks recently introduced the re-mask feature, could this be assoicated with the crashes.

[Zeus]

Appreciating that the recent transition of owners may introduce a delay to getting this issue fixed, I would appreciate an acknowledgement from the current dev(s) that the problem is being looked into.

It would also be good to understand if the level of detailed information recently provided is of any use, for future reference.

Thanks.

[ddavison]

I would be interested to know if you are able to cause the hang/crash as a single user with nobody connected or if it is only with other users connected. The recent bug that I was experiencing caused a crash during the save operation, but the step that preceded the crash was actually related to NPC records with empty formattedtext nodes. I could make it repeatable by performing the operation and then issuing a /save command on the console.

BTW, I found it helpful to first define a /save and a /console hotkey, exit and restart and then I could use them to test saving after each operation. If it crashes, you can look at the latest entry in the console.log by looking in the application directory.

I believe there are several weird issues out here and many of them relate to not finding the expected data within custom rulesets and modules. There might be some other bugs buried in the core code base as well. The problem I see is that the application does not currently generate detailed error messages so it actually becomes a bit of a guessing game to resolve strange issues like this. As I start working with the code more, I want to add error trapping to nearly every operation the program makes to help increase stability.

I have a steep learning curve ahead of me since I just got the codebase yesterday, so unfortunately I can't give a really good ETA at the moment. I will do my best to fit it into my schedule to help resolve this issue for you though.

-Doug

[Zeus]

Doug, many thanks for the acknowledgement and I appreciate it will takes some time to become familiar with the code.

All I can suggest is that now that you have the source code it should be relatively straightforward to run a copy in debug mode and set a breakpoint just after the desktop first initialises, you should then be able to run a disassembly of fantasygrounds.exe and cross compare the instruction at address 004041EC and cross-reference it to the line in the source code that it maps to.

That should at the very least provide an indication as to what function/procedure the exception is raised from. Its then a case of considering all of the conditions that could occur.

As for the crashes themselves they have only occured when I either have other players connected or a 2nd localhost connected session running. They have not occured when running with no one connected so its related to network attached players and conditions that can arise when they are.

Eugenez and I have both experienced crashes just after interacting with map masks, that maybe a good place to start, particularly given that the re-mask/grid features were recently added and crashes have only started occuring from 2.5 onwards.

[Zeus]

Doug,

Have you been able to progress finding the root cause of the host runtime error issue?

I know your have other pressing matters however this is starting to have a negative impact on my group, I really could do with an update. Something at the very least to go back to the other 6 members of the group with.

Our game session was again abandoned tonight due to no less than 7 re-occurences of the host runtime error and crashes. :(

[EugeneZ]

I too have been having issues with this continuously. It bothers me that Zeph and I are the only ones having this problem (not the duplicate nodes one fixed above) because it sounds like it's something we're doing or using rather than a general issue -- I wish knew what.

The last two times it happened for me, it was once again triggered by a player arriving late. The game crashed when he connected or I tried to share the map, don't quite remember which. That has been the consistent reason for seeing the crash, at least the FIRST time in a night: a player connects hours later than everyone else.

After that, we crash soon after connecting every single time, UNLESS I have players connect one at a time. This solution seems to work quite well, actually.

And, as Zeph mentioned, this did not happen prior to the masking functionality being updated in a recent patch.

Sorry if I'm repeating myself, just trying to report my latest experiences with this really, really annoying bug.

[Moon Wizard]

Here is some information that I got from Tenian related to a crash that occurs when using tokens from modules. Perhaps it's related?



In the past few months we've learned a trick to avoid what we lovingly referred to as "token" crash. It happens under the following conditions:

* an NPC is added from a module to the CT
* The client has the CT and map open at the same time
* The token is revealed to the client either by unmasking, clicking the 'show npc' icon or by placing the token onto a revealed portion of the map

So during our sessions when the DM is going to add new npcs to the mix they will announce it. The players close their CTs. The token is added. They can then reopen the CT without issues.

We've been doing that for over a month and haven't had a crash. We had one player forget last week and he crashed on the second or third combat.


Cheers,
JPG

[Tenian]

The "token crash" as we've come to call it, is a client issue. I've never had it crash the host, only the clients. While it is annoying, it's usually quick to recover from as only a few clients typically crash.

I believe the issue Zeph and EugeneZ are reporting causes a crash on the host.

I would think the crash logs would provide some sort of useful information for Smiteworks to debug the problem. Hopefully they could at the very least provide some sort of information on how to prevent future crashes.

[Foen]

{Slightly off-topic}

The token crash might have something to do with client-side code invoking a createNode method on the CT: the client won't have permission to do this on module NPCs, and the code would crash.

[Zeus]

Hey guys,

Thanks for assistance, its much appreciated, I'll try the suggestion of having the players close their CT before I add new tokens to the maps/CT.

I have a game scheduled for Friday this week. I'll update the thread with the outcome following the game.

[Tenian]

If it was the case of the client not having permissions, I would think the crash would be easy to predict. However the token crash has some random element to it. I can have 5 players connected and share a token. Sometimes none crash, sometimes they all crash. Usually it's one or two. And it's not always the same one or two.

I suspect it's some sort of race condition/network issue. It might have something to do with the fact that both the CT and the map display the same token which is loaded from a module.

Maybe I should force load my adventure modules?

[Zeus]

I'm already force loading my core modules, perhaps its tokens that come from a db.xml based module like our MM's?

As for crash conditions, aside from the Runtime crash problem(s) cited in this thread, I also get random crashes when either returning to the launcher or reloading using /reload all command.

The latter is pain in the wotsits when your trying to develop and therefore having to reload the ruleset etc.

[Tenian]

The only time I've ever had crashes on /reload is when I've played with chat_chat.lua or similar parts of the chat system.

For some reason I seem to remember I needed to add a semicolon at the end of a line to make it stable. Normally this is optional but in this particular instance it was required.

If you've made changes to the chat system or overwritten it with an extension you should try using a stock version of the ruleset and seeing if the /reload problem continues.

[Zeus]

The only time I've ever had crashes on /reload is when I've played with chat_chat.lua or similar parts of the chat system.

For some reason I seem to remember I needed to add a semicolon at the end of a line to make it stable. Normally this is optional but in this particular instance it was required.

If you've made changes to the chat system or overwritten it with an extension you should try using a stock version of the ruleset and seeing if the /reload problem continues.

It doesn't crash everytime, only occaisionally.

My house rules mod extension overrides chat_chat.lua and chatmanager.lua, I'll disable the extension and re-try.

[ddavison]

I apologize for the delay in getting back to you. Along with all the contractual, tax, accounting and governmental issues that needed to be addressed, it also took me longer than expected to get my dev environment up and running correctly -- due in part to difference between VS2008 and VS2005. It's going better now, but I also noticed the shear size of the code base. It's quite large. ;)

Anyway, I am testing right now but I don't have the same mod files you have referenced in your campaign. Does the problem occur when you are putting a mask on images within a mod or images within the root campaign, or both? If the system is trying to somehow write back to the mod file, this might be causing the problem if it can't update the mod file on the fly. I will test that area first and let you know what I find. If that is the case, it might be necessary to run the mod unzipped into a folder as opposed to being compressed as a zip with a .mod extension. That is my early "hunch" at least.

[ddavison]

So far I've been unable to reproduce this issue. I tried with a new image loaded in the root campaign image folder and with an image from a module. I had the host app running in debug mode and another non-dev version running as a player on localhost. I edited the mask on both, edited the drawings, cleared both, saved, closed and reopened them, and had it with tokens on and off the map, with tokens locked, unlocked, and practically anything else I could think of. My system is currently running Vista 32-bit with UAC turned off.

It may be important to note that I dragged new tokens from my token box onto the CT first and then onto the map. The tokens were not pre-linked to a personality within a mod or anything.

Are you and Eugene running the same mod file(s) by chance? I would also recommend saving after each step. I put a /save hotkey on my toolbar and hit it after each step when trying to reproduce crash behavior.

[ddavison]

I'm already force loading my core modules, perhaps its tokens that come from a db.xml based module like our MM's?

As for crash conditions, aside from the Runtime crash problem(s) cited in this thread, I also get random crashes when either returning to the launcher or reloading using /reload all command.

The latter is pain in the wotsits when your trying to develop and therefore having to reload the ruleset etc.

There is a memory leak when you go back to the launcher. When I was developing my own rulesets, I noticed that I could only reload about 5 times before my memory usage had grown to high to continue. Then I would close all the way out and get back in. You can see this by keeping task manager open and witness the stepping up of memory usage with each reload or return to the launcher.

[Zeus]

Doug, thanks for coming back to us, I know your a busy man and appreciate you turning your attention to getting a resolution to the problem.

As for the modules, I would be happy to forward them to you, I think I have your email address however I have already forwarded the H1 module to Dupre for analysis so you may want to ask him first.

Was the crash dump dissassembly not of any use to you?

[Tenian]

What problem are you attempting to reproduce? Zeph's host crash or the client "Token Crash"?

If it's the "Token Crash", I've never been able to reproduce it with a localhost client. It only happens to remote clients. Even then it is random.

However if you think it would be helpful to have a crash log from the client, I'll see if I can't cause a crash and grab the log from a client.

[ddavison]

I don't normally work with disassemblies at all. My regular mode of operation is to wrap everything within error handlers and generate a detailed error message that includes the stack trace and offending line numbers and then use that to locate and fix the problem. There is a lot of this that needs to be added.

[EugeneZ]

Doug, thanks for looking at this.

I'm going to try and reproduce this bug reliably to see if I can get exact steps that crash it.

It might be helpful to have a debug build that outputs the information you asked for above.

[Moon Wizard]

Doug,

It might also be useful to have some sort of memory/variable information output (debug mode, warnings on host, ...) to track down potential memory leaks and problem areas for reloads and ruleset use in general.

Cheers,
JPG

[Zeus]

Thanks to Tenian for some assistance I have successfully identifed the root cause of the frequent host run-time crashes under FGII 2.6.x.

The problem is caused by a module I had loaded and activated, my 4E Monster Manual 2. Its a 19MB module containing all monsters from the 2nd volume rulebook. Its 19MB as it contains all monster data and graphics and to keep all encounter references valid includes the entire MM vol 1 as well.

Now the module itself appears fine, I can open and interact with the data with no issues, however if when hosting games I leave the MM2 open and activated (disabled for players) as soon as players connect, FGII will run-time crash with the aforementioned host error at intermittent points of gameplay.

I have successfully hosted 3 games over the last two weeks with no run-time crashes occuring so I am confident this is the cause. I'm guessing FGII 2.6.x's memory leaks might be a cause and even though the module is disabled for players it appears to only come into effect once players are connected.

Doug - I have forwarded a PM containing a link to where you can download the .mod file. You may find it useful in de-bugging the problem. Hopefully you will be able to recreate the crashes.

I'm working around the issue by ensuring the MM2 module is disabled during hosted sessions (its not needed anyway as all adventure mods I use are self contained with all data local), so far its working well.

Thanks to all for the assistance in trying to troubleshoot this problem, my group and I are now enjoying crash free gaming again. :)

[ddavison]

I am glad it is working for you now. Sometimes getting the exact environment replicated in order to reproduce a crash can be the biggest challenge. I'll check the PM.

[EugeneZ]

Brilliant. On Tenian's advice, I too disabled all my modules. I didn't think about it, but yes -- the crash hasn't happened at all since I did that. I only left a few small modules open, as Zeph says, that I made specific to what adventure I was running.

Thanks for narrowing it down for me. Suffice it to say all my testing didn't bear any fruit, since I was so focused on maps/masks being the cause.

[Tenian]

Due to the ease of creating 4E_JPG modules and the fact WOTC publishes a brand new book every month, it is very easy to build quite a large collection of modules.

My guess is having all these modules loaded is exceeding some sort of internal limit.

[EugeneZ]

Sigh. Well, I was wrong before -- disabling modules seemed to have fixed the issue but I've crashed 2-3 times at nearly every single session with ONE of my groups (but not the other!) for the last several months.

There was talk of enabling a log or crash dump in FG2 or do something that might help the developers track down the root cause of this. Is that an idea you might still be open to? I'm at my wits' end with these crashes.

[EugeneZ]

Bump. This is happening over and over and over again. Doug, any chance of some logging or some way of replicating this? It's... killing my games. :(

[Moon Wizard]

While Doug has a chance to figure out what we can do to improve crash identification, let me throw out a few ideas.

* Try moving these directory folders from within your campaign directory to another location(temp, moduledb, maskedimages, drawings). Please keep them for backup. If that does fix the issue, we'd like to see them. This will remove any masks or drawings that you have on your images.

* Also, try moving your chatlog.html and CampaignRegistry.lua files, just in case those might be an issue.

Those changes should bring your campaign to a minimum state, without losing any data (other than masks/drawings).

Thanks,
JPG

[ddavison]

You might also try having all your players delete or rename their campaign cache folder and re-download. If this is a 4E campaign that existed prior to the change from 4E_JPG to 4E, I wonder if there is a problem with one or more players having cached versions of older campaigns.

We are definitely planning on adding better error handling and logging capabilities. Hopefully we can avoid a crash altogether but at least provide better support if one does occur.

-Doug

[EugeneZ]

Thanks. I actually IMed Tenian really frustrated about this issue and he walked me through some similar steps. We narrowed it down to an issue with db.xml. The steps we took to do this were creating a new campaign, had players connect, and everything was fine. Copyed the db.xml from the old campaign and had everyone connect; crash. Furthermore, my players had been reporting longer and longer "wait times" while waiting for their character to show up on the select screen.

The file was 1,551 KB. Once we narrowed it down to this issue, I also realized I'd been relying on modules less and less, making more and more local changes (increasing the size of the db.xml one session at a time). At the same time I'd been adding more and more host tokens. So I spent an hour whittling db.xml down and tossing what I didn't need for the current session and removing unneeded tokens. I whittled the db.xml to ~950 KB.

After I did that, FG2 not only loaded much faster, but the players' characters loaded faster (almost ninstantly). And, of course, it didn't crash, even when everyone connected at once. In older sessions, the only way we could get by not crashing was if everyone connected one at a time.

It seems that something happens between a player connecting and receiving his list of characters in which the db.xml size plays a factor, that, if gone awry, can cause a crash.

I'm just really, really relieved to be rid of this, frankly. I'm guessing to reproduce the issue, just create a very large db.xml file with lots of dummy data and try and have multiple clients connect at once. With a 1.5MB db.xml file it was crashing consistently when the 5th or 6th person connected.

[ddavison]

I'm glad to hear it is working well again. If you still have a copy of your offending db.xml, could you perhaps email it in zip form to [email protected]. We are trying to at least build a log of these issues to work through and debug. Maybe we can find what is taking so long and optimize that part of the code a little better -- or at least build it some better error handling.

[EugeneZ]

Coming your way, Doug.

[Robbo]

I am planning on starting my first campaign this week using EugeneZ's module for the first part of The War of the Burning Sky. I think I'll have 5 or 6 players. I have created a master campaign that only houses my player character sheets. For the adventure I was just planning on using EugeneZ's module. Will this be too large? It would be an utter shame to have to cut the module into pieces, but I want FG2 to make a good impression on my new players, and slow load times/crashes would be a soul crusher.

[EugeneZ]

Modules are fine. In fact, as I mention somewhere in this long thread, my War of the Burning Sky campaign has always been error-free. In light of my recent discoveries, it was due to the *use* of modules that this campaign was okay. It was my other campaign, in which I used modules less and less that the problems began to get worse. Yes, I am an idiot for not realizing the connection far, far sooner.

In other words, yes, you're fine using my Burning Sky modules. Enjoy! :)

[askaval30]

Hello people,

I am a relatively new FG2 DM and have been using the program without much issue for almost a month now, until last session where the dreaded visual C++ runtime error reared its ugly head.

A search of this forum led me to this thread but I'm embarrassed to say that my knowledge of the program is not as comprehensive as it should be and I am unsure reading this thread what the proper solution should be... am I to reduce the number of modules used? remove the images?

terribly sorry to rehash an old problem here but I would greatly appreciate some clarification as to what to do to remove the problem. Thanks!

[EugeneZ]

No problem, askaval, we'll do our best to help you solve your problem.

So far, in this thread, there have been two causes for the Visual C++ runtime error. The first is the use of very large modules with many images. Try playing with no modules, or very few modules, and see how that works out for you. In my case, modules weren't the problem (I wasn't using any particularily large ones).

Rather, it was my "local storage" file, db.xml. To find this file, go to your FG2 data dir (should be a shortcut in your Start Menu > Fantasy Grounds II folder). Go to the campaigns folder and then into the folder for your current campaign. You should see a file called db.xml. What's the size of this file for you?

[askaval30]

Thanks for the prompt reply Eugene!

I'll have to get back to you later tonight about size specifics... not currently at home at the moment.

As far as I can recall the biggest module in my list was 311k, but I have a lot of modules... not all of them open at once, but I'll test it with minimal mods and see if the problem persists.

I do have a metric ton of images in my campaign folder though, So i'll have to get back to you on how big the db.xml file is.

Thanks again for your expert advice!

[EugeneZ]

Images in your images folder shouldn't be a problem (well, with FG2, nothing's ever for sure, unfortunately, but I have a lot of images too, not an issue).

However, if you place tokens on these maps, apply masks, create shortcuts, etc. Basically do anything with the image, that information gets stored in the db.xml. If you've done this with a lot of images, then, yes you may eventually inflate the size of your db.xml file, which may or may not lead to a crash.

Another thing that inflated my db.xml file size was that my players often shared characters. Sharing characters doubles the number of <holder> tags in the db.xml file, substantially increasing the size. In fact, this *may* have been the root cause of the issues (since it was tied to my players reporting long wait times when waiting for their character to show up on the character select screen). Hard to know.

[askaval30]

Alright, checked them tonight and my db.xml is 594k in size... is this bad? and if so how does one go about rectifying the issue? would cleaning out the drawings, masked images and temp folders in that same directory do anything to solve this?

Sorry to keep badgering you with questions by the way, and I am very grateful for the help!

[EugeneZ]

No, that is far smaller than my working file, and far, far smaller than files I had issues with.

Here's what I recommend you do: create a new campaign, then copy only the assets (images, etc) that you *need* into the new campaign. Keep track of what you've copied. If the problem occurs again, then the issue is with one of the resources you copied or something you did in FG2.

Sorry if that's kinda vague. Hopefully someone else can offer some advice.

[gmkieran]

I noticed my name came up in one of the earlier posts in this thread as I was reading through it trying to figure out why my system gave me the C++ error tonight. If I hadn't experienced this problem before, I have now! Unfortunately, my db.xml file is < 500Kb and have had more modules open previously than I did tonight without issue. I did just install the new Treasures/Parcels.ext file that DrZeuss posted recently, but I've also done all kinds of other crazy stuff, so it may be entirely un-related. :(

[EugeneZ]

Can those of you having these crashes please PM me a copy of your db.xml? I'm going to try and see if I can find a similarity to my crashy one.

[EugeneZ]

Okay so I got exactly one db.xml. I looked over the file and even though it was WAY smaller than either my broken or fixed file, it had one similarity: The character nodes were peppered with many <holder> xml tags from players sharing characters. I removed these and sent it otherwise unchanged back to the DM. He didn't have a chance to extensively test it but in short tests it did not crash.

The relationship to <holder> tags would also explain why another symptom of the crashes was that the character select screen took a long time to load (and the crash would occur during the player connection phase around the time this loading occurs).

Doug/JPG, if you guys are interested in solving this issue I recommend starting by having five players all share each others characters (I'd use filled out characters so that there are many <holder> tags for each share) and then having all five players connect to the server at the same time. Replicating this on a local machine with five clients running may not work because part of the issue seems to be speed related -- as in, how long it takes to transfer something related to those holder tags to the clients. Or something.

[Moon Wizard]

When you say sharing characters, do you mean that the GM releases the owner on the characters, and then someone else plays those characters? And this happens for 5 or more users on each character?

I actually have been looking extensively at the database code trying to wrap my head around it and identify areas to improve.

Thanks,
JPG

[EugeneZ]

Yes, that's exactly what I mean. I mean, my campaign that had issues had six players, but our policy was to play if one person was missing.We've been playing this campaign for over a year and a half... so gradually the amount of sharing of characters between people rose. We started crashing around six months ago. The crashes slowly got worse over that six month period until a month ago we literally couldn't play. By the point, the quantity of holder tags on each character was ridiculous. Every single character had been shared by at least four others, some of them by as much as seven or eight (due to past players as well as some players who changed names).

Removing these holder tags completely fixed the issue, so far.

[Moon Wizard]

I already identified one item slated for the next release which should help with the holder bloat issue, but I'd like to get more info on reproducing the crash with the current version.

When you were crashing, when did it happen? Right when a player first connected? After they downloaded? When they selected their character? After you started the game (if so, what did you typically do)?

Trying to reproduce on my machine.

Thanks,
JPG

[EugeneZ]

It always happened when someone connected. I can't say exactly at what point during the connection phase, but typically it was while the player was waiting for his character to show up on the selection screen.

One common scenario we had was a player would arrive late (as in, we were actively playing) and almost without fail, when that player would connect, I would crash almost instantly.

Then everyone would try to reconnect and I would crash again, and again, so I assume the crash was caused, again, by someone during their character selection phase. We never, ever crashed this way when a player wasn't connecting or had just connected.

[askaval30]

Hate to resurrect this, but the problem reared its ugly head again tonight making Fantasy Ground unplayable.

To compound things this was a brand new campaign, with new characters, maps, etc... yet the problem started happening before I even started the adventure, all seeming to begin once one of my characters had finished creating a character.

I read the above responses and went into my db.xml file to deal with the holder tags... but everything in the db seems normal, we hadn't had the chance to try out the characters much less swap them around, so the issue might not reside with the holder tags?

I'll gladly provide the db. file to any of you who is more knowledgeable on the matter, and as always my sincerest gratitude for any assistance you might provide!

[EugeneZ]

Can you send it to me, please?

[email protected]

[EugeneZ]

askaval30 sent me their db.xml file but I couldn't find any similarities to mine (or gmkieran for that matter).

askaval30, there was another issue mentioned in this thread that could cause this crash: the use of very large modules. Try turning off all your modules before your players connect.

JPG is on vacation at the moment but he told me he plans on looking into this when he comes back. We are planning to try our best to reproduce the crash with my file, on his debug system.

[gmkieran]

I just got this error again in the db.xml file that you fixed for me, Z. Interesting to note, what I was doing just before it crashed is probably not something FG would be expecting. I was trying to figure out how to give ownership of Notes to a character (still don't know how to do that) and I figured out that I could add inventory entries to a PC's sheet and then link those to Notes entries. After adding several I closed the character, no problem. I closed the Notes and FG crashed. I also had open an instance of the CT (populated with 5 NPCs from the MM) and a map with tokens linked to that CT. Prior to messing with the Notes, I had created an encounter, populated it with the above MM NPCs, populated the CT and set up the map. There were no clients connected at the time, just my host session and there has been no sharing of characters since you sent the db.xml back to me (I'm not even sure we've played since then, honestly). FG re-started normally and the Notes entries remain in the sheet I added them to. No idea how this might be relevant to anything that's been suggested as a source of this error, but I figured I'd throw it into the mix as one more data point.

[Zeus]

Notes are owned by the person who created them, so for example if your players were to create a note it would appear in the list with their name in [] brackets.

Notes are then shared to everyone else by right clicking and selecting share from the menu. The GM will automatically have access to all notes whilst players will have access to i) notes they created and therefore own and ii) any notes that have been shared to them.

Your approach to Notes is indeed not quite in line with what was intended for their use. I think having GM owned notes attached to PC charsheets may cause problems however in theory once the node(s) and data are written to the DB if the parent node is accessible by the player (in this case yes as its the charsheet) then all subnodes are made accessible as well. So perhaps it will be fine. I would test by connecting a localhost client and joining the campaign as a new player. Open the PC charsheet containing the notes as the player and see if FGII complains/crashes.

Regarding the continued crashing of FGII, try restarting your campaign but this time first close ALL your open modules. If you experience no crashes then you may have hit an issue similar to the one that caused me headaches last year. Large modules that contain suppressed content (in my case my MM2 module which contains suppressed MM1 content) seem to cause FGII some challenges.

If you continue to experience crashes then its worth re-submitting your campaign file here so that others can try to reproduce the problem. The more data that can be collected the easier it should be to spot any common denominators.

[gmkieran]

What was odd about the notes is that all ownership seems to have been removed, so that even the creators no longer had access. I can share them, but I wanted to re-assign them to their creator. To be safe, I'll probably just delete the entries on the character sheet's inventory tab.

That said, i remembered the module issue from reading through the thread and closed everything except the PHB and PHB2 - once I did that, no more crashes. I don't even use MM2, so I will probably just remove that from my modules folder entirely (along with a bunch of other things I just don't need right now).

thanks, again, DrZ!

[Zeus]

Your welcome, glad it helped.

For reference, as the DM for my groups, the only modules I have open is the current adventure module and a couple of campaign modules. My adventure modules are self contained, so once they are built there is no need to have DM rulebook modules open.

As the DM you rarely have to have the player guides open (unless your looking up a rule etc.) so by default I just simply don't have them open. As long as you have enabled access for them, your players will still be able to reference them regardless.

[askaval30]

So last night it happened again... first to two players, and we closed all maps, modules and CT while we waited for them to log back in. A few minutes later my host got the error and crashed... FG is a wonderful program but this is getting tedious...

I was wondering if deleting the contents of the "temp" folder and "maskedimages" one might help... is this advisable or could it just opening another world of hurt?

Sorry to keep bringing this up... I would like nothing more to make this thread vanish for good, but as of now my group and I are at a loss as to how to prevent these crashes from happening.

[Moon Wizard]

From what I can gather, most of the crashes are occurring when using tokens provided inside modules. Or, they are occurring when loading up 12-20 modules.

Can you confirm whether you are using any modules with tokens, or are all of the tokens you are using in the FG application data folder under the tokens subdirectory? Also, how many modules are you loading?

Thanks,
JPG

[askaval30]

Can you confirm whether you are using any modules with tokens, or are all of the tokens you are using in the FG application data folder under the tokens subdirectory? Also, how many modules are you loading?

Thanks,
JPG

I used to usemore than 12 modules, but have limited myself to a couple in the last sessions. The adventure modules I use does have tokens but they wouldn't add themselves to entries in the CT, so I'm using them from the data folder instead.

hope that helps!