Closed rob-scheepens closed 3 years ago
Adding Yuri @ybendito
I noticed that on the VS build vm in procmon the path C:\Program Files (x86)\Windows Kits\8.1\Include\shared\sdkddkver.h
is referenced. I manually copied that file to the EWDK build vm, but that did not make a change. In fact, procmon only shows queries for that file in C:\ewdk_1809\Program Files\Windows Kits\10\Include\10.0.17763.0\shared\sdkddkver.h
. Perhaps an env var is missing? I've attached the two procmon runs.
sdkddk_filter_procmon.txt
Opening a support case with Microsoft confirmed that WindowsTargetPlatformVersion should be changed. Several vcxproj files have this set to 8.1, which won't work with EWDK 1809. Changing all instances to $(LatestTargetPlatformVersion) resolved that problem.
Another issue was errors about missing .metaproj files when building using MSBuild. Setting MSBUILDEMITSOLUTION=1 resolved that. Only remaining errors now are:
C:\git\kvm-guest-drivers-windows\viosock\ViosockPackage\ViosockPackage.vcxproj(197,5): error MSB3030: Could not copy the file "..\lib\x86\Win10Release\viosocklib.pdb" because it was not found.
C:\git\kvm-guest-drivers-windows\viosock\ViosockPackage\ViosockPackage.vcxproj(197,5): error MSB3030: Could not copy the file "..\lib\x86\Win10Release\viosocklib.dll" because it was not found.
These can be explained since https://github.com/virtio-win/kvm-guest-drivers-windows/blob/57eee37e5ccfee280d35de2998b30baa34d555cd/viosock/ViosockPackage/ViosockPackage.vcxproj#L188 also lists these x86 files even when only building x64. I need to dig into why this dependency for x86 files is present, but that is of lower priority, since the build still works. Easy workaround is to build x86 before x64, then build succeeds 100%.
Additionally, EWDK 1809 generates various warnings 1303:
C:\git\kvm-guest-drivers-windows\viorng\viorng\viorng.inf(98-98): warning 1303: Found legacy AddReg operation defining co-installers (CoInstallers32). [C:\git\kvm-guest-drivers-windows\viorng\VirtRNG Pa
ckage\VirtRNG Package.vcxproj]
C:\git\kvm-guest-drivers-windows\viosock\sys\viosock_wow_co.inx(99-99): warning 1303: Found legacy AddReg operation defining co-installers (CoInstallers32). [C:\git\kvm-guest-drivers-windows\viosock\sys
\viosock.vcxproj]
For now these warnings don't block building, but I'll create a new issue for this.
C:\git\kvm-guest-drivers-windows\viorng\viorng\viorng.inf(98-98): warning 1303: Found legacy AddReg operation defining co-installers (CoInstallers32). [C:\git\kvm-guest-drivers-windows\viorng\VirtRNG Pa ckage\VirtRNG Package.vcxproj] C:\git\kvm-guest-drivers-windows\viosock\sys\viosock_wow_co.inx(99-99): warning 1303: Found legacy AddReg operation defining co-installers (CoInstallers32). [C:\git\kvm-guest-drivers-windows\viosock\sys \viosock.vcxproj]
Most probably we need to solve this on the installer level. Additional components should be installed with the driver in both cases. On other hand, AddReg is breaking the "Universal" platform target.
Hi,
also lists these x86 files even when only building x64. I need to dig into why this dependency for x86 files is present, but that is of lower priority, since the build still works. Easy workaround is to build x86 before x64, then build succeeds 100%.
WOW64. x86 apps require x86 socket provider, it should be installed along with x64 provider on Windows x64. Thus it is really necessary to build x86 viosock (at least viosocklib.dll) before x64.
C:\git\kvm-guest-drivers-windows\viosock\sys\viosock_wow_co.inx(99-99): warning 1303: Found legacy AddReg operation defining co-installers (CoInstallers32). [C:\git\kvm-guest-drivers-windows\viosock\sys \viosock.vcxproj]
Remove
Regards, Ilya
I do not exactly understand why we need to focus now on warnings. Probably better idea is to spawn the task of converting coinstallers (deprecated for universal drivers, i.e. actually for ARM) to extension INF which is legitimate method of spawning software installation as a result of hardware installation.
This is fixed by https://github.com/virtio-win/kvm-guest-drivers-windows/pull/542.
I've started to experiment with building the drivers using EWDK, 1809 at first, to remove the VS dependencies. I setup Windows Server 2019 core, so no ui. I downloaded EWDK 1809 on it, and installed winfsp and cpdk on it, as well as the 1809 sdk, needed for windows.h. Short setup for winfsp and 1809 sdk:
choco install -y winfsp windows-sdk-10-version-1809-all
For cpdk I used:After that, I ran
msbuild -p:Configuration=Win10%20Release -p:Platform=x64
, and that fails on:I thought it's because that project is of an older version of VS, but it's not. The SDKDDKVer.h seems to be present in
C:\ewdk_1809\Program Files\Windows Kits\10\Include\10.0.17763.0\shared
, and that's included in my path:Path=C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86;C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin\Roslyn;x86;C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\\MSBuild\15.0\bin;C:\Windows\Microsoft.NET\Framework\v4.0.30319;C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\;C:\ewdk_1809\Program Files\Microsoft Visual Studio\2017\BuildTools\Common7\Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\ProgramData\chocolatey\bin;C:\Program Files\OpenSSH-Win64;C:\Program Files\Git\cmd;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Users\Administrator\AppData\Local\Microsoft\WindowsApps;;C:\ewdk_1809\Program Files\Windows Kits\10\\bin\10.0.17763.0\x86;C:\ewdk_1809\Program Files\Windows Kits\10\\Tools\bin\i386;C:\ewdk_1809\Program Files\Windows Kits\10\\tools;C:\ewdk_1809\Program Files\Windows Kits\10\\tools\ARM64;C:\ewdk_1809\BuildEnv;"C:\Program Files (x86)\Windows Kits\10\Include";"C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um";"C:\ewdk_1809\Program Files\Windows Kits\10\Include\10.0.17763.0\shared"
Then again, EWDK is using VS2017 while the project is defined for VS2015. Could that be it? I changed
WindowsTargetPlatformVersion
to10.0.17763.0
from the original8.1
, but that did not make a difference.