Fantasy Grounds and Chrome causing BSOD

[chiquit]

Hi everyone,

This is a random, localized issue. I am one of five players and the sixth being the GM. I also run a game and have four players. In both cases, if I run Chrome (Or Firefox) at the same time, my system will eventually Blue Screen of Death with a fairly generic video card error. I am the ONLY person to have this issue. Others will have Fantasy Grounds crash or error out from time to time when the resources get too big across our GMs poor network, but nobody else crashes. They all can use browsers without issue. Some info about this issue from my investigations:

• There are no events generated in event viewer except the generic blue screen video card error
• Fantasy Grounds generally will take up about 4GBs of RAM
• I am running three monitors and if I pull Fantasy Grounds across at least two of them, it seems to speed up this BSOD
• I highly doubt it's a system specs issue (Nvidia Titan, i7-4770, 24GB RAM, Win 10 Pro (x64 of course))
• In Chrome, I do tend to have many tabs running, but it can BSOD with as few as one tab
• In Chrome, there is no hardware acceleration being used, but when I do use it, it does appear (speculative) to make the BSOD occur sooner
• This may be speculative and reaching, but I THINK it might occur faster if a stream or other video related item is running in the browser
• This does NOT occur when I have PDFs up in Adobe Reader, MS Word, and Steam running while using FG
• I can have multiple non-FG games running along with 30+ Chrome tabs running streams and other things and have never seen this same error happen otherwise on this system (To the point of crashing Chrome or a game or something)

I know it is a long shot, but I am hoping someone can help.

[Trenloe]

I don’t know about the blue screen of death, but FG will definitely experience issues above 3.5GB of RAM and will crash soon after. If you’re seeing 4GB of RAM use you need to reduce the resources you’re using (tokens, modules, large maps, etc.) to bring it down below 3GB for reliable use.

FG is a 32-bit application so is limited to less than 4GB memory use on a 64-bit operating system, it doesn’t matter how much memory you have in your computer.

Stop the FG overload issue first and then see if you still have BSODs.

[JohnD]

You have too much on the go in general, but specifically within FG if you are using that much ram.

[Zacchaeus]

Indeed, it is the RAM issue that is the problem. Since you are the player it will be your GM that needs to cut down on what he is sharing as well. As Trenloe says, have him unshare un-needed modules and images (especially maps), and extensions and especially don't share tokens. Once he has slimmed down his campaign nuke your cache before rejoining his game.

[chiquit]

All, thanks for the responses. I must apologize as I rounded up to 4GB. It's hitting the limit of 32-bit, now that I see it directly. But would that seriously cause a BSOD?

One key issue here is how quickly the memory sky rockets. After having detailed out people and places in a single major plotline based city, we can easily kick FG up to 2.5 GBs of RAM used. Add in a single, large dungeon map and boom, it's already nearing the limits. What should I and the other GM be doing to properly cut down RAM utilization for our players (and ourselves)?

Further, when could we get a 64-bit version of this application? Am I alone in thinking it's a bit unrealistic to have a fairly RAM inefficient application like FG not moving to 64-bit memory addressing? I'm sorry if that sounds rude, that is not how I intend it to sound. Simply asking the questions for the betterment of all.

[Andraax]

All, thanks for the responses. I must apologize as I rounded up to 4GB. It's hitting the limit of 32-bit, now that I see it directly. But would that seriously cause a BSOD?

Yes. From looking over all the posts, I would say that it's likely your video driver doesn't handle low memory situations well. Make sure you have the latest video driver loaded for your card.

One key issue here is how quickly the memory sky rockets. After having detailed out people and places in a single major plotline based city, we can easily kick FG up to 2.5 GBs of RAM used. Add in a single, large dungeon map and boom, it's already nearing the limits. What should I and the other GM be doing to properly cut down RAM utilization for our players (and ourselves)?

Check your image sizes and number of open modules. But usually the biggest hit in terms of memory is the number of tokens. I just keep a minimum of tokens always loaded, and load other tokens as needed for an adventure.

[Trenloe]

Tokens and the size of shared images - even if the tokens and images aren't currently open they will be using resources on the players side. Unshare images that are no longer used and drastically reduce the number of tokens in the tokens\shared directory.

Maps/images should be kept as small as possible with a maximum recommended resolution of 2048x2048 pixels.

There is not a 64-bit version on the horizon. A lot of us thought the the move to Unity would bring 64-bit architecture to FG, but we've recently been told it won't - due to 32-bit libraries and the multi-platform support. But the devs are working hard on making the memory management a lot more efficient in FGU.

[chiquit]

Yes. From looking over all the posts, I would say that it's likely your video driver doesn't handle low memory situations well. Make sure you have the latest video driver loaded for your card.
Check your image sizes and number of open modules. But usually the biggest hit in terms of memory is the number of tokens. I just keep a minimum of tokens always loaded, and load other tokens as needed for an adventure.

Yes, my video card drivers are most certainly up to date, as well as all other drivers and the BIOS for good measure. Given that it is a Titan video card, I'm sure the card itself isn't out of memory, so that would mean the video memory for that particular process is maxing out. However, in this scenario, it should only be that that application crashes. Why would it BSOD the whole system? Further, what does Chrome have to do with it? As I stated before, it ONLY crashes when I have a browser running too.

Tokens and the size of shared images - even if the tokens and images aren't currently open they will be using resources on the players side. Unshare images that are no longer used and drastically reduce the number of tokens in the tokens\shared directory.

Maps/images should be kept as small as possible with a maximum recommended resolution of 2048x2048 pixels.

There is not a 64-bit version on the horizon. A lot of us thought the the move to Unity would bring 64-bit architecture to FG, but we've recently been told it won't - due to 32-bit libraries and the multi-platform support. But the devs are working hard on making the memory management a lot more efficient in FGU.

I'll push this on to the other GM, as well. It's an extreme sad shame that we can't move on to x64. This would dramatically improve the speed of the application and remove these artificial RAM limits.

All said, the original issue still stands of why does it BSOD the system ONLY when I have a browser (Chrome, Firefox, etc) open as well?

[LordEntrails]

Their have been other reports of Chrome impacting the performance of FG. But no root cause was identified. I think a third application(SVN?, Bitbucket?) was mentioned as being part of the equations and for at least one person they reported the problem went away when they updated the other program.

Given that you have identified that it is a graphics issue and seems to be related to the number of screens in use (or FG is stretched across) makes me think it a graphics driver issue. FG uses an old version of DirectX. Many of the latest/greatest video cards often have problems running at their best performance and using old versions of DirectX or other graphic renderers.

As mentioned, the first thing you need to do is get your FG process size below 3GB. Then if the problems persist I would look at lowering your graphic drivers performance settings. The third area I would look at is what is running in all those browser tabs? If one or more of them are using graphic's renderers like Silverlight, Flash, etc, then I would look at that. It may end up that certain combinations of things between various applications are just not going to work with your hardware and drivers, etc.

Moving on to x64 architecture is not simple or easy. It is something desired by the developers as well as many GM's, but it's not priority one. It will happen in time, but their are other things that must be done before they can do that. And the big one is to move to an architecture (Unity) that makes such a move even possible. But once on Unity, they still have to look at all the various libraries used by FG and see if they have 64 bit versions. I have faith it will happen (because FG is very well managed I believe it will be around for decades to come, and therefore it will migrate to x64) but it won't be this year and I doubt next.

[Andraax]

Yes, my video card drivers are most certainly up to date, as well as all other drivers and the BIOS for good measure. Given that it is a Titan video card, I'm sure the card itself isn't out of memory, so that would mean the video memory for that particular process is maxing out. However, in this scenario, it should only be that that application crashes. Why would it BSOD the whole system? Further, what does Chrome have to do with it? As I stated before, it ONLY crashes when I have a browser running too.

Because drivers typically run in kernel space and therefore can hose the whole system if they have a problem. I have had bad drivers cause BSODs numerous times. Also, while the card itself uses on-board memory, the *driver* does not. It relies on system RAM. Chrome is a bit of a memory hog as well, especially when you have multiple tabs open simultaneously.