New Post: OpenCPPCover with native C++ test

I finally found the time to do some more tests.

I first tried the last post that you had:

1. Made a copy of the project to another location
2. Removed tests until I had only 1 left
3. Coverage is generated.
   3.1. Copied more tests... it all seems to be working here.
   

I then restored the referenced libraries, include paths, etc - all working fine. However, as I said, I tested it on a different location on disk, which obviously matters because of the sources filters. I'm not using a modules filter anymore. Having this different path means that the process doesn't need to bind breakpoints to the engine.

As I said before, the small test cases are working just fine. The problems start to occur when I'm attempting to run coverage for my engine project (which is huge).

Next, I tried the suggestions in the first post:

Check if your dll has a special settings under properties C++ or linker compare to a default dll.

No difference here with a smaller test, I checked all properties.

Another idea is to call DebugBreak in a location you expect to be monitored. If you run with OpenCppCoverage, you should see the message "It seems there is an assertion failure or you call DebugBreak() in your program."

Confirmed, this happens.

You can put a breakpoint inside Debugger::OnException. This function is called for each executed line and for every thread creation. If this function is called often, you can trace and see why #1 is not called.

What I observe is that CodeCoverageRunner::OnException will return FirstChanceException -> NotHandled each time it's called. On closer inspection, ExceptionHandler::HandleException attempts to find the exceptionCode in breakPointExceptionCode_, which is never present (the dictionary contains only 2 codes, which I understand to be related to breakpoints)

The exception code that occurs the most is 0xE06D7363, which seems to be a SEH exception ( https://support.microsoft.com/en-us/kb/185294 ). To make it even stranger, when I filtered that code out, it doesn't seem to generate any exception codes anymore. I believe this can only mean that debug events from the child process aren't captured for some strange reason...

So, I've turned my attention to de Debugger class next and compared it to the information in (sysinternals) process explorer. Both processes (vstest.console.exe and TE.ProcessHost.Managed.exe) are present in the processHandles dictionary. The relevant threads (WEX.Common...) are also present in the threadHandles dictionary.

It's strange... I understand that if breakpoint events aren't captured for some reason, it won't work. Still, the events show that it should work.

You can also call IsDebuggerPresent in a location you expect to be monitored. If you run with vstest.console.exe from command line without OpenCppCoverage this should return false.

Hmm... you say something interesting here.

I'm using custom exceptions, which also generate stack traces through DbgHelp. To be on the safe side, I tested if it interferes with a minimum test... it seems not to interfere, but better safe then sorry. Here's the relevant test code:

HANDLE process = GetCurrentProcess();
SymSetOptions(SYMOPT_LOAD_LINES);
SymInitialize(process, NULL, TRUE);

static const int MaxCallStack = 62; // // ## The sum of the FramesToSkip and FramesToCapture parameters must be less than 63 on Win2003
void* callers[MaxCallStack];
auto stackCount = RtlCaptureStackBackTrace(1, MaxCallStack, callers, NULL);

SYMBOL_INFO* symbol = reinterpret_cast<SYMBOL_INFO *>(calloc(sizeof(SYMBOL_INFO) + 256 * sizeof(char), 1));
symbol->MaxNameLen = 255;
symbol->SizeOfStruct = sizeof(SYMBOL_INFO);

SymFromAddr(process, reinterpret_cast<DWORD64>(callers[0]), 0, symbol);

Either way, I've checked with your suggestion as well. IsDebuggerPresent returns false without opencppcoverage.

To be entirely thorough I've also checked this WITH opencppcoverage and vstest. IsDebuggerPresent returns true here.

Last but not least, even though I always want everything to work and it kinda feels unsatisfactory, I'm on the virge of giving this this one up. The workaround that I've created earlier works great and is much, much faster than running everything though vstest; to be honest it's very unlikely that I'll move back to the vstest route.

PS: have you already looked at the VS plugin I wrote?