After recently updating Chrome, I ran into certain sites hard-crashing the entire application on certain actions. I’m not talking about the “this tab has crashed” message, I’m talking acts-like-a-kernel-panic, no error shown, every single tab and entire app window exists type crash. Understandably, I got frustrated, but I never like being one of those people that just complains without knowing why, so I wanted to see if I could dig a little deeper. Trying to use Chrome’s dev tools panel wasn’t much help as, well… it crashed along with the browser whenever this happened. So next I looked to using Chrome’s crash reports.
Using Chrome’s Crash Reports:
A quick Google search pulled up this SuperUser post, that says you need to enable the sharing of usage stats and crash reports with Google Corporate in order to use them, which I did not want to do. However, I noticed that even with that setting off, and and chrome://crashes/ showing “Crash reporting is disabled.”, the actual crash dump files were being generated and saved anyways. I found them in “C:\Users\[USERNAME]\AppData\Local\Google\Chrome\User Data\Crashpad\reports”, but your location may differ. They are saved as files with the “DMP” extension, which would indicate “Dump files”, but they are actually “minidump” files, which I confirmed by checking the magic bytes (first 6 bytes read as “MDMP“§”) and then referring to the readme for Crashdump and Breakpad, which are the Chromium tools that actually are responsible for saving and generating the files.
(EDIT: This helpful page from Chromium on Crash Reports cleared this up more. Breakpad is what used to be used, but is getting replaced by Crashpad, which is now used by default on Windows and Mac.)
Now how do we read these files? If you are a newbie to this part of software, like I am, you might be a little lost. The page from Chromium on decoding crash dumps makes it kind of sound like this is impossible to do on Windows and requires very specialized Unix tools. However, this is not true; minidump is a standardized dump format, actually created by Microsoft for Windows specifically, and there is more than just one tool to analyze them. On Windows, the default tool to use is WinDbg, which you might already have on your computer if you are a developer; it is available as part of the Windows 10 SDK. The full installation guide is here. WinDbg is also not the only program out there to analyze minidumps – for example, whocrashed.
Without any special setup, simply loading the minidump from Chrome into WinDbg on my machine let me see a lot of helpful details; the most helpful being the call stack. I could see that in every single of my 10+ crashes, the same exact function call was triggering the crash; blacklist::SuccessfullyBlocked(). This is a function that triggers when Chrome’s anti-DLL-injection blacklist records that it successfully blocked a “rogue” DLL from injecting code into the browser. I’m going to have to do some more digging, but this is probably related to the real-time web browsing protection offered by my antivirus.
If you want a more in-depth experience with WinDbg, definitely read the docs on WinDbg, and at a minimum, you might want to enable symbol resolution by providing WinDbg with some symbol paths. For example, to pull in symbols for Windows API and Chrome, and I used this command to set the symbol file path:
.sympath srv*c:\symbols\chrome*https://chromium-browser-symsrv.commondatastorage.googleapis.com/;.symfix+ c:\symbols\ms
After which, you can use
.reload
and then
!analyze -v
to run a quick analysis.
Another option for trying to examine Chrome crashes is through logging.
Using Chrome Logs
To run Chrome with error logging on, where it logs critical errors to a specific file, use this command flag when you start the application:
--enable-logging --v=1
In Windows, you can save the flag with the shortcut for the application, or even save it is a separate shortcut, so you can choose at any time to launch the non-logging version of Chrome versus the logging one.
Once logging is set up, you can view the log file, likely at C:\Users\[USERNAME]\AppData\Local\Google\Chrome\User Data\chrome_debug.log
You can also use an application called Sawbuck (also made by Google) that can show you logging entries in realtime, and let you filter on levels. See the Chromium page on logging for details.
In my scenario, the log did not help or turn up anything useful, as the crash was actually happening so fast, nothing about the crash itself was getting written out to the log before the application exited completely.
Update: A further note about DLL injection
Another resource to check for which installed DLLs are potentially injecting code into Chrome and could cause a conflict, is this internal Chrome page – chrome://conflicts/. Mentioned here.
