win: crashpad_util_test ProcessInfo.Handles doesn't work with CONOUT$

win: crashpad_util_test ProcessInfo.Handles doesn't work with CONOUT$

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

Committed: https://chromium.googlesource.com/crashpad/crashpad/+/82ffeaa0f0866e04e9e3b4f36fe27143cc2f233e

[Mark Mentovai, 2015-11-05 19:42:01]

mark@chromium.org changed reviewers:
+ scottmg@chromium.org

[Mark Mentovai, 2015-11-05 19:42:02]

Do you have any better ideas? We’re evidently not capturing all handles.

https://codereview.chromium.org/1428753009/diff/1/util/win/process_info_test.cc
File util/win/process_info_test.cc (right):

https://codereview.chromium.org/1428753009/diff/1/util/win/process_info_test....
util/win/process_info_test.cc:541: security_attributes.nLength =
sizeof(security_attributes);
I originally thought that this would be the problem, but no such luck.

I also thought that https://support.microsoft.com/en-us/kb/90088 might be it,
but adding FILE_SHARE_WRITE didn’t help either.

[Mark Mentovai, 2015-11-05 19:54:47]

Where this fails for me on Windows 7, inherited_file from CONOUT$ is 3, which
I’m guessing is a pseudo-handle.

[Mark Mentovai, 2015-11-05 20:03:09]

If I DuplicateHandle() it, I get 0x13, which still doesn’t show up in the list
of handles.

[scottmg, 2015-11-05 20:06:51]

Hmm, I can't think of anything, but lgtm to green the test.

[Mark Mentovai, 2015-11-05 20:08:33]

Committed patchset #1 (id:1) manually as
82ffeaa0f0866e04e9e3b4f36fe27143cc2f233e (presubmit successful).

[scottmg, 2015-11-05 20:08:38]

On 2015/11/05 20:03:09, Mark Mentovai wrote:
> If I DuplicateHandle() it, I get 0x13, which still doesn’t show up in the list
> of handles.

0x13 is still a "weird" handle -- I've never encountered a handle who's value
isn't % 4 == 0.

[Mark Mentovai, 2015-11-06 15:25:26]

I found this nugget in the DuplicateHandle() documentation:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724251

DuplicateHandle can duplicate handles to the following types of objects.
[…]
Console screen buffer
The handle is returned by the CreateFile function when CONOUT$ is specified, or
by the GetStdHandle function when STD_OUTPUT_HANDLE is specified. Console
handles can be duplicated for use only in the same process.

Similar for CONIN$.

We actually are duplicating it in the same process (just for this test), but
this kind of carries an implication that it’s not a real kernel handle. This
also kind of explains why the bottom two bits aren‘t clear.

[Mark Mentovai, 2015-11-06 15:37:54]

I confirmed that windbg can’t see this handle either, so I don’t think there’s
anything else to do here.