使用企业库时 C# 非托管应用程序崩溃

发布于 2024-12-06 21:52:06 字数 1657 浏览 0 评论 0原文

我有一个从非托管进程加载的 C# 库 DLL。到目前为止一切都很好。现在我想将 Enterprise Library 5.0 与其日志记录功能结合起来。我添加了这些引用:

  • Microsoft.Practices.EnterpriseLibrary.Common.dll
  • Microsoft.Practices.Unity.dll
  • Microsoft.Practices.Unity.Interception.dll
  • Microsoft.Practices.ServiceLocation.dll
  • Microsoft.Practices.EnterpriseLibrary.Logging.dll

...和所需的所有 using 语句。 以下是该类的摘录:

using Microsoft.Practices.EnterpriseLibrary.Common;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.InterceptionExtension;
using Microsoft.Practices.ServiceLocation;
using Microsoft.Practices.Unity.Configuration;    

[StructLayout(LayoutKind.Sequential,CharSet=CharSet.Unicode,Pack=2)]
unsafe public static class DLLDispatch
{
    private static IConfigurationSourceBuilder LoggingBuilder = new ConfigurationSourceBuilder();
    ...
}

问题是,当定义此字段时,非托管进程会崩溃。如果将其注释掉,则不会发生此崩溃。以下是此崩溃的 Windows 应用程序日志:

**Sig[0].Name=应用程序名称

Sig[0].Value=terminal64.exe

Sig[1].Name=应用程序版本

Sig[1].Value=5.0。 0.507

Sig[2].Name=应用程序时间戳

Sig[2].Value=003f5e00

Sig[3].Name=故障模块名称

Sig[3].Value=clr.dll

Sig[4].Name=故障模块版本

Sig[4].Value=4.0.30319.237

Sig[5].Name=故障模块时间戳

Sig[5].Value=4dd2333e

Sig[6].Name=异常代码

Sig[6 ].Value=c00000fd

Sig[7].Name=异常偏移量

Sig[7].Value=000000000007382a**

我在网上搜索了异常代码 c00000fd 并发现它是一个 stackoverflow :-) 异常。 我玩了一下,每次涉及企业库的实例时都会发生这种崩溃。如果没有使用该库,则不会发生崩溃。这是怎么回事?是因为该类处于不安全的上下文中还是其他什么原因? 提前致谢。

I have a C# library DLL which is loaded from an unmanaged process. So far everything is good. Now I wanted to incorporate the Enterprise Library 5.0 with its logging capabilities. I added these references:

  • Microsoft.Practices.EnterpriseLibrary.Common.dll
  • Microsoft.Practices.Unity.dll
  • Microsoft.Practices.Unity.Interception.dll
  • Microsoft.Practices.ServiceLocation.dll
  • Microsoft.Practices.EnterpriseLibrary.Logging.dll

...and all the using statements required.
Here is an excerpt from the class:

using Microsoft.Practices.EnterpriseLibrary.Common;
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.InterceptionExtension;
using Microsoft.Practices.ServiceLocation;
using Microsoft.Practices.Unity.Configuration;    

[StructLayout(LayoutKind.Sequential,CharSet=CharSet.Unicode,Pack=2)]
unsafe public static class DLLDispatch
{
    private static IConfigurationSourceBuilder LoggingBuilder = new ConfigurationSourceBuilder();
    ...
}

The problem is that when this field is defined the unmanaged processes crashes. If it is commented out, this crash does not happen. And here is the windows application log for this crash:

**Sig[0].Name=Application Name

Sig[0].Value=terminal64.exe

Sig[1].Name=Application Version

Sig[1].Value=5.0.0.507

Sig[2].Name=Application Timestamp

Sig[2].Value=003f5e00

Sig[3].Name=Fault Module Name

Sig[3].Value=clr.dll

Sig[4].Name=Fault Module Version

Sig[4].Value=4.0.30319.237

Sig[5].Name=Fault Module Timestamp

Sig[5].Value=4dd2333e

Sig[6].Name=Exception Code

Sig[6].Value=c00000fd

Sig[7].Name=Exception Offset

Sig[7].Value=000000000007382a**

I searched the web for the exception code c00000fd and found it to be a stackoverflow :-) exception.
I played around a bit and this crash occures everytime there is an instance involved from the enterprise library. If nothing is used of that library then there is no crash. What is going on here? Is it becasue the class is in unsafe context or what else can it be?
Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

白鸥掠海 2024-12-13 21:52:06

我找到了这个问题的解决方案。必须将应用程序配置文件放入非托管应用程序文件夹中,其中包含以下内容:

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
 <runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
     <probing privatePath="Unmanaged application startup folder" />
   </assemblyBinding>
 </runtime>
</configuration>

通过此信息,CLR 可以绑定程序集并在正确的文件夹中进行搜索。我不清楚配置文件对于非托管应用程序是否也有用。

谢谢,于尔根

I found the solution to this problem. One has to put a app-config file in the unmanaged application folder with this content:

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
 <runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
     <probing privatePath="Unmanaged application startup folder" />
   </assemblyBinding>
 </runtime>
</configuration>

With this information the CLR can bind assemblies and searches in the correct folder. It was not clear to me that a config file is also useful for unmanaged applications.

Thanks, Juergen

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文