Windows-Server-2012-R2
Server 2012 R2 VSS 凍結並導致 DFSR 和 Win 備份失敗
症狀是大約每週一次 DFSR（分佈式文件系統複製）停止複制並且 Windows 備份 (wbengine.exe) 停止響應。當我分析他們的等待鏈時，他們正在等待 dfsrs.exe 執行緒：4664 和執行緒：4680。dfsrs.exe 正在等待執行緒：4664。
我殺死 dfsrs.exe 並且 wbengine 開始響應。日誌顯示備份失敗，因為創建卷影副本已超時。
重新啟動 dfsrs.exe，我們重新開始工作。
此問題發生在兩台新的 Server 2012 R2 機器（完全更新）上，彼此共享 DFS。在電腦上禁用 Windows 備份似乎可以阻止它導致問題（即使我們有其他軟體可以創建多個每日卷影副本）。兩台伺服器上幾乎沒有非微軟軟體。
我獲取了處於卡住狀態的程序的轉儲文件，但我猜 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有什麼想法可以從這裡開始嗎？我沒想過在服務被凍結時執行程序資源管理器，但如果我們想嘗試的話，它會在下週再次凍結。
好的，問題最終出在備份軟體 (Syncovery) 上，它存在記憶體洩漏，導致 VSS 卡住，即使軟體本身完成了工作。更新似乎已經解決了這個問題。