Unit tests pass but dotCover fails with an error
We're currently able to get around this by disabling dotCover in the unit test build step but of course that's less than ideal. I found some discussion in YouTrack about issues with OneDrive and Data Deduplication but neither of those seem to apply to our environment.
Can someone provide some insight / assistance on this?
Notes:
- Other tests / coverage work fine on the same agent
- Tests are in an assembly that targets .NET Framework v4.7.2
- Coverage is needed for assemblies that target .NET Framework v4.7.2 and .NET Standard 2.0
- All projects involved use PackageReferences for nuget dependencies
- This works on workstations running VS 15.9.11 and 16.0.1 with dotCover 2019.1 EAP6 (workstations not tested with any older dotCover versions)
Environment:
- Build agent running Windows Server 2012 R2
- TeamCity 2018.1.3
- dotCover console runner 2018.3.4 (also fails with the bundled 2018.1.2)
- VSTest 2017
Log:
[09:54:35] TeamCity custom logger was not found
[09:54:35] VSTest will report tests to TeamCity after run
[09:54:35] VSTest executable: E:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe
[09:54:35] Command line params: [[REDACTED ASSEMBLY NAME] [/Logger:trx] [/Platform:x86] [/TestCaseFilter:TestCategory!=Integration]] [09:54:35] Starting: E:\BuildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.NUnitLauncher.exe #TeamCityImplicit
[09:54:35] in directory: E:\BuildAgent\work\85e2d8d8e2780ae7
[09:54:38] JetBrains dotCover Console Runner 2018.3.4. Build 777.0.20190304.45822
[09:54:38] Copyright (c) 2009-2019 JetBrains s.r.o. All rights reserved.
[09:54:38] [JetBrains dotCover] Coverage session started [4/12/2019 9:54:39 AM] [09:54:41] Microsoft (R) Test Execution Command Line Tool Version 15.9.0
[09:54:41] Copyright (c) Microsoft Corporation. All rights reserved.
[09:54:41] [09:54:43] Starting test execution, please wait...
[09:55:00] Passed RedactedTest1
[09:55:00] Passed RedactedTest2
[09:55:00] Passed RedactedTest3
[09:55:00] Passed RedactedTest4
[09:55:00] Passed RedactedTest5
[09:55:04] Results File: E:\BuildAgent\work\85e2d8d8e2780ae7\TestResults\devbuilds_DEV-BUILDER-01_2019-04-12_09_55_01.trx
[09:55:04] [09:55:04] Total tests: 5. Passed: 5. Failed: 0. Skipped: 0.
[09:55:04] Test Run Successful.
[09:55:04] Test execution time: 9.6362 Seconds
[09:55:06] [JetBrains dotCover] Coverage session finished with errors: Error HRESULT E_FAIL has been returned from a call to a COM component
[09:55:06] PDB server error: Invalid MVID for the absolute module path is detected
[09:55:06] [location] = c:\build agent\work\cf3eb19e8ddb7658\profiler\kernel\windows\native\solution\pdb_server\src\pdb_processor.cpp(174)
[09:55:06] [function] = unsigned int __cdecl jbprof::pdb_processor::load_module(const class boost::filesystem::path &,const struct _GUID &)
[09:55:06] [location] = c:\build agent\work\cf3eb19e8ddb7658\profiler\kernel\windows\native\solution\core\src\bridges\pdb\pdb_bridge.cpp(195)
[09:55:06] [function] = void __thiscall jbprof::pdb_bridge::send_receive_command(const char *,enum jbprof::pdb_bridge::time_key,enum jbprof::pdb_bridge::time_key,enum jbprof::pdb_bridge_command,enum jbprof::pdb_bridge_answer,class std::function<void __cdecl(struct write_stream_iface *)>,class std::function<void __cdecl(struct read_stream_iface *)>).
[09:55:06] Importing data from 'E:\BuildAgent\temp\buildTmp\coverage_dotcover44359873727558036481.data' (not existing file) with 'dotNetCoverage' processor
[09:55:06] Rejected coverage report file: E:\BuildAgent\temp\buildTmp\coverage_dotcover44359873727558036481.data size: 0. File is empty or does not exist
[09:55:06] Process exited with code -2
[09:55:06] Importing data from 'E:\BuildAgent\work\85e2d8d8e2780ae7\TestResults\devbuilds_DEV-BUILDER-01_2019-04-12_09_55_01.trx' (4.86 KB) with 'vstest' processor
Please sign in to leave a comment.
I'm also seeing "[JetBrains dotCover] Coverage session finished with errors: PDB server error: Invalid MVID for the absolute module path is detected" but with NUnit tests. Also using built-in coverage tool.
Hi both,
I'm forwarding your request internally for further inspection, but please, consider that this error seems to happen always under third party disruptions on the file system:
-Having your data in One Drive: https://youtrack.jetbrains.com/issue/DCVR-9090
-Enabling Data deduplication on the server: https://youtrack.jetbrains.com/issue/DCVR-9218
-A very specific antivirus: https://youtrack.jetbrains.com/issue/DCVR-9395
-A fourth report that after mentioning the prior ones never answered (usually a sign that any of those other solutions were the cause).
If none of this conditions apply to you, please check for possible third party software that might be obstructing or altering dotcover's interaction with the files (AV, backups, OS systems...)
Hi Denis, thanks for your response. In our case, CrowdStrike is likely the culprit.
Does JetBrains intend to implement a fix for these kinds of situations? I can understand not supporting data in OneDrive, but deduplication and antivirus are common scenarios on servers so it seems logical that TeamCity should be able to handle them gracefully.
Hi,
to be strict in the answer, the issue is in the dotcover engine itself (which is a separate product of which we use some parts), so our devs can only wait until DotCover fixes it to then be able to implement the solution. As usual, please vote on the related issues in the tracker, and feel free to leave a comment about your scenario if you can provide extra information not available there. Having the best information in the tracker should help in prioritizing the issue and fixing it as soon as possible. You should also get notified when progress is taken. We will usually integrate changes from a dotcover release in the following TeamCity release, but once it's fixed feel free to ping us just in case.
On the other hand, if the issue is with the antivirus, it's often required to communicate with the AV vendor to search for a combined solution. I'm unaware of other AV vendors presenting the same (or similar) issue at this moment, which should imply that the particular AV is more disrupting than others for this kind of operations. It might be worth considering a report to the AV vendor as well to bring them to the attention that this is impacting their user base while others don't.
The user in the issue reports that excluding CrowdStrike from dotcover (and maybe excluding crowdstrike from the working folders of the build agents) makes the issue go away, so please test that as a workaround.
Hi
Could you make sure this issue is reproducible after updating dotCover to 2019.1.0-eap07 via Administration\Tools