执行xmake f -c或任何需要检测环境的xmake命令，windows系统整个卡死 #549
Comments
|
可能是xmake调用的某个vs命令导致的 可以进入xmake的安装脚本目录找到core/base/os.lua文件里面 os.execv 函数，里面在执行前 通过 print 打印下 执行的完整命令 和参数 然后触发xmake f -c 看下，实际导致卡死时候，最后执行的哪个命令 以及参数 然后你可以手动在cmd下执行这个命令 看看时候也会出现这个问题 如果是的话，就贴出来看看时候调用的不对，或者在你这有兼容问题 再尝试想办法处理下。 |
遇到一点小麻烦，不太懂lua，不知道怎么展开打印table类型的argv，不管从刚才的实验结果看，貌似vswhere那一步没问题，卡在之后的xmake的临时目录下的一个bat脚本上了 |
|
你试试 print(os.args(argv)) 把参数列表转成 string打印 |
|
不过看描述 应该是卡在执行vs自带的 vcvarsall.bat脚本去获取vc tools相关环境envs时候卡住了 应该是卡在这块了 |
|
你可以打开这个脚本看下 C:\Users\shiel\AppData\Local\Temp.xmake\190825_6B246CAA4821844DBC53CA66C68506FD_genvcvars.bat 或者尝试在cmd里面直接执行下 看看是否也会卡 |
刚刚按你的建议试了一下，又死机了，图都截不了。
|
|
你把 os.run(genvcvars_bat) 这行注释掉 就不会卡了 然后把这个bat文件内容发我看下 |
@echo off
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 > nul
echo path = %path% > C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo lib = %lib% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo libpath = %libpath% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo include = %include% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo DevEnvdir = %DevEnvdir% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo VSInstallDir = %VSInstallDir% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo VCInstallDir = %VCInstallDir% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo WindowsSdkDir = %WindowsSdkDir% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo WindowsLibPath = %WindowsLibPath% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo WindowsSDKVersion = %WindowsSDKVersion% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo WindowsSdkBinPath = %WindowsSdkBinPath% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo UniversalCRTSdkDir = %UniversalCRTSdkDir% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt
echo UCRTVersion = %UCRTVersion% >> C:\Users\shiel\AppData\Local\Temp\.xmake\190825\_49A9C672BF47E04BA0C7D4395B9C1E05_genvcvars.txt |
我试着手动执行 |
|
看着没啥问题 你手动在cmd下 执行 "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" x86试试，如果这样执行也会挂，那只能是你这新版的vs环境有问题了 这个脚本就是vs提供的 command 终端编译环境 你也可以在开始菜单里找到 vs 的命令行x86环境打开试试 看看会不会卡死 |
|
vcvarsall.bat这个脚本本身执行就会卡死，这个xmake也没办法了，目前这边都是依赖这个bat提供的vs tools envs信息来调用cl.exe 如果vs提供的这个脚本有问题 那就没辙了 |
那确实,只能等微软下一个版本修bug了 |
|
要么你试试自己从开始菜单打开vs command prompt 看看正常吗？如果正常 可以对比下两者的调用传参 是否有差异 看看能否避免这个问题 |
试了，见鬼。cmd还是卡住，不过新提供的powershell入口倒是可用。 |
|
额 难道vs打算要废弃cmd那个入口了？能贴下powershell那个入口的 执行命令和参数吗？我看看能否通过这个获取下vs tools相关envs信息 |
命令是C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -NoExit -Command "& { Import-Module .\Common7\Tools\vsdevshell\Microsoft.VisualStudio.DevShell.dll; Enter-VsDevShell -InstanceId 336753b3}" |
|
好的 回头我看看能否切到ps的入口来获取相关信息 |
感谢你的回复，我这边也会照这个思路尝试解决问题（powershell的传参和cmd差异貌似还挺大的） |
我稍微试了一下，在vs提供的developer powershell中，可以通过$env驱动器获取相关envvars。 |
|
好的 回头我参考着支持下 |
|
我这边也尝试更新了下 vs2019 。。developer powershell应该是这次更新才新加的，之前的老版本vs2019中并没有这个。。不过cmd版本入口我这边倒是能打开，并没有导致系统卡死，xmake运行检测也能通过 |
|
我记得很早就有了。但是powershell版的好像并没有分架构和目标平台啊 |
|
我这里 cmd 也没问题 ，已经更新最新版 VS。 |
|
@ChanthMiao 感觉是你的 VS 装炸了啊。 |
$ powershell -ExecutionPolicy ByPass -File test.ps1
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.23.28008\lib\x86;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\ucrt\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.17763.0\um\x86;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.23.28008\lib\x86;C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.23.28008\lib\x86\store\references;C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.17763.0;C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0;C:\Windows\Microsoft.NET\Framework\v4.0.30319;
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.23.28008\include;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\shared;C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\winrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\cppwinrt整了段test代码dump了下，似乎默认获取的是x86的环境。。不知道怎么切到x64， -arch参数似乎不行。。 |
|
没用，他就是把 Developer Command Prompt for VS 2019 包了一下，只有 VC 那几个才能选环境。 |
|
额。。那岂不是最后还是用了vcvarsall.bat。。= = |
|
x64 的话大概是这个，那个 Enter-VsDevShell -Verbose -InstanceId fe1916c5 -DevCmdArguments "-arch=amd64" |
|
实际上做的事情和 xmake 差不多嘛。 |
|
不过为什么 @ChanthMiao 那 ps 入口没卡，cmd卡了，有点怪了。。如果只是特定用户由于升级挂了，导致cmd失效，那么即使切到ps入口去探测，也有可能出现其他用户ps入口跪了，cmd没跪的情况，不管怎么兼容，都没法完全解决这种问题。。 这块先待定吧，看看是否还会有其他用户反馈cmd入口问题，@ChanthMiao 你可以尝试重新升级下试试 这个版本暂时先不动了，这两天要封板了。。 |
|
我试着重装了VS，但还是一样，cmd入口不可用。见鬼了。 |
我貌似找到出问题的地方了！！！ @REM Send Telemetry
if "%VSCMD_SKIP_SENDTELEMETRY%"=="" (
if "%VSCMD_DEBUG%" NEQ "" (
@echo [DEBUG:%~nx0] Sending telemetry
powershell.exe -Command "& {Import-Module '%~dp0\vsdevshell\Microsoft.VisualStudio.DevShell.dll'; Send-VsDevShellTelemetry -NewInstanceType Cmd; }"
) else (
START "" /B powershell.exe -Command "& {Import-Module '%~dp0\vsdevshell\Microsoft.VisualStudio.DevShell.dll'; Send-VsDevShellTelemetry -NewInstanceType Cmd; }" > NUL
)
)经过我多次手动从cmd执行（set VSCMD_DEBUG=2）该文件，观察到每次都是在这里卡住。 |
|
刚刚在vs的开发者社区搜到了临时解决方案： 暂时可以确定，我遇到的问题是由新版本vs提供的bat文件造成的（powershell入口自动调用该文件貌似无影响，手动在powershell执行该脚本却一样会出错） |
你在下面这行后面加上VSCMD_SKIP_SENDTELEMETRY设置试试，如果可以的话 可以提个pr过来 |
已提交 |
|
现在可以确保xmake在Windows正常检测到vs2019环境了，但是如果要从别处进入vs2019开发者控制台（cmd）而不出错的话，还是得靠系统环境变量苟活，，，只能希望微软下个版本修复这个bug了。 |
这种vs自身引入的bug，目前也只能先通过这种方式绕过了 |
|
@ChanthMiao 我改进了下，限制只对 >= vs2019之后的版本，添加这个env，你试试，是否还是能够正常处理 |
稍等，马上 |
可以正常运行，没有问题 |
ok |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
执行xmake f -c或任何需要检测环境的xmake命令，windows系统整个卡死。powershell无响应。GUI响应异常，键鼠可用，但大部分操作无响应，只能通过电源键强制关机。
Expected behavior
检测出正确的工具链（vs2019），并顺利执行后续相关动作。
Error output
输出表示已成功检测到x64架构，但后续无响应（多次尝试，最多多输出一行‘vswhere.exe’），整个系统会在短短1~2秒内卡死。
xmake -v -D无帮助，似乎在到达前进程已无响应。
Related Environment
xmake v2.2.7+201906192321
Windows 10 Pro x64 1903（18362.295）
Microsoft visual studio community 2019 16.2.3+29215.179
Additional context
崩溃现象是在最近一次vs版本升级后出现的，在此之前3个月内没有问题。
The text was updated successfully, but these errors were encountered: