New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 824894 link

Starred by 1 user
Status: Assigned
Owner:
brucedaw...@chromium.org
Cc:
█ mosescu@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature



Sign in to add a comment

--disable-breakpad should let crashes flow to Windows Error Reporting

Project Member Reported by brucedaw...@chromium.org, Mar 22 2018 
breakpad/crashpad are great but they only record minidumps, not minidumps with heap, and may omit other information that Windows Error Reporting records. This is particularly problematic when dealing with the out-of-memory crashes that I occasionally see on my home computer. While these are probably due to bad websites with JavaScript memory leaks it could still be useful to get full crash dumps.

This can either be done by giving crashpad the option to record full crash dumps or, more easily, by having --disable-breakpad cause crashpad to ignore crashes so that they are handled by Windows Error Reporting, as described here:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Comment 1 by brucedaw...@chromium.org, Oct 2

Cc: mosescu@chromium.org
InitializeCrashReporting (browser process) ignores --disable-breakpad. The call stack that gets to this function is here:

>	chrome_elf.dll!crash_reporter::internal::PlatformCrashpadInitialization
 	chrome_elf.dll!crash_reporter::`anonymous namespace'::InitializeCrashpadImpl
 	chrome_elf.dll!crash_reporter::InitializeCrashpadWithEmbeddedHandler
 	chrome_elf.dll!ChromeCrashReporterClient::InitializeCrashReportingForProcess
 	chrome_elf.dll!elf_crash::InitializeCrashReporting
 	chrome.exe!wWinMain

InitCrashReporter (renderer process) pays attention to --disable-breakpad, but that is insufficient.

It's fairly straightforward to get wWinMain in chrome_exe_main_win.cc to not call SignalInitializeCrashReporting if kDisableBreakpad is specified (although it does mean initializing crash reporting slightly later, which is not ideal) but I'm still not getting crash dumps in %localappdata%\crashdumps - the WER process doesn't run when the crash happens.

Any ideas on where all the hooks are that try to capture crashes?

Comment 2 by mosescu@chromium.org, Oct 2 

Thanks Bruce, I agree this is a good idea. 

We also have http://crbug.com/crashpad/239, which pretty much says the same thing but with a new --disable-crashpad switch to avoid any confusion.

Comment 3 by brucedaw...@chromium.org, Oct 3 

It looks like the sandbox prevents WER from working. If I unconditionally crash in wWinMain then I get crash dumps from the browser process recorded by WER. If I crudely detect the renderer process at the earliest possible moment:

#if !defined(WIN_CONSOLE_APP)
int APIENTRY wWinMain(HINSTANCE instance, HINSTANCE prev, wchar_t*, int) {
#else
int main() {
  HINSTANCE instance = GetModuleHandle(nullptr);
#endif

  wchar_t* p = GetCommandLine();
  wchar_t* pType = wcsstr(p, L"--type=");
  if (pType && (wcsncmp(pType, L"--type=renderer", 15) == 0))
    __debugbreak();

I get no crash dumps. I don't see a way around this. Maybe the better option would be to support some way of asking crashpad to save full memory dumps, perhaps a registry key. Or perhaps it's not important enough. Thoughts?
►

Sign in to add a comment