Solves two problems with having the macros inline:
1. Deduplicates some of the logic (in this case, the name of the
histogram, and whether it should be divided by 1024);
2. More useful check for compilation. As the macros are no-ops in
Crashpad, it was easy to use the wrong name for a variable in the
arguments to the macros (see .mm!)
This way, we have some better chance of at least having code that
compiles when built in Chromium if all the arguments are passed to
Metrics::Something() in a standalone build.
Also rolls mini_chromium DEPS to include:
99213eb Mark histogram arguments as unused to avoid warnings
R=mark@chromium.org
BUG=crashpad:100
Change-Id: I9f7fc3b85854fd61c1ebdf0084d728a7b690c2f1
Reviewed-on: https://chromium-review.googlesource.com/380445
Reviewed-by: Mark Mentovai <mark@chromium.org>
Add a first example of a UMA entry to have it available to try to plumb
through to Chromium.
Adds LoggingFileSizeByHandle() to util/file/file_io.* to retrieve the
size of on disk file to report to UMA.
Also rolls DEPS for mini_chromium to include:
b5ec9ce Add stub versions of histogram_macros.h
R=mark@chromium.org
BUG=crashpad:100
Change-Id: Ib8e96ad4b7d715b46d2c71810c95c92965a89821
Reviewed-on: https://chromium-review.googlesource.com/338821
Reviewed-by: Mark Mentovai <mark@chromium.org>
In order to allow on-demand uploads for crash reports, adding a
upload_explicitly_requested bit on 'pending' state and necessary support
for it.
BUG=chromium:620762
Change-Id: Ida38e483fe8d0e48eb5cbe95e8b8bfd96a2f8f00
Reviewed-on: https://chromium-review.googlesource.com/367328
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The utilities in base/stl_util.h have been moved from the global
into the base namespace. This patch updates the call sites accordingly.
No functional changes.
Change-Id: I059d5d6299f947b1135672da170427d23ac4775e
Reviewed-on: https://chromium-review.googlesource.com/368640
Reviewed-by: Mark Mentovai <mark@chromium.org>
HTTPBodyStream::GetBytesBuffer returns negative number on error.
Change-Id: I9958fb35d65e894067d71e8f37c30ff8948cd90d
Reviewed-on: https://chromium-review.googlesource.com/366360
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
RESOURCE_TYPE_IO always appears to be non-fatal based on disassembly of
the function responsible for sending it in xnu 3705.0.0.1.10 (10.12dp1
16A201w).
BUG=crashpad:120,crashpad:124
Change-Id: I9dcc6673f922cbd7af910b76991825a9d9c96fe6
Reviewed-on: https://chromium-review.googlesource.com/355250
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The desired work count must be set before the thread is started,
otherwise multiple work items might be completed before it is set,
resulting it never signalling the sema.
R=mark@chromium.org,rsesek@chromium.org
BUG=crashpad:115
Change-Id: Ie4712f56af073277366cb84cca6d302a9eab409a
Reviewed-on: https://chromium-review.googlesource.com/346193
Reviewed-by: Mark Mentovai <mark@chromium.org>
d:\src\crashpad\crashpad>git checkout origin/master
Note: checking out 'origin/master'.
...
HEAD is now at f497e54... win: Fix indirectly gathered memory cap
[f497e54...]d:\src\crashpad\crashpad>ninja -C out\Debug
ninja: Entering directory `out\Debug'
[0->23/23 ~0] STAMP obj\All.actions_depends.stamp
[f497e54...]d:\src\crashpad\crashpad>tim out\Debug\crashpad_snapshot_test --gtest_filter=ProcessSnapshotTest.CrashpadInfoChild
Running main() from gtest_main.cc
Note: Google Test filter = ProcessSnapshotTest.CrashpadInfoChild
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from ProcessSnapshotTest
[ RUN ] ProcessSnapshotTest.CrashpadInfoChild
[ OK ] ProcessSnapshotTest.CrashpadInfoChild (147879 ms)
[----------] 1 test from ProcessSnapshotTest (147880 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (147884 ms total)
[ PASSED ] 1 test.
real: 2m27.907s
qpc: 147914874us
[f497e54...]d:\src\crashpad\crashpad>git checkout slow-debug
Previous HEAD position was f497e54... win: Fix indirectly gathered memory cap
Switched to branch 'slow-debug'
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
[slow-debug]d:\src\crashpad\crashpad>ninja -C out\Debug
ninja: Entering directory `out\Debug'
[0->23/23 ~0] STAMP obj\All.actions_depends.stamp
[slow-debug]d:\src\crashpad\crashpad>tim out\Debug\crashpad_snapshot_test --gtest_filter=ProcessSnapshotTest.CrashpadInfoChild
Running main() from gtest_main.cc
Note: Google Test filter = ProcessSnapshotTest.CrashpadInfoChild
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from ProcessSnapshotTest
[ RUN ] ProcessSnapshotTest.CrashpadInfoChild
[ OK ] ProcessSnapshotTest.CrashpadInfoChild (4414 ms)
[----------] 1 test from ProcessSnapshotTest (4416 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (4420 ms total)
[ PASSED ] 1 test.
real: 0m4.453s
qpc: 4454559us
R=mark@chromium.org
BUG=crashpad:114
Change-Id: I9f18fe54a2711a483ced86ece0b261cdfffc6192
Reviewed-on: https://chromium-review.googlesource.com/346490
Reviewed-by: Mark Mentovai <mark@chromium.org>
Adds a new client API which allows causing an exception in another
process. This is accomplished by injecting a thread that calls
RaiseException(). A special exception code is used that indicates to the
handler that the exception arguments contain a thread id and exception
code, which are in turn used to fabricate an exception record. This is
so that the API can allow the client to "blame" a particular thread in
the target process.
The target process must also be a registered Crashpad client, as the
normal exception mechanism is used to handle the exception.
The injection of a thread is used instead of DebugBreakProcess() which
does not cause the UnhandledExceptionFilter() to be executed.
NtCreateThreadEx() is used in lieu of CreateRemoteThread() as it allows
passing of a flag which avoids calling DllMain()s. This is necessary to
allow thread creation to succeed even when the target process is
deadlocked on the loader lock.
BUG=crashpad:103
Change-Id: I797007bd2b1e3416afe3f37a6566c0cdb259b106
Reviewed-on: https://chromium-review.googlesource.com/339263
Reviewed-by: Mark Mentovai <mark@chromium.org>
Kasko needs a way to read crash keys from out of process. This API
reuses the functionality of PEImageAnnotationsReader.
Change-Id: I2f3bbc358212e6f50235183e9dbb4e5a2cf989cf
This is a reupload of https://codereview.chromium.org/1586433003/ but
for gerrit.
Change-Id: I2f3bbc358212e6f50235183e9dbb4e5a2cf989cf
Reviewed-on: https://chromium-review.googlesource.com/322550
Reviewed-by: Scott Graham <scottmg@chromium.org>
Tested-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@google.com>
a43fee120b10 Sync Mac scopers with upstream Chromium
This adapts to updated Mac scopers from Chromium cfd6ed5600d8, including
the changes from that commit and Chromium f39d4ffc6c32.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1565873002 .
This was done in Chromium’s local copy of Crashpad in 562827afb599. This
change is similar to that one, except more care was taken to avoid
including headers from a .cc or _test.cc when already included by the
associated .h. Rather than using <stddef.h> for size_t, Crashpad has
always used <sys/types.h>, so that’s used here as well.
This updates mini_chromium to 8a2363f486e3a0dc562a68884832d06d28d38dcc,
which removes base/basictypes.h.
e128dcf10122 Remove base/move.h; use std::move() instead of Pass()
8a2363f486e3 Move basictypes.h to macros.h
R=avi@chromium.org
Review URL: https://codereview.chromium.org/1566713002 .
../../handler/crash_report_upload_thread.cc:142:7: error: field 'database_' will be initialized after field 'thread_' [-Werror,-Wreorder]
database_(database),
^
1 error generated.
And:
..\util\thread\worker_thread_test.cc(25) : warning C4244: 'initializing' : conversion from 'double' to 'const uint64_t', possible loss of data
BUG=crashpad:22
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1556043005 .
Fix some warnings when compiling crashpad with VC++ 2015 Update 1.
Warning 4302 occurs if you convert from a pointer to a <sizeof(void*)
integer in one cast, because this often indicates an accidental pointer
truncation which can be a bug in 64-bit builds.
Warning 4577 warns that noexcept will not be enforced, but we don't want
it to be enforced anyway, so I disabled it. The full warning is:
warning C4577: 'noexcept' used with no exception handling mode specified
termination on exception is not guaranteed. Specify /EHsc
BUG=440500
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1527803002 .
Patch from Bruce Dawson <brucedawson@chromium.org>.
This more-natural spelling doesn’t require Crashpad developers to have
to remember anything special when writing code in Crashpad. It’s easier
to grep for and it’s easier to remove the “compat” part when pre-C++11
libraries are no longer relevant.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1513573005 .
MEMORY_BASIC_INFORMATION64 specifies an alignment of 16, but the
standard allocator used by containers doesn't honor this. Although 16
is the default alignment size used on Windows for x86_64, it's not for
32-bit x86. clang assumed that the alignment of the structure was as
declared, and used an SSE load sequence that required this alignment.
AlignedAllocator is a replacement for std::allocator that allows the
alignment to be specified. AlignedVector is an std::vector<> that uses
AlignedAllocator instead of std::allocator.
BUG=chromium:564691
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1498133002 .
Don't call GetFileVersionInfo(), which calls LoadLibrary() to be able to
access the module's resources. Loading modules from the crashy process
into the handler process can cause trouble. The Crashpad handler
definitely doesn't want to run arbitrary modules' module initializer
code.
Since the VS_FIXEDFILEINFO needed is already in memory in the remote
process' address space, just access it from there.
BUG=crashpad:78
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1475023004 .
This unifies several things that used a 16-character random string, and
a few other users of random identifiers where it also made sense to use
a 16-character random string.
TEST=crashpad_util_test RandomString.RandomString
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1451793002 .
The bug and linked code review has more of the history, but we’ve been
tempted to remove the loop outright a couple of times already before
realizing that it serves an important purpose. Hopefully this comment
will protect our future selves from going on the same fool’s errand.
BUG=crashpad:75
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1427643010 .
This is better because now end_to_end_test.py fails immediately with
[1180:9020:20151106,145204.830:ERROR registration_protocol_win.cc:39] CreateFile: The system cannot find the file specified. (0x2)
R=mark@chromium.org
BUG=crashpad:75
Review URL: https://codereview.chromium.org/1409693011 .
In 2eeaa3ac549a, I added a check to make sure that the expected CONOUT$
handle was found. Its omission seemed to be unintentional. The tests
passed for me on Windows 10, but failed on the bots. I can reproduce
the failures locally on Windows 7.
Doing the inheritance test with a file other than CONOUT$ fixes the
immediate problem, but we should find out why this CONOUT$ handle isn't
showing up in the handles list on Windows 7, fix it, and add back a
test.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1428753009 .
This consolidates all of the twisted casts and comments that discuss how
HANDLEs are really only 32 bits wide even in 64-bit processes on 64-bit
operating systems into a single location.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1422503015 .
Allowing the client to create its own pipe name string caused a race
between client and server. Instead, in this mode, the server now creates
the pipe name along with a pipe, and returns it to its client via a
--handshake-handle. This guarantees that by the time the client gets the
pipe name, the server has already created it.
Ephemeral mode is now implied by --handshake-handle. The --persistent
option is gone. --persistent mode is enabled when using --pipe-name.
BUG=crashpad:69
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1432563003 .
I considered writing the CodeView records to the minidump, but I didn't
find a ton of docs and debugging is only lightly supported (e.g.
http://www.debuginfo.com/articles/gendebuginfo.html#debuggersandformats
and it doesn't attempt to load at all on more recent Visual Studios).
As we won't be generating symbols in this format, and we don't expect to
have symbols for any weird modules that get injected into us in the
wild, it seems like we don't lose anything by just ignoring them.
R=mark@chromium.org
BUG=crashpad:47
Review URL: https://codereview.chromium.org/1430773003 .
Each routine in this implementation returns MIG_BAD_ID. These routines
may be overridden.
Most things that implement NotifyServer::Interface will only need to
implement one of the interface routines. Since another user of
NotifyServer will be added soon, it makes sense to provide a default
no-op implementation rather than forcing everyone to write the same
no-op boilerplate repeatedly.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1414413006 .
Previously, crashpad_handler made its own receive right, and transferred
a corresponding send right to its client. There are two advantages to
making the receive right in the client:
- It is possible to monitor the receive right for a port-destroyed
notificaiton in the client, allowing the handler to be restarted if
it dies.
- For the future run-from-launchd mode (bug crashpad:25), the handler
will obtain its receive right from the bootstrap server instead of
making its own. Having the handler get its receive right from
different sources allows more code to be shared than if it were to
sometimes get a receive right and sometimes make a receive right and
transfer a send right.
This includes a restructuring in crashpad_client_mac.cc that will make
it easier to give it an option to restart crashpad_handler if it dies.
The handler starting logic should all behave the same as before.
BUG=crashpad:68
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1409073013 .
This allows better code sharing in crashpad_handler’s main(). It doesn’t
look like much of an improvement now, but a separate change will cause
the Mac ExceptionHandlerServer() to be constructed with an argument. It
will be beneficial for Mac and Windows to be able to share the Run()
call.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1402333004 .
The intended use is to flip the client-server relationship in
CrashpadClient so that the initial client (parent process) furnishes the
handler process with a receive right. The parent can optionally receive
a port-destroyed notification allowing it to restart the handler if it
exits prematurely.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1408473002 .
Fixes two incorrect usages of ssize_t/off_t being implicitly converted
to bool. As such, I think it's worth the cost of the additional !! on
BOOL returning Win32 functions.
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1408123006 .
In https://codereview.chromium.org/1411523006, the Mach port scopers are
becoming better ScopedGenerics and are losing the type conversion
operators in the process. This is needed to adapt to that change. get()
is ugly, but being explicit about conversion isn’t a bad thing, and
these scopers will gain functionality such as Pass() as part of the
switch.
As a bonus, some would-be uses of get() to check for valid port rights
are becoming a more descriptive is_valid().
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1405273002 .
This new test from 7de04b02f85d was failing on Windows 10. I started by
adding the hint, which produced “CreateFileMapping: Access is denied.
(0x5)â€. Switching the “Global\†to “Local\†fixes the test for me.
TEST=crashpad_util_test ProcessInfo.Handles
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1407993003 .
I thought I had confirmed that this still allocated and ignored the flag
on older OSs, but I must have not had the PLOG active yet? I'm not sure
what I did. (I might try to blame VMware as it has an annoying habit of
caching old binaries when you use it's "Shared Folders" feature to point
at the dev machine's build dir.)
I confirmed that it does work on Win8 and Win10 but doesn't on Win XP
and Win 7.
R=mark@chromium.org
BUG=crashpad:52
Review URL: https://codereview.chromium.org/1405243002 .
Capture the memory for the loader lock (can be inspected by !cs), as
well as all locks that were created with .DebugInfo which can be viewed
with !locks.
e.g.
0:000> !cs ntdll!LdrpLoaderLock
-----------------------------------------
Critical section = 0x778d6410 (ntdll!LdrpLoaderLock+0x0)
DebugInfo = 0x778d6b6c
NOT LOCKED
LockSemaphore = 0x0
SpinCount = 0x04000000
0:000> !locks -v
CritSec ntdll!RtlpProcessHeapsListLock+0 at 778d7620
LockCount NOT LOCKED
RecursionCount 0
OwningThread 0
EntryCount 0
ContentionCount 0
CritSec +7a0248 at 007a0248
LockCount NOT LOCKED
RecursionCount 0
OwningThread 0
EntryCount 0
ContentionCount 0
CritSec crashy_program!g_critical_section_with_debug_info+0 at 01342c48
LockCount NOT LOCKED
RecursionCount 0
OwningThread 0
EntryCount 0
ContentionCount 0
CritSec crashy_program!crashpad::`anonymous namespace'::g_test_critical_section+0 at 01342be0
WaiterWoken No
LockCount 0
RecursionCount 1
OwningThread 34b8
EntryCount 0
ContentionCount 0
*** Locked
Scanned 4 critical sections
R=mark@chromium.org
BUG=crashpad:52
Review URL: https://codereview.chromium.org/1392093003 .
This doesn’t really provide compatibility, it just ignores the
deprecation warning for +[NSURLConnection
sendSynchronousRequest:returningResponse:error:].
The suggested replacement, NSURLSession, was new in 10.9, and this code
needs to run on 10.6, so it’s not usable here, at least not without a
runtime check.
BUG=crashpad:65
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1395673002 .
We already use all the shared constants for page protection and type,
so rather than making various incompatible structures, just use
the MEMORY_BASIC_INFORMATION64 one directly, so that it can be directly
used.
R=mark@chromium.org
BUG=crashpad:20, crashpad:46
Review URL: https://codereview.chromium.org/1375313005 .
ExceptionPorts::GetExceptionPorts() returned a
std::vector<ExceptionPorts::ExceptionHandler>, which contained send
rights to Mach ports. The interface required callers to assume ownership
of each send right contained within the vector. This was cumbersome and
error-prone, and despite the care taken in Crashpad, port right leaks
did occur:
- SimulateCrash() didn’t make any attempt to release these resources at
all.
- Neither did crashpad_util_test ExceptionPorts.HostExceptionPorts,
which also reused a vector.
This replaces the vector with the interface-compatible (as far as
necessary) ExceptionPorts::ExceptionHandlerVector, which deallocates
collected port rights on destruction or clear().
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1381023007 .
This wraps bootstrap_check_in() in BootstrapCheckIn(), and
bootstrap_look_up() in BootstrapLookUp(). The wrappers make it more
difficult to accidentally leak a returned right. They’re easier to use,
encapsulating common error checking and logging, simplifying all call
sites.
TEST=crashpad_util_test MachExtensions.BootstrapCheckInAndLookUp
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1383283003 .
Chrome’s relauncher process needs a way to sever ties with the
crashpad_handler instance running from the disk image in order to cause
that instance to exit so that the disk image may be unmounted. This new
function is otherwise not thought to be interesting, and its use is not
recommended.
This comes with a small refactoring to create a
SystemCrashReporterHandler() function, and a fix for a minor port leak
in CrashReportExceptionHandler::CatchMachException().
BUG=chromium:538373
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1375573005 .
Sadly this code did not survive a collision with the real world. In
probing for the environment block there's a MEM_COMMIT region followed
directly by a MEM_RESERVE region (past the end of the environment
block).
Update region checker to correctly treat MEM_RESERVE as inaccessible.
R=mark@chromium.org
BUG=crashpad:20, crashpad:46, crashpad:59
Review URL: https://codereview.chromium.org/1370063005 .
On Win10, VirtualQueryEx supports querying the x64 part of WOW64
processes. However, on lower OSs it errors past 2/3G. There's no direct
way to retrieve to maximum memory address for processes other than
yourself, but fortunately, VirtualQueryEx sets a distinct error code
when `lpAddress` exceeds the maximum accessible address, so we can just
terminate successfully in that case.
R=mark@chromium.org
BUG=crashpad:20, crashpad:46
Review URL: https://codereview.chromium.org/1376353002 .
Windows requires the connection to the handler to do anything, so it
can't really be implemented or tested without CrashpadClient and the
connection machinery.
R=mark@chromium.org
BUG=crashpad:53
Review URL: https://codereview.chromium.org/1356383002 .
This makes the basics of !peb work in windbg, however, pointed-to things
are not yet retrieved. For full functionality, a variety of pointers in
the PEB also needs to be walked and captured.
e.g.
Previously:
0:000> .ecxr
eax=00000007 ebx=7e383000 ecx=c3f9a943 edx=00000000 esi=006d62d0 edi=003c9280
eip=00384828 esp=005bf634 ebp=005bf638 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
crashy_program!crashpad::`anonymous namespace'::SomeCrashyFunction+0x28:
00384828 c7002a000000 mov dword ptr [eax],2Ah ds:002b:00000007=????????
0:000> !peb
PEB at 7e383000
error 1 InitTypeRead( nt!_PEB at 7e383000)...
Now:
0:000> .ecxr
eax=00000007 ebx=7f958000 ecx=02102f4d edx=00000000 esi=00e162d0 edi=01389280
eip=01344828 esp=00c2fb64 ebp=00c2fb68 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
crashy_program!crashpad::`anonymous namespace'::SomeCrashyFunction+0x28:
01344828 c7002a000000 mov dword ptr [eax],2Ah ds:002b:00000007=????????
0:000> !peb
PEB at 7f958000
InheritedAddressSpace: No
ReadImageFileExecOptions: No
BeingDebugged: No
ImageBaseAddress: 01340000
Ldr 77ec8b40
*** unable to read Ldr table at 77ec8b40
SubSystemData: 00000000
ProcessHeap: 00e10000
ProcessParameters: 00e114e0
CurrentDirectory: '< Name not readable >'
WindowTitle: '< Name not readable >'
ImageFile: '< Name not readable >'
CommandLine: '< Name not readable >'
DllPath: '< Name not readable >'
Environment: 00000000
Unable to read Environment string.
R=mark@chromium.org
BUG=crashpad:46
Review URL: https://codereview.chromium.org/1364053002 .
Removes the bitness-specific targets in favour of pulling binaries from
the other build directory. This is to avoid the added complexity of
duplicating all the targets for the x86 in x64 build.
Overall, mostly templatizing more functions to support the
wow64-flavoured structures. The only additional functionality required
is reading the x86 TEB that's chained from the x64 TEB when running
as WOW64.
The crashing child test was switched to a manual CreateProcess because
it needs to launch a binary other than itself.
R=mark@chromium.org
BUG=crashpad:50
Review URL: https://codereview.chromium.org/1349313003 .
A few function implementations that were missing, various switches
for functions/functionality that didn't exist on XP, and far too long
figuring out what exactly was wrong with SYSTEM_PROCESS_INFORMATION
on x86 (the "alignment_for_x86" fields).
R=mark@chromium.org
BUG=crashpad:1, crashpad:50, chromium:531663
Review URL: https://codereview.chromium.org/1336823002 .
The pipe handle was being leaked on connections (oops!). On XP this
resulted in the next test's CreateNamedPipe to fail, because the
previous one still existed (because all handles were not closed). More
recent OSs are more forgiving so I got away with the buggy code.
R=mark@chromium.org
BUG=crashpad:50
Review URL: https://codereview.chromium.org/1337953003 .
