在生產環境中，應用程式偶爾會出現無回應或崩潰的情況。此時僅靠日誌或遙測資料往往難以完整還原問題發生時的記憶體狀態，開發者必須額外重現情境才能追蹤根本原因。記憶體傾檔（memory dump）正是一種能在特定瞬間完整保存進程位址空間的技術，它可以包含堆積、控制代碼、模組以及執行緒的快照，讓除錯工具得以在不重新執行程式的情況下檢視當時的變數與呼叫堆疊。因此，了解如何在程式內部主動產生傾檔，對於診斷間歇性效能瓶頂或執行緒池飽和問題具有實際價值。
本文示範的做法是建立一個名為 ThreadPoolWatcher 的監視類別。該類別會啟動一個背景執行緒，以固定間隔（預設三秒）喚醒一次。每次喚醒時，它會將一個簡單的 Task 丟入執行緒池並使用 Stopwatch 量測該任務完成所需的時間。如果任務的執行時間超過預設的閾值，程式會判斷執行緒池可能已經飽和，因而觸發記憶體傾檔的產生。為避免重複產生過大的傾檔，程式內部還加入了一個靜態計數器與鎖定機制，確保在同一次執行中只會產生一次傾檔。這種設計讓監視邏輯與傾檔產生過程相互獨立，且不會干擾主要工作負載的正常執行。
在 Windows 平台上，傾檔的實作透過 P/Invoke 呼叫 dbghelp.dll 中的 MiniDumpWriteDump 函式。該函式需要傳入目標進程的控制代碼、進程 ID、以及一個已開啟的檔案串流，然後透過一系列旗標（例如 WithFullMemory、WithHandleData、WithThreadInfo 等）決定要傾檔的內容範圍。在範例中，所有可用的旗標都被組合，因此產出的傾檔大小會接近進程所佔用的完整記憶體空間，實測約為 125 MB，但實際大小會隨著記憶體使用量與選擇的旗標而變化。在 Linux 上，則使用 .NET 執行階段隨附的 createdump 工具。為了讓此工具能夠在受 Yama LSM 限制的系統上成功附加到目標進程，程式會先透過 prctl 設定 PR_SET_PTRACER 為 PR_SET_PTRACER_ANY，使得任何具有相同使用者權限的進程都能進行 ptrace。接著程式尋找執行目錄旁的 createdump 執行檔，以 --full 參數產生完整位址空間的傾檔，並在非根權限的容器或 SELinux/AppArmor 環境中提供相應的提示訊息。此方法在測試環境中產出的傾檔約為 800 MB，同樣受到進程記憶體大小與傾檔設定的影響。
為了展示監視機制的實際效果，範例中故意讓應用程式執行大量平行工作，每項工作內部呼叫 Thread.Sleep 以模擬長時間阻塞。由於沒有對平行度進行限制，這些工作會快速佔滿執行緒池的可用執行緒，導致後續的 Task 無法及時完成，從而觸發 ThreadPoolWatcher 的傾檔產生流程。產出的 .dmp 檔案可直接在 Visual Studio 中開啟，使用受管理偵錯功能檢視執行緒堆疊、檢查物件狀態以及觀察執行緒池的內部佇列。這種事後分析方式讓開發者能夠在不重新重現問題的情況下，直接看到導致執行緒池飽和的具體呼叫路徑與資源佔用情況。
透過程式內部主動產生記憶體傾檔，團隊可以在問題首次出現時就捕獲現場資訊，避免依賴使用者回報或手動觸發傾檔的延遲。這種主動式監控尤其適合於間歇性效能問題或難以重現的競爭條件。然而，這種做法也具有明顯的限制：完整傾檔檔案龐大，可能包含連線字串、權杖或其他敏感資料，必須妥善保存與傳輸；在進程已經陷入死鎖或資源耗盡的狀態下，內部執行緒可能無法正常執行傾檔程式碼，導致產生失敗；此外，頻繁觸發傾檔會影響系統效能與磁碟空間。因此，在正式環境中建議將此類監視代碼視為臨時診斷工具，或僅在特定診斷建置中啟用；對於長期監控，可考慮使用外部工具（如 dotnet-dump、透過環境變數觸發的傾檔或 Microsoft.Diagnostics.NETCore.Client 套件）來降低對目標進程的侵入性。總結來說，了解記憶體傾檔的產生原理與使用情境，有助於開發者在需要時快速取得關鍵的系統狀態，進而提升問題診斷的效率與準確度。本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。