Test failure: Exceptions_ForeignThread._ForeignThreadExceptions_ForeignThreadExceptions_/_ForeignThreadExceptions_ForeignThreadExceptions_cmd

Opened on behalf of @RussKeldorph

The test Exceptions_ForeignThread._ForeignThreadExceptions_ForeignThreadExceptions_/_ForeignThreadExceptions_ForeignThreadExceptions_cmd has failed.

Return code:      1
Raw output file:      C:\dotnetbuild\work\d0e5c98a-24b6-4afd-baee-3a2ab651d33b\Work\615ccb8d-9ab1-40e7-bdd1-c860e20caa71\Unzip\Reports\Exceptions.ForeignThread\ForeignThreadExceptions\ForeignThreadExceptions.output.txt
Raw output:
BEGIN EXECUTION\r
 "C:\dotnetbuild\work\d0e5c98a-24b6-4afd-baee-3a2ab651d33b\Payload\corerun.exe" ForeignThreadExceptions.exe \r
Failed to catch an exception! System.DllNotFoundException: Unable to load DLL 'ForeignThreadExceptionsNative': The specified module could not be found. (Exception from HRESULT: 0x8007007E)\r
   at ForeignThreadExceptionsTest.InvokeCallback(MyCallback callback)\r
   at ForeignThreadExceptionsTest.RunTest()\r
   at ForeignThreadExceptionsTest.Main()\r
Expected: 100\r
Actual: 1\r
END EXECUTION - FAILED\r
FAILED\r
Test Harness Exitcode is : 1\r

To run the test:
> set CORE_ROOT=C:\dotnetbuild\work\d0e5c98a-24b6-4afd-baee-3a2ab651d33b\Payload
> C:\dotnetbuild\work\d0e5c98a-24b6-4afd-baee-3a2ab651d33b\Work\615ccb8d-9ab1-40e7-bdd1-c860e20caa71\Unzip\ForeignThreadExceptions\ForeignThreadExceptions.cmd
\r
Expected: True\r
Actual:   False

    Stack Trace:

       at Exceptions_ForeignThread._ForeignThreadExceptions_ForeignThreadExceptions_._ForeignThreadExceptions_ForeignThreadExceptions_cmd()

Build : Master - 20170719.02 (Core Tests)
Failing configurations:

• windows.10.arm64
  • arm

[RussKeldorph]

@wtgodbe Should this have been fixed by dotnet/coreclr#12781?

[wtgodbe]

@RussKeldorph yes, I'm surprised to see this failing with this error - I'll take a look

[wtgodbe]

@tijoytom @botaberg can you take a look? This is the same type of failure as https://github.com/dotnet/coreclr/issues/12488, but seems to have a different cause, as the other related tests were fixed by dotnet/coreclr#12781, and I've verified that all expected components are present in the test execution folder & in Core_Root

[jashook]

This is a dup of #7777

[danmoseley]

Closing, and it's clearly a test issue

[RussKeldorph]

@danmosemsft This test is still failing in master. Instead of closing, could we perhaps convert to a Test Bug and move to another milestone?

[BruceForstall]

The issue is the test file ForeignThreadExceptionsNative.dll depends on msvcp140.dll which is not in the package restored by dotnet/coreclr#12781.

[BruceForstall]

@wtgodbe How do we update the package used on ARM to fill CORE_ROOT with the required CRT files?

In my VS2017 install, I see:

c:\>dir /b "c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Redist\MSVC\14.14.26405\onecore\arm\Microsoft.VC141.CRT"
concrt140.dll
msvcp140.dll
msvcp140_1.dll
msvcp140_2.dll
vccorlib140.dll
vcruntime140.dll

It seems like we should update the package to include all of these files, and update the package to include the latest versions.

Also, I want to extend this to arm64 as well, to support using public arm64 tools (dotnet/coreclr#19115). How do I create and publish a package for arm64? (Or can you do both?)

E.g.:

c:\>dir /b "c:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Redist\MSVC\14.14.26405\onecore\arm64\Microsoft.VC141.CRT"
concrt140.dll
msvcp140.dll
msvcp140_1.dll
msvcp140_2.dll
vccorlib140.dll
vcruntime140.dll

[wtgodbe]

I believe that I created that package manually using the nuget pack command, or possibly with this BuildTools target: https://github.com/dotnet/buildtools/blob/78260239e4db68ad5c2df774a27d5f9a54fd92e5/src/Microsoft.DotNet.Build.Tasks/PackageFiles/packages.targets#L17, though I don't remember the specifics - @chcosta or @dagood may know the specifics there. It should be as simple as appending the now-public files to the files already present in the package. As for creating an arm64 package, you'll probably have to make both a runtime.win-arm and a runtime-win-arm64 version of the package, and have a generic version of the package that references both. You may even be able to mock up a .pkgproj similar to what's in https://github.com/dotnet/coreclr/tree/master/src/.nuget/Microsoft.NETCore.Jit, then run msbuild on it.

[dagood]

A very quick and dirty way to create these packages is to manually edit the nuspec and add files to the zip. For runtime-specific binaries, yeah, runtime packages plus an identity package with runtime.json sounds like the "minimum download" way, or you can just stick them all in the same package.

(I don't think I have any other context on this issue or what happened for the earlier one.)

[BruceForstall]

@wtgodbe @dagood First, I know essentially zero about buildtools, msbuild, packages, etc., so I barely understand what you've written. That being said, I created a vc-runtime.2.1.0.nupkg using nuget.exe CLI "pack" with the following structure:

vc-runtime.nuspec
content\VC\Redist\MSVC\14.14.26405\onecore\arm\Microsoft.VC141.CRT\concrt140.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm\Microsoft.VC141.CRT\msvcp140.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm\Microsoft.VC141.CRT\msvcp140_1.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm\Microsoft.VC141.CRT\msvcp140_2.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm\Microsoft.VC141.CRT\vccorlib140.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm\Microsoft.VC141.CRT\vcruntime140.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm64\Microsoft.VC141.CRT\concrt140.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm64\Microsoft.VC141.CRT\msvcp140.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm64\Microsoft.VC141.CRT\msvcp140_1.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm64\Microsoft.VC141.CRT\msvcp140_2.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm64\Microsoft.VC141.CRT\vccorlib140.dll
content\VC\Redist\MSVC\14.14.26405\onecore\arm64\Microsoft.VC141.CRT\vcruntime140.dll

It seemed to make more sense to me to make this an arbitrary set of files in the "content" tree, than to put them in the "lib" directory, which seems to have particular semantics, and doesn't support multi targeting. I like that this is just a packaging of the appropriate VC Redist files from the VS2017 install, with the same paths and version numbers that were used.

It's not clear the existing api-ms-win-crt-*.dll files in the current package are needed. I couldn't find any "official" location for these, nor could I find arm64 versions.

I named it vc-runtime.2.1.0.nupkg because it's currently versioned 1.2.0, but I'm not sure why. I picked 2.1.0 to correspond to the current shipping dotnet CLI, but it seems it's arbitrary.

Now: how do I get this package uploaded to myget, downloaded as part of the build, and unpacked? I don't have permissions to write to myget (e.g., https://dotnet.myget.org/feed/dotnet-buildtools/package/nuget/vc-runtime, where @wtgodbe published vc-runtime currently).

I'm really not clear what tests\src\Common\vc_runtime\vc_runtime.csproj should look like now.

I put a PR up at dotnet/coreclr#19265 with some of this work. I can send you a link to my vc-runtime.2.1.0.nupkg.

Comments? On the right track?