我有一步一步的在Visual Studio .NET的多線程應用程序的調試問題2008建議調試多線程應用程序
對於每個階梯線，Visual Studio中得到慢（它需要更多的和更多時間跳到下一行），並且通常會在幾行後掛起（我得到「Visual Studio繁忙」氣球提示），並且我需要停止調試。
我懷疑問題是由於應用程序有幾個連接的TCP/IP客戶端，這意味着每次創建斷點時，其網絡緩衝區都會被填充，直到我繼續我的應用程序。無論何時我使用F10轉到下一行代碼，Visual Studio都會很快喚醒所有其他線程來處理輸入數據。
有沒有人有這些問題的經驗，並提出如何避免這些問題的建議？
這不是一件容易的事，我相信你明白這一點。 對於由.NET Framework提供的線程和同步機制有一個清楚的瞭解非常重要。只有這樣做後才能啓動設計一個線程同步和管理。
我建議爲你的線程定義明確的名稱，並引入廣泛的日誌記錄，log4net將是一個不錯的選擇，因爲它提供了一個線程安全和強大的日誌工具。
的Visual Studio提示：
查看更多在這裏：Debugging Multithreaded Applications
編輯：添加更多提示
嘗試找出它真正有用的應用程序邏輯狀態進行手動調試和使用條件斷點，如果有可能這樣就可以避免調試器的額外遊：
正如acoolaum指出的那樣，最好使用定時日誌來查看任何異常或崩潰報告。此外，您可以添加條件編譯來使用不會導致任何掛斷的備用路徑。例如，當調試依賴於從TCP/IP獲取信息的函數時，使用一個只是返回字符串而不實際執行任何TCP/IP通信的模擬函數。
有創建只爲做這種嘲笑的圖書館。你可能想看看其中的一個。
這個建議可能是一個長鏡頭，但在這裏我去了：任何機會，你試圖調試的應用程序是一個WinForms應用程序，你有一個觀察窗口打開？
過去，在我幾乎完全停止使用Watch Windows之前，我還記得體驗過慢一點的場景。如果我的斷點是在非UI線程的上下文中觸發的，並且觀察窗口的值輪詢包括UI綁定的值，那麼我可以重複它，調試器將無聲無息地吞噬跨線程異常，並且它會變得更慢，越來越慢，直到它無法使用。
關閉監視窗口完全擺脫了延遲。
可能是好日誌會更好嗎？或者嘗試使用條件進行調試... – acoolaum
我使用日誌記錄（log4net），我通常使用單元測試來測試應用程序。但是偶爾我需要在某個地方製造一個斷點。斷點*可以是有條件的（如果這就是你的意思），但這並不改變這樣一個事實，即在沒有VS掛起的情況下，我很難執行下兩行。到目前爲止，我會失去自己的脾氣，並在整個方法中爲日誌添加一堆調試，然後從那裏開始工作。但是不能正確使用調試器是沒有意義的。 – Groo