netsh unit tests fail app verifier handles test

[shankarseal]

Repro steps:
appverif -enable handles -for unit_tests.exe

Launch under windbg: .\unit_tests.exe [netsh]

The test breaks into user mode debugger. Per AVRF, the faulting source seems to be in the catch library. However running other test modules such as [end_to_end] does not produce similar break.

Partial debug output:

!avrf
Application verifier settings (80000004):

• no heap checking enabled!
• Handles

No verifier stop active.

Note. Sometimes bugs found by verifier manifest themselves
as raised exceptions (access violations, stack overflows, invalid handles
and it is not always necessary to have a verifier stop.
0:000> !analyze -v

---

•                                                                         *
  

•                    Exception Analysis                                   *
  

•                                                                         *
  

---

APPLICATION_VERIFIER_HANDLES_INVALID_HANDLE (300)
Invalid handle exception for current stack trace.
This stop is generated if the function on the top of the stack passed an
invalid handle to system routines. Usually a simple kb command will reveal
what is the value of the handle passed (must be one of the parameters -
usually the first one). If the value is null then this is clearly wrong.
If the value looks ok you need to use !htrace debugger extension to get a
history of operations pertaining to this handle value. In most cases it
must be that the handle value is used after being closed.
Arguments:
Arg1: ffffffffc0000008, Exception code.
Arg2: 0000000000000000, Exception record. Use .exr to display it.
Arg3: 0000000000000000, Context record. Use .cxr to display it.
Arg4: 0000000000000000, Not used.
AppX analyze extension failed with 0x8000ffff
Plugin 'AppxExt.dll' failed (0x8000ffff) in phase 'Post'

KEY_VALUES_STRING: 1

Key  : AVRF.Code
Value: 300

Key  : AVRF.Enabled
Value: 1

Key  : AVRF.Exception
Value: 1

Key  : Plugin.Exception.Post.AppxExt.dll
Value: 0x8000ffff (E_UNEXPECTED)

Key  : Statistics.LastEvent.Exception.Code
Value: 0xC0000008

PROCESS_NAME: unit_tests.exe

APPLICATION_VERIFIER_LOADED: 1

EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 00007ffb2ec50c7a (ntdll!KiRaiseUserExceptionDispatcher+0x000000000000003a)
ExceptionCode: c0000008 (Invalid handle)
ExceptionFlags: 00000000
NumberParameters: 0
Thread tried to close a handle that was invalid or illegal to close

ERROR_CODE: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified.

EXCEPTION_CODE_STR: c0000008

RETRACER_ANALYSIS_TAG_STATUS: DEBUG_FLR_EXCEPTION_CODE is not 0xc0000005

FAULTING_SOURCE_LINE: C:\Users\sseal.nuget\packages\catchorg.catch\2.8.0\lib\native\include\catch2\catch.hpp

FAULTING_SOURCE_LINE_NUMBER: 8399

FAILURE_BUCKET_ID: INVALID_HANDLE_AVRF_c0000008_unit_tests.exe!Catch::anonymous_namespace::Win32ColourImpl::setTextAttribute

Call Stack:
ntdll!KiRaiseUserExceptionDispatcher
vfbasics!AVrfpNtDeviceIoControlFile
KERNELBASE!ConsoleCallServerGeneric
KERNELBASE!ConsoleCallServer
KERNELBASE!SetConsoleTextAttribute
unit_tests!Catch::anonymous namespace'::Win32ColourImpl::setTextAttribute unit_tests!Catch::anonymous namespace'::Win32ColourImpl::use
unit_tests!Catch::Colour::use
unit_tests!Catch::Colour::~Colour
unit_tests!Catch::ConsoleReporter::printTotalsDivider
unit_tests!Catch::ConsoleReporter::testRunEnded
unit_tests!Catch::RunContext::~RunContext
unit_tests!Catch::`anonymous namespace'::runTests
unit_tests!Catch::Session::runInternal
unit_tests!Catch::Session::run
unit_tests!Catch::Session::run<wchar_t>
unit_tests!wmain
unit_tests!invoke_main
unit_tests!__scrt_common_main_seh
unit_tests!__scrt_common_main
unit_tests!wmainCRTStartup
KERNEL32!BaseThreadInitThunk
ntdll!RtlUserThreadStart

[dthaler]

capture_helper.hpp apparently causes this when redirecting stdout to capture it.
CATCH2 also messes with stdout and the interaction is what appverif is hitting.
Specifically, catch caches the HANDLE returned by GetStdHandle(STD_OUTPUT_HANDLE).
Normally capture_helper.hpp would preserve the underlying handle, but catch somehow changes the underlying behavior so that it does not.

I can potentially change capture_helper to remember the underlying handle, but I am not sure how to restore it.
The current method uses _dup() to back up the original fd and restore it with _dup2() which normally works, but with catch the underlying handle is different with _dup (possiblying dup'ing a handle that catch has already redirected to another one). By the time we try to put the handle back it is already closed, not sure from where.

[dthaler]

Update: _dup2() closes the underlying file handle of the target fd, which handle CATCH2 already cached in its Win32ColourImpl class. To me this seems like a flaw in CATCH2's color handler for Windows. The workaround is to disable the use of color like it does for UWPs.

[Alan-Jowett]

Can we file an issue in https://github.com/catchorg/Catch2/issues with the details?

[dthaler]

Done: catchorg/Catch2#2345
Also referenced this issue in a comment in PR #708