You can troubleshoot problems with Chrome browser, such as hanging tabs and error messages. Use debug logs to help you. These logs aren't generated automatically. You need to turn on logging first.
Turn on logging
Note: Instructions assume that Chrome browser is installed in the default location.
- Quit any running instance of Chrome.
- Right-click your Chrome shortcut.
- Select Properties.
- At the end of the Target: line, add the command line flags:
--enable-logging --v=1
With that example flag, it should look like:chrome.exe --enable-logging --v=1 - Click Apply
OK. - Launch Chrome using your shortcut.
OK.- Quit any running instance of Chrome.
- Run the terminal application.
- In the terminal, run the command:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-logging--v=1 - Press Enter.
- Quit any running instance of Chrome.
- Run a terminal emulator.
- In the terminal, run Chrome with the flag:
--enable-logging--v=1 - Press Enter.
Debug logs are stored in the user data directory as chrome_debug.log. The file is overwritten every time Chrome restarts. So, if you have an issue with the browser, check the log before you restart Chrome. You can stop the file from being overwritten by moving it to the desktop.
The location of the directory depends on the operating system. For information, see User Data Directory.
Read the logs
Tools like Sawbuck on Microsoft® Windows® or Console on Apple® Mac® (located at Applications > Utilities > Console) can help you read the logs and find the source of a problem. These tools present the logs in a graphical user interface that you can easily view, filter, and search.
You can also open the file in a text editor and use the information below to identify problems.
What to look for
The first thing to look for in the chrome_debug.log file is the ERROR keyword. However, depending on the issue, this might not be the root cause. For example, if a user reports excessively long start times, you might see repeated lines at the beginning of the debug log or a high number of process IDs (PIDs) or thread IDs (TIDs).
Each line of the log file begins in a time-stamp format with the following elements:
[PROCESS_ID:THREAD_ID:MMDD/TIME:LOGGING_LEVEL:SOURCE_CODE_FILE_NAME(LINE_NUMBER)]
For example: [7352:11760:0809/012714:VERBOSE1:resource_loader.cc(630)]
-
PROCESS_ID: The identifier of the process that's currently running.
-
THREAD_ID: A process within a PID.
-
MMDD: The current month and day. In the example above, it's August 9.
-
TIME: The current time in a 24-hour format of HH:MM:SS, which will help you narrow your search to the time an issue happened.
-
LOGGING_LEVEL: The current level of logging. This is usually VERBOSE1 as set by the command line. You might also see occurrences of ERROR.
-
SOURCE_CODE_FILE_NAME(LINE_NUMBER): The name of the source-code file that triggered the event to be logged.
Was this helpful?
How can we improve it?
