If there's anything I can do to help debug this, please let me know. I'm a programmer so I have windbg, etc. installed.

cameron314@ Thanks for the issue.

Tested this issue on Windows 10 and Mac OS 10.13.6 on the reported version 65.0.3325.181 and the latest Canary 67.0.3395.0 and unable to reproduce the issue.
Able to uninstall and Install Chrome without any issues and no crashes are observed.

Request you to provide the Crash ID from chrome://crashes which will help in further triaging of the issue.

Thanks..

I can't access chrome://crashes because I can't launch Chrome. I assumed it was just exiting after the updater (setup.exe) crashed, but digging a little deeper reveals that chrome.exe is also crashing, and generating minidumps in %LOCALAPPDATA%\Google\Chrome\User Data\Crashpad\reports. It looks like Chrome is crashing with a very similar callstack:

>	chrome.exe!base::debug::BreakDebugger()  Line 21	C++
 	chrome.exe!logging::LogMessage::~LogMessage()  Line 842 + 0x5 bytes	C++
 	chrome.exe!logging::Win32ErrorLogMessage::~Win32ErrorLogMessage()  Line 963 + 0xc bytes	C++
 	chrome.exe!crashpad::internal::ScopedKernelHANDLECloseTraits::Free()  Line 28 + 0x31 bytes	C++
 	chrome.exe!base::ScopedGeneric<void *,crashpad::internal::ScopedKernelHANDLECloseTraits>::reset()  Line 103 + 0x12 bytes	C++
 	chrome.exe!crashpad::ExceptionHandlerServer::Run()  Line 329 + 0x3e bytes	C++
 	chrome.exe!crashpad::HandlerMain()  Line 799 + 0x15 bytes	C++
 	chrome.exe!crash_reporter::RunAsCrashpadHandler()  Line 89 + 0xb bytes	C++
 	chrome.exe!wWinMain()  Line 205 + 0x1a bytes	C++
 	chrome.exe!__scrt_common_main_seh()  Line 283 + 0x21 bytes	C++

I've placed a copy of the most recent minidump here: https://www.dropbox.com/s/05zpdy0y83e0eu8/4177bb5d-2efc-491e-8194-52d0368b0148.dmp?dl=1 ('Attach a file' doesn't seem to work in the comment section in Firefox.)

I'm running Windows 7 64-bit.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Maybe you can find the regression range yourself:
https://www.chromium.org/developers/bisect-builds-py

A debug log could be helpful too:
https://www.chromium.org/for-testers/enable-logging

Aha, there was an existing log in C:\Program Files (x86)\Google\Chrome\Application\debug.log:

    [0411/082512.165:FATAL:scoped_handle.cc(28)] : The handle is invalid. (0x6)
    [0411/082512.977:ERROR:registration_protocol_win.cc(56)] CreateFile: The system cannot find the file specified. (0x2)
    [0411/082613.723:ERROR:crashpad_client_win.cc(174)] crash server did not respond, self-terminating

This matches the callstack in the dumps, but doesn't explain why the handle was invalid.

Looking at the source code (https://github.com/electron/crashpad/blob/master/util/win/exception_handler_server.cc#L309) there's no way the handle could be invalid during the call to reset(), since it's a default-constructed handle object with the canonical default value for a kernel handle. Looks like stack corruption -- perhaps the latest builds with clang are to blame?

I'll try to bisect...

Bisecting went nowhere, unfortunately. Every build it downloaded launched successfully.

Logging with verbosity v=4 gives:

[4528:4608:0412/110820.777:ERROR:cache_util_win.cc(20)] Unable to move the cache: 5
[4528:4608:0412/110820.777:ERROR:cache_util.cc(134)] Unable to move cache folder C:\Users\Cameron\AppData\Local\Google\Chrome\User Data\ShaderCache\GPUCache to C:\Users\Cameron\AppData\Local\Google\Chrome\User Data\ShaderCache\old_GPUCache_000
[4528:4608:0412/110820.780:ERROR:disk_cache.cc(169)] Unable to create cache
[4528:4608:0412/110820.780:ERROR:shader_disk_cache.cc(601)] Shader Cache Creation failed: -2
[5064:4984:0412/110821.110:ERROR:gl_surface_egl.cc(840)] eglInitialize D3D11 failed with error EGL_NOT_INITIALIZED, trying next display type

If I manually remove the cache folder, the first error goes away, and the log shows just:

[3004:4520:0412/111434.792:ERROR:gl_surface_egl.cc(840)] eglInitialize D3D11 failed with error EGL_NOT_INITIALIZED, trying next display type

I'm not sure these errors are related. The C:\Program Files (x86)\Google\Chrome\Application\debug.log file continues to accumulate entries like:

[0412/111433.968:FATAL:scoped_handle.cc(28)] : The handle is invalid. (0x6)
[0412/111434.206:ERROR:registration_protocol_win.cc(56)] CreateFile: The system cannot find the file specified. (0x2)
[0412/111534.445:ERROR:crashpad_client_win.cc(174)] crash server did not respond, self-terminating

which seem much more related to the crash in question.

Switching to the crash component so that the right folks see this. Is this happening at startup or shutdown? ERROR_INVALID_HANDLE would happen if something else in the process was closing the handle. Windows re-uses handle values aggressively, so there could be a double-free.

Thanks. It's happening immediately during startup, in both setup.exe and chrome.exe.

As Issue is not reproducible from TE end adding TE-NeedsTriageHelp lablel to remove this out of TE triaging bucket. Could someone from Internals>CrashReporting team please have a look at this issue.

Thanks!

Since it crashes during ExceptionHandlerServer::Run() which creates named pipes, maybe it's similar to  bug 700615 .