c – cl.exe在通过MSBuild调用时无限期挂起

我试图在我的(主要是C)项目上运行MSBuild(想象一个非常庞大的代码库). Visual Studio 2015是有问题的工具集(
Windows 7 SP1和VS 2015 Update 2).即使使用/ m:1(从而强制它只使用一个处理器),我发现一些完全随机的项目在编译阶段不断挂起.例如,当发生此问题时,如果我查看违规项目及其包含的文件,我可以看到已为每个翻译单元成功创建.obj文件.然而,系统从未进入链接阶段.我看到两个cl.exe实例在任务管理器上闲置并且什么都不做.也许在30分钟后,当我杀死其中一个实例时,我会得到类似的东西:

cl : Command line error D8040: error creating or communicating with child 
process [Path_To_The_Project_Where_The_Compiler_Was_Stuck.vcxproj]

在此之后,令人惊讶的是,编译器继续以其快乐的方式从它停止的地方开始.

有没有人碰到类似的东西?在过去的几周里,这一直让我感到害怕!

更新了IInspectable查询的答案:

这看起来有点毛茸茸.请有更好的编辑技巧的人,你能帮助我以更好的方式格式化这个,这样人们就不会睁大眼睛了吗?

0:002> ~*kv

   0  Id: 842c.86b0 Suspend: 1 Teb: 000007ff`fffde000 Unfrozen
Child-SP          RetAddr           : Args to Child                                                           : Call Site
00000000`0024e008 00000000`774b8db8 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`774c3649 : ntdll!ZwWaitForSingleObject+0xa
00000000`0024e010 00000000`774b8cb4 : 00000000`00000001 00000000`0024e1d0 ffffffff`ffffffff 00000000`775a2490 : ntdll!RtlpWaitOnCriticalSection+0xe8
00000000`0024e0c0 00000000`774c25d4 : 000007fe`e012e3a0 00000000`0024e2c0 00000000`77350000 00000000`0000003c : ntdll!RtlEnterCriticalSection+0xd1
00000000`0024e0f0 00000000`774c2631 : 000007fe`fd25ace0 00000000`00004f03 ffffffff`ffffff00 00000000`00000000 : ntdll!LdrGetProcedureAddressEx+0x42d
00000000`0024e260 000007fe`fd2133d0 : 000007fe`fd25ace0 000007fe`fd256ee0 00000000`00004f03 00000000`0024e438 : ntdll!LdrGetProcedureAddress+0x11
00000000`0024e2a0 000007fe`e008f77d : 000007fe`e0163c58 000007fe`fd210000 000007fe`e012d890 00000000`0024e438 : KERNELBASE!GetProcAddress+0x5c
00000000`0024e2e0 000007fe`e008f5f1 : 00000000`00000000 ffffffff`ffffffff 00000000`0024e4d0 000007fe`fd1014bd : ucrtbase!try_get_function+0xed
00000000`0024e330 000007fe`e008f2c0 : 00000000`0024e4d0 00000000`00489198 00000000`004891b8 00000000`00000000 : ucrtbase!GetLocaleNameFromDefault+0x4d
00000000`0024e430 000007fe`e00871d8 : 00000000`00000004 00000000`004892c2 00000000`004891b8 00000000`00493ba0 : ucrtbase!__acrt_get_qualified_locale+0x74
00000000`0024e480 000007fe`e008aae3 : 00000000`00000000 00000000`0024e738 00000000`00000000 00000000`0024e820 : ucrtbase!_expandlocale+0x2c8
00000000`0024e6f0 000007fe`e008a5cd : 00000000`00200000 00000000`00240016 00000000`00000007 00000000`00493ba0 : ucrtbase!_wsetlocale_set_cat+0xab
00000000`0024ea60 000007fe`e008752a : 00000020`00000000 00000000`0000000a 003d0041`004c0019 00000000`0024ed50 : ucrtbase!_wsetlocale_nolock+0x10d
00000000`0024ecb0 000007fe`e00888f7 : 00000000`00000000 00000000`00000000 00000000`00000158 00000000`00000000 : ucrtbase!<lambda_30712929f77e709619002f448b6a9510>::operator()+0x3a
00000000`0024ed00 000007fe`e0085e2f : 00000000`0024ee50 00000000`00000000 00000000`77371eb0 00000000`0024ed90 : ucrtbase!__crt_seh_guarded_call<void>::operator()<<lambda_d67e8342c384adda8f857579ab50b2ae>,<lambda_30712929f77e709619002f448b6a9510> & __ptr64,<lambda_4525336fd7e478d965fb7ca7a337cad8> >+0x3b
00000000`0024ed30 000007fe`e0088935 : 00000000`00000004 00000000`00000004 00000000`0024ee38 00000000`0024ee59 : ucrtbase!<lambda_2af78c5f5901b1372d98f9ab3177dfa6>::operator()+0x8b
00000000`0024ed90 000007fe`e0086c18 : 00000000`00000000 00000000`00000000 00000000`00000005 00000000`0024ee38 : ucrtbase!__crt_seh_guarded_call<void>::operator()<<lambda_5df02c53a8f32f81fd64e5bbb78039f1>,<lambda_2af78c5f5901b1372d98f9ab3177dfa6> & __ptr64,<lambda_f51fe5fd7c79a33db34fc9310f277369> & __ptr64>+0x15
00000000`0024edc0 000007fe`e0085e62 : 00000000`00000003 00000000`00000002 00000000`00000005 00000000`00489100 : ucrtbase!call_wsetlocale+0x288
00000000`0024eec0 00000001`3f258409 : 00000000`00000100 00000000`00000000 00000000`00000100 063707fe`00030000 : ucrtbase!setlocale+0x22
00000000`0024ef30 00000001`3f27cd2c : 00000000`00000000 00000001`3f32e270 000007fe`e0163818 00000000`00000000 : link!wmain+0xed
00000000`0024f790 00000000`773659bd : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : link!MOD::FHasCorMeta+0x238
00000000`0024f7d0 00000000`7749a2e1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`0024f800 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

   1  Id: 842c.73bc Suspend: 1 Teb: 000007ff`fffdc000 Unfrozen
Child-SP          RetAddr           : Args to Child                                                           : Call Site
00000000`0287f118 00000000`774b8db8 : 00000000`003c0a18 00000000`000000e0 00000000`003c0000 00000000`0000000a : ntdll!ZwWaitForSingleObject+0xa
00000000`0287f120 00000000`774b8cb4 : 00000000`00000000 00000000`00000002 00000000`00000043 000007fe`e01639c0 : ntdll!RtlpWaitOnCriticalSection+0xe8
00000000`0287f1d0 000007fe`e008872f : 00000000`0287f2c0 00000000`0287f260 00000000`0287f290 00000000`00000000 : ntdll!RtlEnterCriticalSection+0xd1
00000000`0287f200 000007fe`e0089255 : 000007fe`e012db80 000007fe`e01625c0 00000000`00000000 00000000`0287f260 : ucrtbase!__crt_seh_guarded_call<void>::operator()<<lambda_5e887d1dcbef67a5eb4283622ba103bf>,<lambda_4466841279450cc726390878d4a41900> & __ptr64,<lambda_341c25c0346d94847f1f3c463c57e077> >+0x3f
00000000`0287f240 00000000`7749a52c : 000007fe`e0089060 000007fe`00000005 000007ff`fffd8000 00000000`00000005 : ucrtbase!__acrt_DllMain+0x1f5
00000000`0287f2e0 00000000`7749a1ef : 000007ff`fffd8000 00000000`00000000 000007ff`fffdc000 00000000`00000000 : ntdll!LdrpInitializeThread+0x17c
00000000`0287f3e0 00000000`7749a0ee : 00000000`0287f4a0 00000000`00000000 000007ff`fffd8000 00000000`00000000 : ntdll!LdrpInitialize+0x9f
00000000`0287f450 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe

#  2  Id: 842c.71d8 Suspend: 1 Teb: 000007ff`fffda000 Unfrozen
Child-SP          RetAddr           : Args to Child                                                           : Call Site
00000000`0275f9e8 00000000`77562c88 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!DbgBreakPoint
00000000`0275f9f0 00000000`773659bd : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!DbgUiRemoteBreakin+0x38
00000000`0275fa20 00000000`7749a2e1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`0275fa50 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

这是锁扩展的输出:

0:002> !locks

CritSec ntdll!LdrpLoaderLock+0 at 00000000775a2490
WaiterWoken        No
LockCount          1
RecursionCount     1
OwningThread       73bc
EntryCount         0
ContentionCount    2
*** Locked

CritSec ucrtbase!wenviron_table+c0 at 000007fee01639c0
WaiterWoken        No
LockCount          1
RecursionCount     1
OwningThread       86b0
EntryCount         0
ContentionCount    1
*** Locked

Scanned 417 critical sections

它显而易见的线程86b0和73bc正在相互等待,但我无法弄清楚它们是如何进入这种状态的!

最佳答案 从这个
link安装UCRT可分发程序为我解决了这个问题.

点赞