症状是每周大约一次DFSR（分布式文件系统复制）停止复制并且Windows备份（wbengine.exe）停止响应。 当我分析他们的等待链时，他们正在等待dfsrs.exe线程：4664和线程：4680. dfsrs.exe正在等待线程：4664。
我杀dfsrs.exe和wbengine开始响应。 日志说，由于创build卷影副本超时，备份失败。
重新启动dfsrs.exe，我们又回来了。
两台新的Server 2012 R2计算机（完全更新）发生此问题，DFS共享彼此。 禁用Windows备份在机器上似乎阻止它导致问题（即使我们有其他软件，创build多个日常卷影副本）。 两台服务器上都有非微软的软件。
我把进程的转储文件作为卡住的状态，但是我想VSSVC.dmp将是最重要的一个。 我不知道如何使用WinDbg，但这里是我得到的结果：
0:000> !analyze -hang ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. Probably caused by : dfsrs.exe ( dfsrs!RunTaskCallback+17 ) Followup: MachineOwner ------------------------------------- 0:000> !dml_proc DbgId PID Image file name 0 8c8 C:\Windows\System32\dfsrs.exe 0:000> !dml_proc 0x0 DbgId PID Image file name 0 8c8 C:\Windows\System32\dfsrs.exe Browse module list Threads: DbgId TID Name (if available) 0 8cc "<No name>" 1 8e8 "<No name>" 2 1a70 "<No name>" 3 1a94 "<No name>" 4 1af0 "<No name>" 5 306c "<No name>" 6 5d4 "<No name>" 7 2648 "<No name>" 8 2654 "<No name>" 9 204c "<No name>" a 2cd0 "<No name>" b 304c "<No name>" c 784 "<No name>" d eec "<No name>" e 3220 "<No name>" f 298c "<No name>" 10 1238 "<No name>" 11 2b80 "<No name>" 12 1248 "<No name>" 13 3464 "<No name>" 14 2cf0 "<No name>" 15 31ac "<No name>" 16 3100 "<No name>" 17 308c "<No name>" 18 2a74 "<No name>" 19 18e0 "<No name>" ------------------- 0:000> ~[0x10]s;kM ntdll!NtWaitForSingleObject+0xa: 00007ffc`27e606fa c3 ret # Child-SP RetAddr Call Site 00 0000008e`4af1c348 00007ffc`25111118 ntdll!NtWaitForSingleObject+0xa 01 0000008e`4af1c350 00007ff7`0540754f KERNELBASE!WaitForSingleObjectEx+0x94 02 0000008e`4af1c3f0 00007ff7`0537d78c dfsrs!Task::ShutDown+0x283 03 0000008e`4af1c490 00007ff7`053e0656 dfsrs!UpdateDistributionTask::RemoveUpdateTask+0x2c 04 0000008e`4af1c540 00007ff7`053b845c dfsrs!UpdateManager::FinalizeUpdateManager+0x152 05 0000008e`4af1c5d0 00007ff7`053ab007 dfsrs!InConnection::InConnectionContentSetContext::FinalizeInConnectionContentSetContext+0x2e4 06 0000008e`4af1c740 00007ff7`053752e2 dfsrs!InConnection::DeleteContentSetFromInConnection+0x2a3 07 0000008e`4af1c870 00007ff7`0534f1b4 dfsrs!ReplicaSetManager::DeleteContentSetFromReplicaSetManager+0x1e2 08 0000008e`4af1c950 00007ff7`05338e89 dfsrs!ContentSetManager::InternalFinalizeContentSetManager+0x310 09 0000008e`4af1cbe0 00007ff7`053362c5 dfsrs!VolumeManager::FinalizeVolumeManager+0x265 0a 0000008e`4af1ccd0 00007ff7`05323b1a dfsrs!VolumeManager::ShutdownVolume+0x265 0b 0000008e`4af1ce20 00007ff7`05227034 dfsrs!FrsReplicator::FinalizeReplicator+0x182 0c 0000008e`4af1cef0 00007ff7`05239c0f dfsrs!FrsService::InternalShutdown+0x1f4 0d 0000008e`4af1d030 00007ffc`23896e83 dfsrs!VssWriter::OnPrepareSnapshot+0x12f 0e 0000008e`4af1d0a0 00007ffc`2389d145 vssapi!CVssWriterImpl::OnPrepareSnapshotGuard+0x2b 0f 0000008e`4af1d0d0 00007ffc`2389c470 vssapi!CVssWriterImpl::PrepareForSnapshotInternal+0xc71 10 0000008e`4af1e150 00007ffc`270e20f3 vssapi!CVssWriterImpl::PrepareForSnapshot+0x50 11 0000008e`4af1e1a0 00007ffc`270e6fad rpcrt4!Invoke+0x73 12 0000008e`4af1e200 00007ffc`2757d58a rpcrt4!NdrStubCall2+0x35e 13 0000008e`4af1e870 00007ffc`272522b3 combase!CStdStubBuffer_Invoke+0xa0 14 0000008e`4af1e8b0 00007ffc`275786ad oleaut32!CUnivStubWrapper::Invoke+0x53 15 0000008e`4af1e900 00007ffc`27404f5a combase!SyncStubInvoke+0x205 16 (Inline Function) --------`-------- combase!StubInvoke+0xc0 17 0000008e`4af1eaa0 00007ffc`2757951f combase!CCtxComChnl::ContextInvoke+0x27a 18 (Inline Function) --------`-------- combase!DefaultInvokeInApartment+0x51 19 0000008e`4af1ecb0 00007ffc`27578fb0 combase!AppInvoke+0x1af 1a 0000008e`4af1eda0 00007ffc`27579b35 combase!ComInvokeWithLockAndIPID+0x676 1b 0000008e`4af1efe0 00007ffc`270e2467 combase!ThreadInvoke+0x48a 1c 0000008e`4af1f0b0 00007ffc`270e22c0 rpcrt4!DispatchToStubInCNoAvrf+0x33 1d 0000008e`4af1f100 00007ffc`270eaa88 rpcrt4!RPC_INTERFACE::DispatchToStubWorker+0x190 1e 0000008e`4af1f200 00007ffc`270e2d26 rpcrt4!LRPC_SCALL::DispatchRequest+0x4c9 1f 0000008e`4af1f310 00007ffc`270e2b78 rpcrt4!LRPC_SCALL::HandleRequest+0x291 20 0000008e`4af1f3c0 00007ffc`270e195d rpcrt4!LRPC_SASSOCIATION::HandleRequest+0x238 21 0000008e`4af1f450 00007ffc`270e175e rpcrt4!LRPC_ADDRESS::ProcessIO+0x444 22 0000008e`4af1f590 00007ffc`27e0af00 rpcrt4!LrpcIoComplete+0x144 23 0000008e`4af1f630 00007ffc`27e09238 ntdll!TppAlpcpExecuteCallback+0x210 24 0000008e`4af1f6a0 00007ffc`254d13d2 ntdll!TppWorkerThread+0x888 25 0000008e`4af1fa80 00007ffc`27de54e4 kernel32!BaseThreadInitThunk+0x22 26 0000008e`4af1fab0 00000000`00000000 ntdll!RtlUserThreadStart+0x34 任何想法从哪里去？ 我没有想到在服务被冻结时运行进程资源pipe理器，但是如果我们想要尝试的话，下一周它会再次冻结。
好了，问题最终成为备份软件（Syncovery），即使软件本身完成工作，也有内存泄漏，导致VSS卡住。 更新似乎已经解决了这个问题。