Advanced lighting model crashes viewer

[Suki Hirano]

After extensive testing I've concluded that enabling advanced lighting model will guarantee to crash my viewer, both Firestorm and the vanilla linden viewer. The error is the form of a brief freeze, then the error popup "Firestorm.exe has stopped responding", clicking OK would shut down the process.

• The odd thing is that this usually only happens in a few sims, such as (unfortunately) my home sim
• Even more odd is it rarely if ever happens in crowded regions such as shopping events, which leads me to conclude it's not related to computer specs
• Enabling advanced lighting model has little negative impact on FPS, which means my computer has no issues handling it in the GPU department
• The crash happens randomly. Sometimes only takes 10 seconds. Other times might take 20min before crashing
• Decreasing draw distance/LOD/spinning camera around has no effect on crash
• Nvidia drivers all up to date. Already tried reverting to a few older versions, no effect
• Increasing TDRDelay to infinite or a higher number in regedit does not prevent crash, but would simply CTD the client without any error
• This crash only started happening after one of the major viewer patches about half a year ago

This leads me to think some rezzed objects at my home sim is causing the crash. Other than removing every single rezzed item at my home sim which is the absolute last resort, anyone have any idea what might be causing this? Firestorm support didn't have any idea about it.

Edited December 22, 2017 by Suki Hirano

[Klytyna]

33 minutes ago, Suki Hirano said:

Firestorm support didn't have any idea about it.

Go to one of the places you DON'T automatically crash in, find the "Object to Object Occlusion" setting (usually off the Developer Menu), turn it off...

See if that fixes it. Lots ob objects close together in the build, + O2O occlusion, + ALM can sometimes severely overload your viewer and cause lag spikes that end with you disconnected, black screen lag spikes, and / or crashes, especially if your RenderVolumeLodFactor is set too damn high (ie standard FS user lodfactor 4).
 

[Suki Hirano]

23 hours ago, Klytyna said:

Go to one of the places you DON'T automatically crash in, find the "Object to Object Occlusion" setting (usually off the Developer Menu), turn it off...

See if that fixes it. Lots ob objects close together in the build, + O2O occlusion, + ALM can sometimes severely overload your viewer and cause lag spikes that end with you disconnected, black screen lag spikes, and / or crashes, especially if your RenderVolumeLodFactor is set too damn high (ie standard FS user lodfactor 4).
 

Developer -> rendering -> object object occlusion?

Disabled it but still crashing. =/

Edited December 23, 2017 by Suki Hirano

[Whirly Fizzle]

Can you give a SLURL to one of the locations you can reproduce this?

Have you tried a cache clear yet?
I know a cache clear is wrongly recommended as the miracle "fix it all" for all manor of problems, but in this case it's worth a shot.
It's possible that you have corrupted slc files in your object cache for certain regions.  If you do, then as soon as the viewer renders the "problem" object, you'll crash & this kind of crash is often  "viewername.exe has stopped responding"  rather then a clean crash to desktop.

If a cache clear doesn't help, do you know how to find your viewer log files?
I suspect there won't be a dmp for this crash but maybe the session log will give a clue to the problem.

Edited December 23, 2017 by Whirly Fizzle
typo

[Suki Hirano]

1 hour ago, Whirly Fizzle said:

Can you give a SLURL to one of the locations you can reproduce this?

Have you tried a cache clear yet?
I know a cache clear is wrongly recommended as the miracle "fix it all" for all manor of problems, but in this case it's worth a shot.
It's possible that you have corrupted slc files in your object cache for certain regions.  If you do, then as soon as the viewer renders the "problem" object, you'll crash & this kind of crash is often  "viewername.exe has stopped responding"  rather then a clean crash to desktop.

If a cache clear doesn't help, do you know how to find your viewer log files?
I suspect there won't be a dmp for this crash but maybe the session log will give a clue to the problem.

Yeah tried cache clear many times, didn't help. Neither did a clean re-install.

There are two logs that are updated at the time of crash, crashreport.log and firestorm.log.

Crashreport.log: https://pastebin.com/eATqegYz

Firestorm.log is way too large to paste, is there anything I should be looking at?

 

Edited December 23, 2017 by Suki Hirano

[Whirly Fizzle]

The Crashreport.log isn't any use, it's just the logging for the crash reporter itself.
The juicy bits for a crashed session are the actual session log (firestorm.log if you didn't relaunch the viewer after the crash) & the dmp file.
Each session, there will be a new dump folder created in the logs folder.
If the session ends cleanly, the dumo folder will be cleaned up.
If the session didn't end cleanly, the dump folder will remain & will contain, among other things, the session log & a dmp file if the viewer actually crashed (as opposed to a disconnect or freeze).
I suspect for your "Firestorm.exe has stopped responding" crash though, the session log will just cut dead & not register a crash & there will be no dmp file.
If there is a dmp file, if you can upload that to dropbox or similar, I'll be able to get a callstack for the crash.
The whole of the session log from a crashed session would be handy. If you can upload the firestorm.log file BEFORE you relaunch the viewer the next time you reproduce this crash.

Do you happen to have Visual Studio 2013 or WinDBG installed on your system?
If the viewer isn;t generating a dmp file for this crash, there are other ways to get a stack, to see what's causing the crash.

[Suki Hirano]

You're right, there's no standalone .dmp file nor a dump folder created upon a crash.

Here's the full firestorm.log: http://www.mediafire.com/file/d7vcc1iv4bzqap9/Firestorm.log

Edited December 28, 2017 by Suki Hirano

[Whirly Fizzle]

Thanks.
I can't see anything wrong in the session log at all, apart from a couple of minor issues that won't be related to the crash/freeze problem (viewer fails to connect to win_crash_logger.exe process on startup & for a while during shopping, the local inventory got out of sync with the server inventory - relog would have fixed that if it didn't right itself).
The previous session ended in a freeze & the log just cuts dead for this session, so either you were still logged in or the viewer froze & never recovered.
Just before the end of the log, you'd changed some graphics preferences - if that's when you enabled ALM, then the freeze was seconds after that.

Your system should handle ALM without any problems going by the specs in the log.

On 22/12/2017 at 4:27 PM, Suki Hirano said:

Increasing TDRDelay to infinite or a higher number in regedit does not prevent crash, but would simply CTD the client without any error

^ When you do this, do you get a dmp file generated for this crash? Without a dmp file & no clue in the session log, I'm afrid I have no way to tell what's wrong.

Have you checked that your system isn't overheating?  Possibly enabling ALM is enough to push the temp over the edge.

Would you be up for running the viewer through a debugger so you can get a dump when it crashes?

[Penny Patton]

I know that avatars and sims with really, really excessive VRAM use (even for SL) would crash me consistently on 32Bit clients (like LL's and Black Dragon) but it's my understanding this is solved in 64 bit viewers like Firestorm. Although, I imagine it just kicks the can further down the road and as content gets more absurdly unoptimized the problem can surface again on 64bit viewers. I don't know that this is the issue here, but figured it was worth mentioning the possibility. Of course until LL rolls out the new VRAM tools it won't be possible to check avatars or environments for their VRAM use.