Проблема с тайм-аутом анализа DebugDiag - PullRequest
Новая
       112

Проблема с тайм-аутом анализа DebugDiag

0 голосов
/ 30 мая 2019

Резюме:

  • Серия дампов памяти собирается с целью обнаружения источник утечки памяти в 32-битном процессе.
  • Попытка использовать диагностику отладки для анализа дампа не удалась после двух часов, сообщая об исключении тайм-аута.
  • Предоставление параметра AnalysisCompletedTimeout в DebugDiag.Analysis.exe.config указывает время ожидания 4 часа Успешно запретить сообщать об исключениях тайм-аута. Вместо этого через 2 часа я вижу совершенно пустой отчет.

Кажется, что моя попытка преодолеть проблему тайм-аута была только частично успешной. Мой вопрос состоит в том, чтобы спросить предложения о том, как сделать анализ успешным при создании отчета анализа.

Подробнее:

По запросу заказчик предоставляет нам последовательность дампов памяти для 32-разрядного приложения сервера COM +. Идея состоит в том, чтобы использовать библиотеку LeakTrack, чтобы помочь отследить источник некоторой утечки памяти, наблюдаемой в этом процессе.

Запущен инструмент анализа отладочной диагностики и добавлен файл дампа. Установив флажок «MemoryAnalysis», анализ начинается. Через два часа инструмент «Анализ» отобразит окно с сообщением о проблеме: 

No report file was generated
---------------------------
An error occurred while generating the analysis report

Exception:
    Type:   TimeoutException

    Message:    This request operation sent to net.pipe://localhost/15466de6-db7d-477f-aac4-42980eb2f27f did not receive a reply within the configured timeout (02:00:00).  The time allotted to this operation may have been a portion of a longer timeout.  This may be because the service is still processing the operation or because the service was unable to send a reply message.  Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.

    StackTrace: 

Server stack trace: 
   at System.ServiceModel.Dispatcher.DuplexChannelBinder.SyncDuplexRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)


Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at DebugDiag.DotNet.x86Analysis.IAnalysisService.RunAnalysisRules(List`1 analysisRuleInfos, List`1 dumpFiles, String symbolPath, String imagePath, String reportFileFullPath, TimeSpan timeout, Boolean twoTabs, Boolean includeSourceAndLineInformationInAnalysisReports, Boolean setContextOnCrashDumps, Boolean doHangAnalysisOnCrashDumps, Boolean includeHttpHeadersInClientConns, Boolean groupIdenticalStacks, Boolean includeInstructionPointerInAnalysisReports, List`1& facts)
   at DebugDiag.DotNet.NetAnalyzer.RunX86Analysis(NetProgress progress, List`1 dumpFiles, List`1 analysisRuleInfos, String symbolPath, String imagePath, String reportFileFullPath, Boolean twoTabs, NetResults& results, List`1& facts)
   at DebugDiag.DotNet.NetAnalyzer.RunAnalysisRulesInternal(DumpFileType bitness, NetProgress progress, String symbolPath, String imagePath, String reportFileFullPath, Boolean twoTabs, AnalysisModes analysisMode)
   at DebugDiag.DotNet.NetAnalyzer.RunAnalysisRules(NetProgress progress, String symbolPath, String imagePath, String reportFileDirectoryOrFullPath, Boolean twoTabs, AnalysisModes analysisMode)
   at DebugDiag.Analysis.AnalyzerClient.RunAnalysisAsyncInternal(NetProgress progress, String symbolPath, String imagePath, List`1 dumpFiles, List`1 analysisRules, String reportFileDirectoryOrFullPath, Boolean IncludeSourceAndLineInformationInAnalysisReports, Boolean SetContextOnCrashDumps, Boolean DoHangAnalysisOnCrashDumps, Boolean IncludeHttpHeadersInClientConns, SynchronizationContext synchContext, Boolean ExcludeIdenticalStacks, Boolean IncludeInstructionPointerInAnalysisReports)

После того, как я покопался в сборках инструмента анализа DebugDiag с помощью JetBrains dotPeek, я внес изменение в DebugDiag.Analysis.exe.config, чтобы попытаться изменить настройку тайм-аута на 4 часа: 

<?xml version="1.0"?>
<configuration>
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="DebugDiag.DotNet.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <DebugDiag.DotNet.Properties.Settings>
      <setting name="AnalysisCompletedTimeout" serializeAs="String">
        <value>04:00:00</value>
      </setting>
    </DebugDiag.DotNet.Properties.Settings>
  </applicationSettings>
  <startup> 
      <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>
  </startup>
  <system.net>
    <defaultProxy useDefaultCredentials="true">
    </defaultProxy>
  </system.net>
</configuration>

После повторной попытки анализа инструмент снова работает около 2 часов. После завершения Internet Explorer запускается со своим отчетом, который оказывается полностью пустым. Проверка папки отчетов DebugDiag показывает, что размер файла отчета .mht составляет 0 байт. Однако на этот раз окно сообщения «исключение тайм-аута» не отображалось.

Итак, у меня есть следующие вопросы: почему не создается отчет? Существуют ли дополнительные параметры конфигурации, которые мне нужно добавить / изменить, чтобы позволить завершить отчет, либо в процессе хоста анализа отладочного диагноза, либо в процессе вызова (UI)?

Чтобы попытаться выяснить, что еще может пойти не так, я подключил windbg к процессу DebugDiag.x86AnalysisHost.exe, когда анализ уже начался. Я надеялся, что смогу увидеть свидетельства других исключительных ситуаций, которые могли бы подсказать, что происходит. Однако процесс, по-видимому, завершается контролируемым образом, без каких-либо исключительных условий.

Предложения по следующему приветствию.

...