Over the years I have seen Second Life™ and the viewers we use change. Computers, screens, speakers, joysticks, and video cards have all advanced as well. But when things go wrong the types of problems and how to troubleshoot them has remained mostly the same. And when it comes to “which viewer” they are all the same for troubleshooting purposes.

We now have Artificial Intelligence (AI) and it is advancing. It is possible to use AI to help troubleshoot. But it can add some complication. But give it a try.

Here I’ll cover the basic and advanced steps needed to troubleshoot issues. Basic understanding of where a problem may exist can save you days of work… literally

Do you actually have a problem?

There are ‘problems’ and there are ‘glitches’. Problems are persistent. Glitches are transitory. They do not repeat, consistently.

Glitches are fixed by shutting down the viewer and relaunching. This is normally the first step in troubleshooting. Some glitches confuse Windows/Apple operating systems and the computer needs to be restarted, second step a issue persists. Network glitches are fixed by restarting your modem/router/gateway device, often the third step.

The point here is these steps are easy and quick.

If after the restarts the problem persists then you have a ‘problem’.

Where is the problem?

There are ‘places’ in which problems fall. That determines what needs to be done to find the cause. The ‘places’ are; the computer, the viewer, the network, and the SL servers.

At this point you need to be using your brain. The computer and viewer are closely tied together. So, one needs to figure out if the computer or viewer is the problem.

We do that easily by having two different viewers installed. The default viewer is the SL Viewer made by Linden Lab. This is the “default” troubleshooting viewer for everyone using a third party viewer. The reason is because if you have to resort to official Second Life Support, they require you to be using the SL Viewer.

If you use the SL Viewer as your main daily use viewer then you need to have one third-party viewer installed. It is your choice as to which one.

Once you have restarted your main viewer and the problem persists, close it. Start the alternate viewer. If the problem disappears, then it is likely in your main viewer. If the problem remains, it more likely is the computer. But we know it is unlikely your main viewer. This means working on or replacing your main viewer is unlikely to help. No re-installs needed.

If you haven’t, then restart the computer. Be sure all the Windows/Apple updates are installed. Make sure your Nvidia/AMD video drivers are up to date. See:

https://www.nvidia.com/en-us/drivers

https://www.amd.com/en/support/download/drivers.html

Is it me?

When the problem in not your computer or viewer then we look at the network and the SL Severs. The quick check is to look at: https://status.secondlifegrid.net/

It can take some time for the Lab to realize they have a problem. So, the Grid Status page lags behind RL. So, check the SL forum. Look in the Answers section of the forum: https://community.secondlife.com/forums/forum/109-answers/

If the SL world is down, you will see posts popping up in the forum with people asking.

If SL is not completely down, people will be asking if there is a problem in the in-world groups.

This doesn’t help if you cannot login. So, then you ask in SL Support: https://support.secondlife.com/ Plus there are a number troubleshooting steps listed on the Support page for specific problems that you can try.

If none of that is revealing a problem on the server side then consider your network connection. Just because you can browse the net or connect to the forum doesn’t mean you have a good connection to the SL Servers running the virtual world.

Then consider: Troubleshoot Your #SL Connection an article I wrote in 2011.

Still need more HELP?

When all else is failing and when you and those helping you have no clue, look in the viewer’s log files. The viewer has various log files you can read to get an idea of what has gone wrong. Look at the log immediately after you crash or exit the viewer. Logs are replaced the next time a viewer starts. You’ll find the logs in:

Windows: C:\Users\[Win_login_ID]\AppData\Roaming\SecondLife\logs\

Mac: /Users/<username>/Library/Application Support/SecondLife/logs

You will need to change folder and file names depending on the viewer you use (like: \SecondLife\ may need to be \Firestorm_x64\). But, the pattern for the path is similar for all viewers.

• crashreport.log – This log is generated when the viewer crashes, the previous version of the file is overwritten. Rename this file if you plan to restart the viewer before examining the file. Otherwise, just read it with a text viewer (Notepad is good enough).
• debug_info.log – This file is internally formatted as an XML file. I never find it of much use. It is mostly the specs of your machine.
• SecondLife.log – This is the main log file. I find it the most useful. Start from the end of the file and work toward the beginning. Search for ‘WARNING’ and ‘ERROR’. With any luck, the messages there will give you an idea of the problem. Recent changes have added a section heading to parts of the file that can identify the general nature of the problem. There are lots of performance stats included.  At the end of a non-crash log, there are secession stats;  Run Time, Average Packet Size, Dropped Packets, Resent Packets, etc. The file is replaced and recreated for each viewer’s secession.
• SecondLife.error_marker – I don’t know what information is inside. I don’t have a copy to examine as I write this.  The presence of the file indicates where, when, and what error happened. I think this is a disaster backup file for crash reporting in which information about the crash is retained in the event the crash handlers are destroyed before they can create the other more complete crash files.
• SecondLife.start_marker – There is no information inside. The presence of the file indicates how far into the start process the viewer has gotten. Whether the file exists or not is the pertinent information.
• SecondLifeCrashReport.log – This is another file internally formatted to XML.  It is created when the viewer crashes. I think this is the new version of the crash log. It is mostly text.
• stats.log – This is a short file containing network statistics. Similar information is in other log files. It is an easy-to-read set of stats that show how many packets were dropped and resent in a secession.

I find the SecondLife.log is the most useful file for tuning and troubleshooting the viewer. It is verbose and reasonably easy to understand. There is a Debug Setting that allows you to increase or decrease the level of reporting. If you are really struggling, increase the verbosity.

Most of these files are erased when the viewer starts. If you plan to send the files in with a trouble ticket or bug report, place copies in another folder before starting the viewer.

Marker files are temporary and may or may not exist at any given time.

Entries in the log files that are associated with errors and warnings are labeled as such. That makes them easy to find by searching using ‘warning’ or ‘error’. Search and read through them starting at the end of the file and working backward. Hard crashes may shorten the file not properly closing it. So, the error you need to know about is likely at the end of the file.

Warning entries are common and do NOT necessarily mean there is a problem. Some warnings are a part of normal operation. Some errors are trivial and do not indicate a ‘noticeable’ problem in the viewer’s operation. To get s sense of this you need to study the file when the viewer is working normally. Basically, you can ignore most warnings.

Hopefully you find an error and can make a fix or ask for specific help.

About clearing the CACHE!

OMG! If anyone tells you to do this, RUN! Clearing the viewer’s cache is old advice that was good a decade ago. But sounds cool and is easy to say and remember. Unfortunately it is horrible advice.

The Lab spent a lot of time fixing cache corruption problems and speeding up the cache. Only in extremely rare cases will there be a problem in the cache. But if you want to do SOMETHING… cause you can’t think of anything else… then clear the cache and degrade your performance. It is unlike to help but you will have done something.

Asking for Help!

The SL Viewer help is supplied by the Lab. Premium members can call for support or file trouble tickets. There is no in-world support.

Concluding

These steps should get you going or well on the road to recovery from a problem or glitch. Good luck. Viewers have other issues, slow, laggy, poor render… etc., etc. These are problem you can get help with in-world or on the forum.