【问题标题】:Disassemble .NET IL to find error message反汇编 .NET IL 以查找错误消息
【发布时间】:2010-12-23 04:23:33
【问题描述】:

我的团队正在尝试查找 .NET windows service 中出现错误消息的位置,该消息封装了由 Microsoft 构建并驻留在我们服务器上的 Web 服务,以支持我们使用的业务产品。微软亲自告诉我们,我们收到的错误实际上是他们的错误之一,但是他们无法确定发生的位置或原因。这是一个关键的业务流程,给我们的团队带来了极大的痛苦。

据我们所知,此错误是随机发生的,并且没有我们可以通过查看堆栈跟踪发现的共性。堆栈跟踪上的最后一次调用是我们尝试从服务读取响应的方法调用,没有提示我们在对服务的方法调用中发生错误的位置或原因。 Microsoft Windows 服务未将任何错误记录到事件查看器。

我们希望通过查找正在抛出的错误消息字符串来跟踪此错误的来源。如果我们能够识别出产生此错误的方法调用,我们就可以更进一步缩小解决此错误的范围。

虽然我们无权访问此服务的源代码,但我们可以使用 IL 反汇编程序 (idlasm.exe) 查看 IL。我已经为一些程序集转储了 IL,但它们不是文字字符串。

是否可以在 IL 中找到文字字符串?我假设它是编码的——我只是对 IL 了解不够,无法确定在哪里查找,或者如何识别 IL 中的字符串。如果它在 IL 中不作为带有方法的文字字符串存在,并且存储在资源中,那么还能在哪里找到错误消息?

堆栈跟踪,已替换应用名称。

Raw Error:  There is insufficient memory to execute this function.
This can be caused by recursive function calls. Contact your system administrator.

at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)   
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Product.DoSomething() in c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\da35f853\f48bba34\App_WebReferences.jygjwt-a.0.cs:line 701
at Product.DoSomething() in E:\Sites\Example.com\App_Code\File.vb:line 1105
at ASP.shop_checkout_aspx.ProcessCheckout() in E:\Sites\Example.com\processcheckout.aspx:line 546

一些附带说明是,在出现此错误消息时有大量可用内存,并且当此错误发生时,对任何方法的每次后续调用都会返回相同的错误。只有重新启动 Microsoft 服务才会消退。

我们已缩小对我们网站使用的服务的每次调用,但无法重现此消息。我们可以使开发中的服务超载大约 1000 倍于生产中的流量,并导致内存不足异常(通过消耗所有内存),但不会显示消息“Can be 由递归函数调用引起。” Agian,微软称这是他们的产品专门抛出的一个独特错误。

更新

我们已经设法在 .etx 文件中找到文字错误消息,如下所示:

//   ÚÄÄÄÄÄÄÄÄÄ¿
// ÚÄ´  STACK  ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
// ³ ÀÄÄÄÄÄÄÄÄÄÙ                                                              ³
// ³                                                                          ³
// ³  Stack Manager                                                           ³
// ³                                                                          ³
// ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
@1@15@0@
@2@1@0@
There is insufficient memory to execute this function.

This can be caused by recursive function calls that are used in the program. Contact your system administrator.
@2@END@0@

我假设@1@15@0@@2@1@0@@2@END@0@ 是程序集用来引用这些字符串的某种引用。有没有人有任何关于如何将这些绑定到使用这些字符串的程序集之一的信息?到目前为止,IL 转储中似乎没有任何数据与@ 符号的格式匹配。

【问题讨论】:

  • 您可以尝试使用Redgates ReflectorDisassemble addin 来寻找它。否则我担心我们能为你做的不多,除非你向我们提供文件和堆栈跟踪......我猜这很可能不会发生。
  • 谢谢鲍比。我有意留下我们的错误消息和产品,以免侵犯任何 Microsoft 合法性。 =)
  • 最后一个想法,stacktrace 中的最后一行还是第一行是您的方法?如果是第一个,则异常源自您自己的应用程序,如果是最后一个,则在他们的应用程序中。
  • “堆栈跟踪上的最后一个调用是我们的方法调用”,是微软代码调用你吗?还是反过来?
  • 您可以尝试使用 Fiddler 或 Wireshark 直接观察 SOAP 流量。

标签: .net il


【解决方案1】:

您很可能需要查看线路的另一端以了解异常的来源。别忘了,你正在使用肥皂。 SoapMessage.Exception 属性在 SoapHttpClientProtocol.ReadResponse() 不为空时被抛出。

异常文本暗示了所谓的软堆栈溢出。 Windows 异常代码 0xe053534f(谷歌很好),当互操作代码发现没有足够的堆栈空间来运行函数而不会导致硬堆栈溢出时抛出。

【讨论】:

    【解决方案2】:

    与此同时,您可以简单地增加 IIS 工作程序 w3wp.exe 的堆栈大小(使用 editbin)。默认堆栈大小非常小。

    【讨论】:

    • @SK 我们试图通过减少运行此进程的 .exe 的堆栈保留来重现错误。在我们更改堆栈大小之前,它被设置为@1mb。在将堆栈限制到 768k 之后,进程仍然会运行,但我们会得到不同的错误——不是上面提到的错误。我们仍在测试这种可能的解决方案。谢谢。
    【解决方案3】:

    这是一个 StackOverflowException。 SOAP 调用中缺少的服务器端堆栈跟踪是一个致命的赠品。

    【讨论】:

      猜你喜欢
      • 2013-06-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-10-10
      • 2017-03-19
      • 2019-10-01
      • 1970-01-01
      相关资源
      最近更新 更多