debugdiag

0熱度

1回答

有沒有辦法從命令行調用DebugDiag分析？我試過這個： DebugDiag.Analysis.exe "C:\dumps\oops.dmp" 但它只啓動了GUI（添加了oops.dmp）。我所尋找的是更多的東西是這樣的： DebugDiag.Analysis.exe -dump "C:\dumps\oops.dmp" -out "C:\results\oops-DebugDiag.mht"

0熱度

1回答

Windows服務不規則地凍結

因爲我用盡討論與我們的管理員的爭論，我希望你能幫助我解決以下問題。我們有一個奇怪的行爲對應於我們自我實現的windows服務。他們隨機凍結。有時他們會繼續工作數週，有時他們會在一週內凍結多次。我很確定，沒有問題的代碼不正常或未處理的異常。在我看來，這是一種Windows管理員/權限管理問題，與時間上的巧合相結合。但是，讓我們有一些信息，在開始第一：所有Windows服務是一個服務器上運行。

0熱度

1回答

DebugDiag未完成分析

我一直在嘗試爲.NET Web應用程序找到較高的CPU使用率。按照本文中的說明，我使用了DebugDiag工具：https://www.iis.net/learn/troubleshoot/performance-issues/troubleshooting-high-cpu-in-an-iis-7x-application-pool 轉儲已成功收集，但是使用DebugDiag Analyzer分

0熱度

1回答

DebugDiag如何分析轉儲文件而沒有匹配的調試DLL

我在嘗試分析轉儲文件時遇到了以下錯誤。 0:000> !threads The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging. CLR

2熱度

1回答

轉儲文件分析

最近我開始面臨一些服務器的CPU開始消耗比平常趨勢更多的資源的問題。我正在試圖找出造成這種情況的根本原因，並從任務管理器中獲取了w3wp進程的轉儲（右鍵單擊進程並轉儲）。現在dmp文件大小爲14GB，我試圖去分析它通過WinDBG的，但該工具不能正常工作並獲得消息：我也參加了一些小型轉儲，但他們中的一些開放罰款，而少數是這與32bit或64bit之間的混淆無關（收集的轉儲爲64bit）。我想

0熱度

1回答

DebugDiag - 像windbg'kp'命令那樣的儀器堆棧

是否有可能使DebugDiag Analysis提供像windbg'kp'命令一樣的堆棧跟蹤信息？即「京都議定書」有源文件路徑，行號和參數值（我已經證實了一個有效的DMP，我們的符號服務器正確儀器DMP在WinDbg中）感謝

0熱度

1回答

如何確定從轉儲文件中導致高內存使用率的方法？

我含在IIS託管我們的.NET應用程序捕獲的內存數.dmp文件，我想通過某種分析儀，會告訴我哪些方法，我們的應用有助於不明原因的內存使用率來運行它們。我試過DebugDiag分析以及Visual Studio附帶的工具。我可以設法產生內存中的對象列表，但我不知道哪種方法正在生成對象。任何人都可以直接我的應用程序，可以輕鬆地幫助我想出解決辦法，或者甚至可能教我如何使用DebugDiag資料或Vi

0熱度

1回答

使用debugdiag獲得更多的通話功能信息

我使用debugdiag 1.2與.dmp文件。我一直在使用Microsoft支持，並且我們獲得了不同的功能跟蹤細節 - 他的版本更加詳細，包含函數名稱和參數。我想知道是否有什麼我失蹤了，以得到他一樣？例如，我將獲得： ntdll!NtWaitForMultipleObjects+a KERNELBASE!WaitForMultipleObjectsEx+e5 clr!WaitForM

1熱度

2回答

如何在應用程序池回收後獲取特定異常的內存轉儲

我們的應用程序池回收了我們的WCF服務後，拋出FileLoadException。回收應用程序池有所幫助。有時錯誤消失而沒有回收。我問了這個問題我在這裏問了第一個問題：FileLoadException when accessing WCF service 由於我們沒有其他的想法如何分析這個問題，我們想獲得內存轉儲與它的異常。但我不知道如何配置adplus或debugdiag自動附加到該新進程

2熱度

1回答

DebugDiag調用堆棧不顯示調用堆棧中函數的行數

我正試圖隔離Windows上的本機代碼中的內存泄漏。我運行了一個測試用例的多次迭代，並將DebugDiag附加到進程中以收集有關可疑泄漏（通過PerfMon中的多次運行確認的內存泄漏）的信息。 DebugDiag資料指出可疑調用堆棧像 Call stack sample 1 Address 0x0f09e2c0 Allocation Time 00:22:38 since trackin